SSH post-quantistico su Ubuntu: cosa è cambiato

Cosa è cambiato in SSH post-quantistico

SSH post-quantistico è già attivo per la maggior parte degli utenti e non è stato necessario configurare nulla. Un client OpenSSH aggiornato che comunica con un server OpenSSH aggiornato seleziona per impostazione predefinita uno scambio di chiavi post-quantistico ibrido. In questo modo la chiave di sessione resiste a un attaccante che registra oggi il traffico e lo decritta tra diversi anni. La protezione è effettiva, ma più limitata di quanto suggerisca l'espressione "SSH a prova di computer quantistici".

Prima servono due definizioni. SSH (secure shell) è il protocollo con cui si accede a un server. Lo scambio di chiavi, indicato generalmente come "kex", è il primo passaggio di ogni connessione SSH: le due estremità concordano un segreto condiviso, che viene usato per cifrare tutto ciò che segue. È cambiato lo scambio di chiavi. Nient'altro.

Non fidarti di questa pagina: esegui i comandi

Ogni nome di algoritmo riportato di seguito proviene da un comando che puoi eseguire direttamente. È una scelta intenzionale. Il valore predefinito cambia a ogni release di OpenSSH. Per questo, una guida scritta due anni fa può indicare un algoritmo che la tua macchina non preferisce più, senza avere modo di informarti. Impara a usare questi comandi e non avrai più bisogno di articoli sull'argomento, incluso questo.

Inizia verificando quali funzionalità supporta la tua build.

ssh -V
ssh -Q kex

ssh -V stampa una riga con la versione che inizia con OpenSSH_, seguita dal suffisso del pacchetto Ubuntu e dalla versione di OpenSSL. ssh -Q kex stampa un algoritmo di scambio delle chiavi per riga. In una build con supporto post-quantistico, nell'elenco troverai nomi come mlkem768x25519-sha256 e sntrup761x25519-sha512@openssh.com, accanto a nomi di algoritmi classici come curve25519-sha256.

Ciò che la build supporta non coincide con ciò che propone

Questa è la distinzione che la maggior parte degli articoli omette. ssh -Q kex risponde a una domanda: che cosa può fare questo binario. Non risponde alla domanda importante: che cosa proporrà effettivamente questa connessione. I due elenchi sono diversi, e il divario tra loro è il punto in cui i consigli obsoleti causano danni concreti.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> stampa la configurazione effettiva del client per quell'host, dopo l'applicazione di ~/.ssh/config e /etc/ssh/ssh_config. sshd -T fa lo stesso per il server. Ciascun comando stampa una singola riga kexalgorithms nell'ordine di preferenza; il primo nome della riga è la prima scelta di quel lato. È questa la riga che viene trasmessa sulla rete.

Il divario non è teorico. OpenSSH 8.5, rilasciato il 2021-03-03, ha aggiunto sntrup761x25519-sha512@openssh.com e lo ha deliberatamente escluso dall'elenco predefinito. In quella release ssh -Q kex mostra l'algoritmo, mentre ssh -G non lo mostra; questo significa che il binario può eseguire uno scambio di chiavi post-quantistico, ma nessuna connessione lo propone.

Leggere l'algoritmo negoziato dalla connessione

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Tra un client aggiornato e un server aggiornato, il comando restituisce:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 è un algoritmo ibrido. Usa ML-KEM (meccanismo di incapsulamento delle chiavi basato su reticoli, standardizzato come FIPS 203) con il set di parametri 768, insieme a Diffie-Hellman su curva ellittica X25519, e combina entrambi i risultati nella chiave di sessione.

Con un server meno recente, invece, potresti vedere:

debug1: kex: algorithm: curve25519-sha256

Questo nome non include una componente post-quantistica. curve25519-sha256 è Diffie-Hellman su curva ellittica usato autonomamente e un computer quantistico abbastanza grande può comprometterlo. È questa la ragione per cui il valore predefinito è cambiato.

Una regola di negoziazione spiega perché una sola macchina obsoleta può limitare una sessione. Il client invia il proprio elenco in ordine di preferenza, il server invia il suo e viene scelto il primo nome dell'elenco del client che compare anche in quello del server. La preferenza del client ha la precedenza, quindi è l'estremità meno aggiornata a stabilire fino a quale elemento dell'elenco si può arrivare. Aggiornare il laptop non aggiorna una sessione verso un server che non ha mai supportato ML-KEM.

Vale la pena conoscere ssh -v anche per altri motivi, perché lo stesso output è il punto da cui individuare un errore Permission denied (publickey) quando il login viene rifiutato completamente.

Rimuovi grep e ssh -v mostra il resto della negoziazione, inclusa la riga a cui è dedicata la sezione successiva:

