OpenSSH e crittografia post-quantum: checklist pratica per SysAdmin

OpenSSH è una di quelle fondamenta che si tende a lasciare in pace finché funziona. È comprensibile: se SSH si rompe, non si rompe un servizio secondario, si rompe il modo in cui entri nei server. Però il 2025 ha segnato un passaggio importante: OpenSSH ha iniziato a spostare il key exchange predefinito verso algoritmi ibridi post-quantum, in particolare combinazioni come mlkem768x25519-sha256, che uniscono un meccanismo moderno basato su curve ellittiche con ML-KEM, lo standard derivato da Kyber pubblicato dal NIST come FIPS 203.

Per un SysAdmin non significa “cambiare tutte le chiavi domani mattina”. Significa capire dove la propria infrastruttura è già pronta, dove è fragile e quali compatibilità potrebbero saltare durante gli upgrade di distribuzione. In un homelab o in una piccola azienda, spesso convivono Debian recenti, NAS datati, firewall embedded, vecchie appliance, client Windows con PuTTY o tool di automazione che nessuno ha più toccato. È lì che il tema diventa pratico.

Cosa cambia davvero

Il key exchange SSH serve a stabilire un segreto di sessione tra client e server. Le chiavi pubbliche degli utenti e degli host restano un pezzo diverso del puzzle: ed25519, ecdsa o rsa continuano a essere usate per autenticare identità e host. La parte post-quantum entra soprattutto nella negoziazione iniziale della sessione.

La logica ibrida è prudente: non si butta via X25519, che oggi è solido e veloce, ma lo si combina con ML-KEM. Se uno dei due componenti resta sicuro, la sessione mantiene una protezione significativa. È una scelta sensata per il periodo di transizione, perché il rischio non è solo il computer quantistico “domani”, ma anche lo scenario harvest now, decrypt later: traffico cifrato intercettato oggi e conservato in attesa di capacità future.

In pratica, quando client e server supportano lo stesso algoritmo ibrido, lo useranno automaticamente secondo l’ordine di preferenza configurato. Se una delle due parti non lo supporta, OpenSSH negozierà un algoritmo precedente compatibile, a meno che la configurazione sia stata irrigidita troppo.

Dove nascono i problemi

Il problema tipico non è il server Linux moderno. Il problema è l’ecosistema attorno. Un jump host aggiornato può parlare senza difficoltà con un server aggiornato, ma un vecchio client embedded potrebbe non riconoscere le nuove liste di algoritmi. Alcuni scanner o script di compliance, poi, segnalano falsi positivi quando vedono algoritmi nuovi non presenti nel loro database.

Attenzione anche alle configurazioni copiate negli anni. Molti hardening SSH contengono righe come:

KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256

Questa impostazione, se lasciata così, può impedire l’uso degli algoritmi post-quantum anche dopo l’upgrade del pacchetto OpenSSH. Non è un disastro, ma vanifica il miglioramento. Peggio ancora, configurazioni troppo restrittive possono rompere client legacy senza averlo previsto.

Checklist prima dell’upgrade

Prima di aggiornare OpenSSH su macchine critiche, conviene fare un inventario minimo.

1. Elenca versioni di client e server:

ssh -V
sshd -V 2>&1 || /usr/sbin/sshd -T | head

2. Verifica gli algoritmi disponibili lato client:

ssh -Q kex | sort

3. Controlla la configurazione effettiva del demone:

sshd -T | grep -i '^kexalgorithms'

4. Cerca override manuali:

grep -R "^KexAlgorithms" /etc/ssh /etc/ssh/sshd_config.d 2>/dev/null

5. Testa una connessione verbosa verso un server non critico:

ssh -vvv utente@host 2>&1 | grep -i "kex: algorithm"

Il punto non è applicare comandi alla cieca, ma sapere quale algoritmo viene negoziato davvero. In produzione è meglio testare da almeno tre sorgenti: workstation amministrativa, jump host e sistema di automazione, per esempio Ansible, GitLab Runner o un backup server.

Strategia consigliata per piccole infrastrutture

La strategia più pulita è evitare override inutili e seguire i default della distribuzione, soprattutto su Debian, Ubuntu, Fedora, RHEL e derivate recenti. I maintainer stanno già facendo il lavoro delicato di bilanciare sicurezza e compatibilità. Personalmente eviterei di “forzare” subito solo algoritmi post-quantum su tutto il parco: è una bella idea sulla carta, ma un pessimo modo per scoprire che il firmware del NAS non riceve update dal 2021.

Meglio procedere per anelli:

• prima aggiornare client amministrativi e jump host;
• poi aggiornare server Linux standard;
• infine trattare appliance, hypervisor, switch, storage e sistemi legacy come eccezioni documentate.

Se usi un bastion host, è il posto giusto dove osservare compatibilità e log. Puoi abilitare logging più dettagliato temporaneamente, verificare gli algoritmi negoziati e correggere gli script che usano librerie vecchie.

Esempio di hardening ragionevole

In molte installazioni moderne non serve impostare KexAlgorithms. Se però hai una policy esplicita, evita liste antiche e includi gli algoritmi moderni supportati dal tuo OpenSSH. Un esempio va sempre validato con sshd -t e in una seconda sessione aperta:

# /etc/ssh/sshd_config.d/20-kex-policy.conf
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected]

Non copiarlo se il tuo server non supporta quegli algoritmi: sshd -t fallirebbe e potresti bloccare il restart. Prima controlla con ssh -Q kex e con la documentazione della tua versione.

Piano di rollback

La regola d’oro resta banale: mai chiudere la sessione SSH con cui stai lavorando finché non hai aperto una seconda connessione di test. Prima di cambiare configurazione:

cp /etc/ssh/sshd_config /root/sshd_config.backup.$(date -u +%Y%m%dT%H%M%SZ)
sshd -t
systemctl reload ssh || systemctl reload sshd

Se la seconda connessione fallisce, ripristina il file e ricarica il servizio dalla sessione ancora aperta. Su server remoti importanti conviene avere anche console out-of-band: iDRAC, IPMI, Proxmox console, VPS serial console o almeno accesso tramite pannello provider.

Impatto su Ansible, backup e Git

Ansible usa OpenSSH nella configurazione più comune, quindi eredita i comportamenti del client di sistema. I problemi arrivano quando usi container di automazione vecchi o immagini CI non aggiornate. Anche repository Git via SSH, job di backup con rsync e script di deploy possono fallire se un host ha una policy troppo stretta.

Prima di irrigidire le policy, crea una matrice semplice: sorgente, destinazione, versione OpenSSH, algoritmo negoziato, esito. Bastano dieci righe per evitare incidenti noiosi.

Conclusione

La crittografia post-quantum in OpenSSH non è una moda da convegno: sta entrando nei default reali. La buona notizia è che la transizione è progettata per essere graduale. La cattiva è che gli ambienti piccoli spesso hanno più eccezioni di quanto si pensi.

Il consiglio pratico è semplice: aggiorna, osserva, rimuovi override vecchi, testa da più client e documenta le eccezioni. Non serve panico, ma serve disciplina. SSH è la porta di servizio dell’infrastruttura: quando cambia il modo in cui negozia la cifratura, è meglio accorgersene prima del prossimo maintenance window.

Fonti

• OpenSSH, release notes ufficiali: https://www.openssh.com/releasenotes.html
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf
• Red Hat, Post-quantum cryptography in RHEL 10: https://www.redhat.com/en/blog/post-quantum-cryptography-red-hat-enterprise-linux-10