SSH post-quantum: mlkem768x25519-sha256 in OpenSSH

OpenSSH offre già oggi l'accordo di chiavi post-quantum, senza librerie aggiuntive e senza patch. Il metodo ibrido mlkem768x25519-sha256 è stato introdotto in OpenSSH 9.9 (19 settembre 2024) ed è diventato l'accordo di chiavi predefinito in OpenSSH 10.0 (9 aprile 2025). Questa guida spiega come leggere quale metodo una sessione abbia effettivamente negoziato, come preferire il metodo ibrido sulle build che lo supportano senza usarlo come predefinito, che cosa significa l'avviso di OpenSSH 10.1 sugli accordi di chiavi non post-quantum e perché le chiavi host SSH restano ancora classiche.

Che cosa fa realmente mlkem768x25519-sha256

Il nome descrive la costruzione. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, un KEM o meccanismo di incapsulamento delle chiavi) con il set di parametri 768, X25519 (Diffie-Hellman su curva ellittica Curve25519) e SHA-256 come funzione di hash. Il NIST ha pubblicato ML-KEM come FIPS 203 il 13 agosto 2024 (FIPS 203), e la pagina di riferimento su ML-KEM ne elenca i set di parametri e lo stato.

Il metodo è ibrido: la chiave di sessione è derivata sia dal segreto condiviso ML-KEM sia dal segreto condiviso X25519. Un client e un server che lo negoziano restano protetti finché almeno una delle due componenti regge. È la scelta prudente mentre le implementazioni post-quantum sono ancora giovani, ed è ciò che indicano le linee guida europee: un accordo di chiavi ibrido anziché uno scambio puramente post-quantum.

In SSH l'accordo di chiavi è la prima priorità, per la stessa ragione che vale per TLS. Un attaccante che registra oggi una sessione cifrata può conservarla e attaccarla in seguito. È lo scenario harvest now, decrypt later (HNDL), descritto nel nostro articolo su harvest now, decrypt later. Se lo scambio era puramente classico, un computer quantistico sufficientemente potente consentirebbe di decifrare a posteriori il traffico registrato. L'autenticazione è diversa: un attaccante in grado di falsificare una firma host deve usarla durante una connessione attiva, quindi la migrazione delle firme può avvenire in un secondo momento senza esporre le sessioni passate.

Passo 1: verificare le versioni e ciò che le sessioni negoziano

Quali metodi supporta il binario

ssh -V
ssh -Q kex
ssh -Q kex | grep mlkem

ssh -Q kex elenca i metodi di scambio di chiavi compilati nel binario, indipendentemente dalla configurazione. Se compare mlkem768x25519-sha256, la build lo supporta. Entrambe le estremità devono supportarlo, quindi eseguite lo stesso controllo sul server: un client moderno che dialoga con un server datato ripiega su ciò che i due hanno in comune.

Quale metodo ha usato questa sessione

ssh -v user@server 2>&1 | grep -i 'kex: algorithm'

L'output dettagliato viene scritto sullo standard error, da cui il reindirizzamento. Una sessione che usa il metodo ibrido stampa una riga del tipo debug1: kex: algorithm: mlkem768x25519-sha256. È il controllo in assoluto più utile, perché riporta ciò che è stato negoziato e non ciò che si ritiene di aver configurato.

Qual è la configurazione effettiva

ssh -G server | grep -i kexalgorithms
sudo sshd -T | grep -i kexalgorithms

ssh -G stampa la configurazione client che si applicherebbe a quella destinazione, dopo la risoluzione di tutti i blocchi Host e delle inclusioni. sshd -T stampa la configurazione effettiva del server e richiede i privilegi di root. Eseguite entrambi prima di modificare qualsiasi cosa e conservatene l'output: costituisce un'evidenza di inventario.

La cronologia delle versioni

Fonte: le note di rilascio di OpenSSH. Lettura pratica: dalla 9.9 il metodo è già disponibile, dalla 10.0 viene preferito automaticamente, e tra la 9.0 e la 9.9 disponete comunque di un accordo di chiavi post-quantum tramite sntrup761x25519-sha512@openssh.com.

Passo 2: preferire mlkem768x25519-sha256 senza compromettere i peer meno recenti

La direttiva è KexAlgorithms, usata in ssh_config lato client e in sshd_config lato server. Accetta tre prefissi: ^ antepone i metodi indicati all'elenco predefinito integrato, + li accoda e - li rimuove. Anteporre è la scelta sicura, perché il resto dell'elenco predefinito rimane disponibile come ripiego.

Client, in ~/.ssh/config o in un file drop-in sotto /etc/ssh/ssh_config.d/:

Host *
    KexAlgorithms ^mlkem768x25519-sha256

Server, in /etc/ssh/sshd_config o in un drop-in sotto /etc/ssh/sshd_config.d/:

KexAlgorithms ^mlkem768x25519-sha256