debug1: kex: host key algorithm: ssh-ed25519

Quale release di OpenSSH ha reso lo scambio ibrido il comportamento predefinito

Le note di rilascio upstream mostrano una sequenza chiara. Le date sono più importanti dei numeri di versione, perché indicano da quanto tempo questa funzione è attiva senza attirare particolare attenzione.

• 8.5, rilasciata il 2021-03-03, ha aggiunto sntrup761x25519-sha512@openssh.com lasciandolo disabilitato per impostazione predefinita.
• 9.0, rilasciata il 2022-04-08, lo ha abilitato. Le note specificano che OpenSSH avrebbe utilizzato «il metodo di scambio delle chiavi ibrido Streamlined NTRU Prime + x25519 per impostazione predefinita». Questa è la release in cui lo scambio delle chiavi post-quantistico è diventato il comportamento normale.
• 9.9, rilasciata il 2024-09-19, ha aggiunto mlkem768x25519-sha256 come seconda opzione. La stessa release ha assegnato al metodo precedente il nome registrato da IANA, sntrup761x25519-sha512, perciò le build più recenti lo mostrano con entrambe le denominazioni.
• 10.0, rilasciata il 2025-04-09, ha reso mlkem768x25519-sha256 il metodo predefinito per l'accordo sulle chiavi.
• 10.1, rilasciata il 2025-10-06, ha aggiunto un avviso lato client quando una connessione negozia uno scambio delle chiavi privo della componente post-quantistica. L'avviso è controllato dall'opzione WarnWeakCrypto in ssh_config ed è attivo per impostazione predefinita.

Aprile 2022 è la data da ricordare. Qualsiasi coppia di macchine che esegue OpenSSH 9.0 o una versione successiva utilizza da allora uno scambio delle chiavi post-quantistico, senza configurazione e senza alcun avviso per la persona che digita ssh.

Quale release di Ubuntu lo include

Ubuntu fissa una versione di OpenSSH al momento del rilascio e successivamente vi integra le correzioni di sicurezza tramite backport, senza modificare il numero di versione. Di conseguenza, la release di Ubuntu in esecuzione determina l'algoritmo predefinito. Controlla la macchina che hai davanti con ssh -V invece di affidarti a un elenco. Ad agosto 2026 l'archivio contiene queste versioni:

• Ubuntu 22.04 LTS include 1:8.9p1, precedente all'impostazione predefinita introdotta con la versione 9.0; un'installazione standard negozia quindi curve25519-sha256.
• Ubuntu 24.04 LTS include 1:9.6p1, successiva alla versione 9.0 e precedente alla 9.9; il valore predefinito è quindi sntrup761x25519-sha512@openssh.com e ML-KEM non è disponibile.
• Ubuntu 25.10 include 1:10.0p1, il cui valore predefinito è mlkem768x25519-sha256.
• Ubuntu 26.04 LTS include 1:10.2p1, che usa mlkem768x25519-sha256 come valore predefinito e visualizza un avviso per le connessioni non post-quantum.

Esaminiamo una coppia reale di macchine. Un laptop con Ubuntu 26.04 si connette a un server con Ubuntu 24.04. La prima scelta del client, mlkem768x25519-sha256, non è presente nell'elenco del server con OpenSSH 9.6. La successiva scelta post-quantum disponibile anche sul server è sntrup761x25519-sha512@openssh.com, ed è il nome riportato da ssh -v. Lo scambio di chiavi della sessione è quindi post-quantum, nonostante il server sia stato compilato nel 2024 e nessuno abbia modificato la configurazione.

Il caso di Ubuntu 22.04 funziona al contrario e mostra esattamente perché ssh -Q kex, da solo, può trarre in inganno. OpenSSH 8.9 riconosce il nome sntrup761x25519-sha512@openssh.com, quindi ssh -Q kex su quella macchina lo elenca; tuttavia, la proposta predefinita lo esclude e la negoziazione sceglie curve25519-sha256. Da un client OpenSSH 10.1 o successivo, la connessione lo indica esplicitamente:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Questo avviso riguarda il server a cui ti stai connettendo, non il client. La soluzione consiste nell'aggiornare il server. Impostare WarnWeakCrypto no rimuove il messaggio, ma non modifica la connessione.

Perché l’approccio ibrido e cosa significa «raccogliere ora, decifrare in seguito»

La minaccia è semplice. Un attaccante che può osservare il traffico registra oggi i byte cifrati e li conserva. Oggi non può leggerli. Li conserva fino a quando sarà disponibile un computer quantistico abbastanza grande da violare X25519, quindi li decifra. Questa tecnica è chiamata harvest now, decrypt later oppure store now, decrypt later. Non richiede nulla di sofisticato nell’immediato. Richiede spazio su disco e pazienza.

La cifratura presenta questo problema, mentre le firme no, e questa asimmetria determina tutto il resto. Un testo cifrato registrato mantiene il proprio valore finché i dati che contiene restano sensibili. Una firma deve essere non falsificabile solo nel momento in cui viene verificata. La violazione di un algoritmo di firma nel 2035 consentirebbe a qualcuno di impersonare un server nel 2035. Non gli permetterebbe di tornare indietro e falsificare un accesso del 2026. Per questo era necessario intervenire prima sullo scambio delle chiavi; il livello delle firme può attendere.

Ibrido significa che entrambi gli algoritmi vengono eseguiti ed entrambi i risultati contribuiscono alla chiave di sessione. Per recuperare il segreto alla base di mlkem768x25519-sha256, un attaccante deve violare sia ML-KEM 768 sia X25519. L'abbinamento è intenzionale: ML-KEM è molto più recente di X25519 e ha avuto molto meno tempo per essere analizzato dagli esperti di crittoanalisi. Di conseguenza, una vulnerabilità scoperta nel nuovo algoritmo non compromette la protezione già disponibile.

Cosa è protetto e cosa non lo è

Lo scambio di chiavi è protetto. Il segreto condiviso che cifra la sessione proviene da uno scambio ibrido, quindi una registrazione della sessione effettuata oggi non diventerà leggibile quando arriveranno i computer quantistici.

La chiave host non è protetta. La riga debug1: kex: host key algorithm: ssh-ed25519 indica una firma classica, come rsa-sha2-512 e i tipi ECDSA (algoritmo di firma digitale a curva ellittica). Un attaccante dotato di un computer quantistico operativo potrebbe falsificare quella firma e impersonare il server, ma soltanto durante una connessione attiva in quel momento futuro, mai contro il traffico registrato oggi.

Anche la chiave di accesso non è protetta. La chiave in ~/.ssh/id_ed25519 usa lo stesso tipo di firma classica e vale lo stesso ragionamento. Ciò che protegge questa chiave quest'anno è il luogo in cui risiede e chi può leggerla; per questo una gestione corretta delle chiavi SSH riduce il rischio reale molto più di qualsiasi nome di algoritmo riportato in questa pagina.

Non c'è nulla che tu debba fare per nessuno dei due aspetti, perché non esiste ancora un'alternativa a cui passare. OpenSSH ha dichiarato che il supporto per le firme post-quantistiche arriverà in una versione futura. Finché non verrà rilasciato, OpenSSH non dispone di un tipo di chiave host post-quantistico né di un tipo di chiave utente post-quantistico, e ssh-keygen non offre alcuna di queste opzioni. Una guida che indica di generarne una descrive software che non esiste ancora.

TLS sullo stesso server è una questione separata, con una risposta diversa. TLS (sicurezza del livello di trasporto) è il protocollo utilizzato dal web server sulla porta 443 e si basa su una codebase diversa, con tempistiche diverse. Aggiornare OpenSSH non cambia nulla in questo ambito. Se utilizzi un certificato autofirmato per un servizio privato sullo stesso VPS, la firma e lo scambio di chiavi vengono determinati da OpenSSL e dal web server; devi quindi valutare quello stack separatamente, secondo i suoi criteri.

Cosa fa ora un operatore prudente

Mantieni OpenSSH aggiornato e fermati qui. Questa è davvero l'intera strategia per questo problema. sudo apt update && sudo apt upgrade mantiene la versione fornita dalla tua release di Ubuntu, mentre il passaggio a una release più recente di Ubuntu installa una versione più recente di OpenSSH. Attivare gli aggiornamenti di sicurezza automatici applica queste patch senza doverlo ricordare. Compilare OpenSSH dal codice sorgente per inseguire il nome di un algoritmo è un compromesso sfavorevole, perché rinunci agli aggiornamenti di sicurezza della distribuzione per il servizio più esposto del server. Se scarichi comunque il codice sorgente, verifica il download rispetto al checksum pubblicato prima di compilarlo.

Non scrivere manualmente una riga KexAlgorithms. È l'unica azione che peggiora sistematicamente la situazione. Una guida all'hardening del 2018 propone un elenco corretto nel 2018; incollarlo in sshd_config sostituisce l'elenco predefinito invece di aggiungervi elementi. Di conseguenza, ogni algoritmo introdotto da allora viene escluso e un server che avrebbe negoziato autonomamente mlkem768x25519-sha256 passa senza avvisi a qualunque algoritmo resti nell'elenco imposto. Esegui sudo sshd -T | grep -i '^kexalgorithms' su ogni server che hai ereditato. Se quella riga è più corta di quella presente in una nuova installazione della stessa release, qualcuno ha imposto un elenco.