Se preferite un elenco ordinato esplicito, mantenete i metodi classici in fondo, in modo che i peer non ancora aggiornati possano comunque connettersi:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

Validate la configurazione prima di ricaricarla, ed eseguite un reload anziché un riavvio:

sudo sshd -t
# the service name varies by distribution: ssh on Debian and Ubuntu, sshd on many others
sudo systemctl reload sshd

Una sequenza di operazioni che evita di restare chiusi fuori: testate prima in staging, mantenete aperta una sessione privilegiata durante il reload, poi aprite una seconda sessione e ripetete il controllo con ssh -v prima di chiudere la prima. Non rimuovete i metodi classici dall'elenco di un server finché tutti i client che vi si connettono non sono stati inventariati: jump host, runner di automazione, agenti di backup, sonde di monitoraggio, apparati di rete e librerie SSH embedded sono la causa abituale di un disservizio in questa fase.

Passo 3: interpretare correttamente l'avviso di OpenSSH 10.1

OpenSSH 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiavi non post-quantum. L'opzione è WarnWeakCrypto ed è abilitata per impostazione predefinita. Due aspetti contano sul piano operativo.

Primo, si tratta di un avviso e non di un blocco: la connessione viene comunque stabilita. Vi segnala che è l'altra estremità della connessione a richiedere attenzione. Secondo, sntrup761x25519-sha512@openssh.com è anch'esso un ibrido post-quantum, quindi una sessione che lo negozia non è il caso a cui mira questo avviso. Semplicemente non si basa su uno standard NIST, ed è per questo che ML-KEM è la direzione da seguire per l'interoperabilità e per i requisiti di approvvigionamento.

Trattate ogni avviso come una riga di inventario: quale peer, quale versione, quale team ne è responsabile. Se in seguito vorrete rifiutare gli scambi esclusivamente classici anziché limitarvi a segnalarli, impostate un elenco KexAlgorithms esplicito che contenga solo metodi post-quantum, e fatelo soltanto quando i vostri controlli dimostrano che tutti i peer li supportano.

Passo 4: per ora le chiavi host restano classiche

In SSH l'accordo di chiavi e l'autenticazione vengono negoziati separatamente. Le chiavi host e le chiavi utente sono algoritmi di firma: ssh-ed25519, rsa-sha2-256, rsa-sha2-512 e le varianti ECDSA. I rilasci sopra citati hanno modificato l'accordo di chiavi, non i tipi di chiave host, quindi la situazione realistica oggi è uno scambio ibrido che protegge una sessione ancora autenticata con una chiave host classica. Potete vedere quale chiave è stata usata nello stesso output dettagliato:

ssh -v user@server 2>&1 | grep -i 'host key'

Questa situazione intermedia è accettabile per la ragione indicata in precedenza: la falsificazione di una firma richiede un attacco durante la connessione e non espone le sessioni registrate in passato. Il NIST ha standardizzato ML-DSA come FIPS 204 il 13 agosto 2024 (si veda la pagina su ML-DSA), e la migrazione delle firme SSH dipende da ulteriore lavoro sul protocollo e sulle implementazioni. Nel frattempo, documentate il divario anziché nasconderlo, preferite chiavi host ed25519 e, dove si usa RSA, seguite le indicazioni sulla dimensione delle chiavi applicabili alla vostra organizzazione.

Che cosa documentare per audit e inventari

SSH manca spesso dagli inventari crittografici che già coprono correttamente TLS. Il requisito 12.3.3 di PCI DSS v4.0.1 impone che le cipher suite e i protocolli in uso siano documentati e riesaminati almeno ogni 12 mesi, ed è obbligatorio dal 31 marzo 2025 (si veda PCI DSS v4.0.1). Nell'ambito di DORA, il Regolamento delegato (UE) 2024/1774 della Commissione all'Art. 6 richiede una politica in materia di cifratura e controlli crittografici che includa disposizioni per aggiornare o modificare la tecnologia crittografica in base agli sviluppi della crittoanalisi, e all'Art. 7 richiede la gestione delle chiavi lungo l'intero ciclo di vita (si veda la pagina sugli RTS DORA). Ciò che questi testi richiedono letteralmente è la politica e l'inventario. La corrispondenza riportata di seguito è la nostra interpretazione di come dimostrarlo per SSH, non la citazione di alcun requisito. Si tratta di un'informazione, non di una consulenza legale.

Passo successivo: verificare il resto della vostra superficie

SSH è un protocollo tra tanti, e la stessa costruzione ibrida esiste in TLS come X25519MLKEM768. Il modo più rapido per capire a che punto sono i vostri servizi pubblici è analizzare il vostro dominio con PQC Status, che riporta i gruppi di scambio di chiavi negoziati, le versioni TLS e la catena di certificati. Affiancate questo risultato ai controlli SSH descritti sopra, una riga per host, e avrete l'inizio di un vero inventario crittografico anziché una supposizione.