Se hai un motivo concreto per modificare l'elenco, aggiungi elementi invece di sostituirlo. OpenSSH interpreta un + iniziale come aggiunta, un - iniziale come rimozione e un ^ iniziale come spostamento in cima all'elenco.

KexAlgorithms ^mlkem768x25519-sha256

Verifica il file prima di farvi affidamento. sudo sshd -t analizza la configurazione e non stampa nulla quando è valida. Una riga KexAlgorithms che nomina un algoritmo non disponibile nella build impedisce l'avvio di sshd; su un server remoto questo significa non poter più accedere al sistema. Mantieni quindi aperta una seconda sessione mentre lavori. Quando gli elenchi dei due endpoint non hanno più elementi in comune, il client lo comunica chiaramente:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Interpreta il marketing sulla sicurezza post-quantistica come un'affermazione relativa a un solo livello. Quando un fornitore definisce un prodotto quantum-safe, sta descrivendo il livello che ha indicato; di solito si tratta di uno scambio di chiavi. Chiedi il nome dell'algoritmo e il protocollo a cui si applica. Per OpenSSH, nell'agosto 2026, la formulazione corretta è che lo scambio di chiavi è ibrido e post-quantistico, mentre le firme sono classiche. Un'affermazione più ampia dovrebbe essere accompagnata da un nome che puoi trovare nell'output di ssh -Q kex.

Continua a occuparti delle attività ordinarie. Uno scambio di chiavi post-quantistico non risolve il problema di una password facilmente indovinabile né quello di una chiave privata copiata su un laptop che in seguito viene rubato. Sono questi i problemi che compromettono realmente i server, e l'hardening SSH standard su un VPS rimane l'intervento più importante. Se i passaggi di negoziazione descritti qui non ti erano familiari, cosa fa SSH quando ti connetti illustra le fasi che questa pagina presuppone tu conosca.

FAQ

La mia connessione SSH è già post-quantistica?

Eseguire ssh -v yourserver 2>&1 | grep 'kex: algorithm' e leggere il nome visualizzato. mlkem768x25519-sha256 e sntrup761x25519-sha512@openssh.com sono scambi ibridi post-quantistici. curve25519-sha256, ecdh-sha2-nistp256 e qualsiasi nome diffie-hellman-group sono classici. Entrambe le estremità devono usare una versione che offra un nome post-quantistico, perché la negoziazione seleziona la prima scelta del client supportata anche dal server. Di conseguenza, la macchina più vecchia stabilisce il limite massimo.

Quale release di OpenSSH ha reso predefinito lo scambio di chiavi post-quantistico?

OpenSSH 9.0, rilasciato il 2022-04-08, ha reso sntrup761x25519-sha512@openssh.com lo scambio di chiavi predefinito. OpenSSH 9.9, rilasciato il 2024-09-19, ha aggiunto mlkem768x25519-sha256, mentre OpenSSH 10.0, rilasciato il 2025-04-09, lo ha reso predefinito al posto del precedente. OpenSSH 10.1, rilasciato il 2025-10-06, ha iniziato a visualizzare un avviso quando una connessione non negozia nessuno dei due. Verificare il comportamento della propria build con ssh -Q kex e ssh -G <host>, perché è la release di Ubuntu installata a determinare quali opzioni sono disponibili.

Devo generare una chiave SSH post-quantistica?

No, perché OpenSSH non dispone di un tipo di chiave di questo genere. Finora il lavoro post-quantistico riguarda lo scambio di chiavi, che non richiede file di chiave né configurazioni da parte dell'utente. Le chiavi host e le chiavi usate per l'accesso sono ancora firme classiche, come Ed25519 e RSA, e il progetto upstream ha dichiarato che le firme post-quantistiche arriveranno in una release futura. Continuare a usare una chiave Ed25519 e proteggere adeguatamente il luogo in cui viene archiviata.

Perché ssh avvisa che la mia connessione non è post-quantistica?

OpenSSH 10.1 e versioni successive visualizzano ** WARNING: connection is not using a post-quantum key exchange algorithm. quando lo scambio negoziato non contiene una componente post-quantistica. L'avviso riguarda il server, non il client, perché il client ha offerto un nome post-quantistico e il server non ne ha accettato nessuno. Aggiornare OpenSSH sul server oppure verificare che nessuno abbia imposto una direttiva KexAlgorithms nel relativo file sshd_config escludendo i nomi moderni. Impostare WarnWeakCrypto no nasconde il messaggio, ma lascia la connessione esattamente altrettanto debole.