SSH post-quantistico su Ubuntu: cosa è cambiato

Cosa è cambiato nell’SSH post-quantistico

L’SSH post-quantistico è già attivo per la maggior parte degli utenti e non è necessario configurarlo manualmente. 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 alcuni anni. La protezione è reale, ma più limitata di quanto lasci intendere l’espressione "SSH a prova di computer quantistici".

Prima servono due definizioni. SSH (secure shell) è il protocollo usato per accedere a un server. Lo scambio di chiavi, generalmente indicato 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 deriva da un comando che puoi eseguire personalmente. È intenzionale. Il valore predefinito cambia con ogni release di OpenSSH. Una guida scritta due anni fa può quindi indicare un algoritmo che il tuo computer non preferisce più, senza avere modo di informartene. Impara 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 della 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 classici come curve25519-sha256.

Ciò che supporta la build non corrisponde a ciò che propone

Questa è la distinzione che la maggior parte degli articoli tralascia. ssh -Q kex risponde a una domanda: che cosa potrebbe fare questo binario. Non risponde alla domanda che interessa davvero: che cosa proporrà effettivamente questa connessione. Le due liste sono diverse e il divario tra loro è il punto in cui le indicazioni obsolete causano problemi reali.

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

ssh -G <host> visualizza 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 sola riga kexalgorithms in 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 lasciandolo intenzionalmente fuori dall'elenco predefinito. In quella versione ssh -Q kex mostra l'algoritmo, mentre ssh -G non lo mostra; questo significa che il binario supporta 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, è possibile vedere invece:

debug1: kex: algorithm: curve25519-sha256

Questo nome non include una componente post-quantistica. curve25519-sha256 usa soltanto Diffie-Hellman su curva ellittica e un computer quantistico di grandi dimensioni può comprometterlo. Questo è il motivo per cui l'impostazione predefinita è cambiata.

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 proprio e viene scelto il primo nome nell'elenco del client che compare anche in quello del server. Prevale la preferenza del client, quindi l'endpoint meno aggiornato dei due determina fino a quale posizione dell'elenco si può arrivare. Aggiornare il laptop non aggiorna una sessione verso un server che non ha mai supportato ML-KEM.

Rimuovi grep e ssh -v per visualizzare 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 predefinito lo scambio ibrido

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 opera senza attirare attenzione.

• La versione 8.5, rilasciata il 2021-03-03, ha aggiunto sntrup761x25519-sha512@openssh.com e lo ha lasciato disabilitato per impostazione predefinita.
• La versione 9.0, rilasciata il 2022-04-08, lo ha attivato. Le note specificano che OpenSSH avrebbe utilizzato per impostazione predefinita "use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default". Questa è la release in cui lo scambio di chiavi post-quantistico è diventato il comportamento standard.
• La versione 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, quindi le build più recenti lo elencano con entrambe le denominazioni.
• La versione 10.0, rilasciata il 2025-04-09, ha reso mlkem768x25519-sha256 il metodo predefinito per l'accordo sulle chiavi.
• La versione 10.1, rilasciata il 2025-10-06, ha aggiunto un avviso client quando una connessione negozia uno scambio di 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 effettua da allora uno scambio di chiavi post-quantistico, senza configurazione e senza alcun annuncio alla persona che digita ssh.

Quale release di Ubuntu lo include

Ubuntu blocca una versione di OpenSSH al momento del rilascio, quindi vi applica le correzioni di sicurezza tramite backport senza modificare il numero di versione. Il release di Ubuntu in esecuzione determina quindi l'algoritmo predefinito. Controlla la macchina interessata 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 al default introdotto 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 mostra un avviso per le connessioni che non usano uno scambio di chiavi post-quantum.

Consideriamo 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 la versione 9.6. La successiva scelta post-quantum del client disponibile anche sul server è sntrup761x25519-sha512@openssh.com; questo è il nome riportato da ssh -v. Lo scambio di chiavi della sessione è quindi post-quantum, anche se il server è stato compilato nel 2024 e nessuno ha configurato nulla.

Nel caso di Ubuntu 22.04 avviene il contrario, e questo mostra esattamente perché ssh -Q kex, da solo, può trarre in inganno. OpenSSH 8.9 conosce il nome sntrup761x25519-sha512@openssh.com, quindi ssh -Q kex su quella macchina lo elenca. Tuttavia, la proposta predefinita lo esclude e la negoziazione seleziona curve25519-sha256. Da un client OpenSSH 10.1 o più recente, 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.

L'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’ibrido e cosa significa «raccogliere ora, decrittografare 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 finché non esiste un computer quantistico abbastanza grande da violare X25519, quindi li legge. Questa tecnica è chiamata harvest now, decrypt later oppure store now, decrypt later. Non richiede particolare abilità da parte dell’attaccante nel presente. Richiede spazio su disco e pazienza.

Questo problema riguarda la cifratura, ma non le firme, e questa asimmetria determina tutto il resto. Un testo cifrato registrato conserva il proprio valore finché i dati che contiene rimangono sensibili. Una firma deve essere non falsificabile soltanto 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 consentirebbe di tornare indietro e falsificare un accesso del 2026. Per questo era necessario intervenire prima sullo scambio delle chiavi, mentre il lato delle firme può attendere.

Ibrido significa che entrambi gli algoritmi vengono eseguiti ed entrambi i risultati alimentano la 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 sottoposto all’analisi degli esperti di crittoanalisi. Una vulnerabilità scoperta nel nuovo algoritmo non elimina quindi la protezione già disponibile.

Cosa è protetto e cosa non lo è

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

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

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

Non è necessario intervenire su nessuno dei due aspetti, perché non esiste ancora un'alternativa a cui passare. OpenSSH ha dichiarato che il supporto alle firme post-quantistiche arriverà in una versione futura. Fino a quel momento, OpenSSH non dispone di un tipo di chiave host post-quantistico né di un tipo di chiave utente post-quantistico, e ssh-keygen non ne offre alcuno. Una guida che indica di generarne uno 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 usato dal web server sulla porta 443 e si basa su un codice sorgente diverso, con una pianificazione distinta. Aggiornare OpenSSH non cambia nulla in questo ambito. Se esegui un certificato autofirmato per un servizio privato sullo stesso VPS, la firma e lo scambio di chiavi dipendono da OpenSSL e dal web server. Devi quindi valutare quello stack separatamente.

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 il sistema sulla versione distribuita con la release di Ubuntu in uso; per passare a una versione più recente di OpenSSH devi aggiornare Ubuntu. Attivando gli aggiornamenti di sicurezza automatici le patch vengono applicate senza doverlo ricordare. Compilare OpenSSH dal codice sorgente per inseguire il nome di un algoritmo è un compromesso svantaggioso, perché rinunci agli aggiornamenti di sicurezza della distribuzione per il servizio più esposto del sistema. 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 il problema in modo affidabile. Una guida all'hardening del 2018 fornisce un elenco corretto nel 2018; incollarlo in sshd_config sostituisce l'elenco predefinito invece di aggiungervi elementi. Ogni algoritmo introdotto da allora viene escluso, quindi un server che avrebbe negoziato autonomamente mlkem768x25519-sha256 passa senza segnalarlo a qualunque algoritmo sia rimasto 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 all'inizio.

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 indica un algoritmo non disponibile nella build impedisce l'avvio di sshd; su un sistema remoto questo significa che non puoi più accedere, quindi mantieni aperta una seconda sessione mentre lavori. Quando gli elenchi dei due lati non hanno più elementi in comune, il client lo indica 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 "quantum-safe" come un'affermazione relativa a un solo livello. Quando un fornitore definisce un prodotto quantum-safe, descrive il livello che ha indicato, che di solito è uno scambio di chiavi. Chiedi il nome dell'algoritmo e il protocollo a cui si applica. Per OpenSSH, ad agosto 2026, la formulazione corretta è che lo scambio di chiavi è post-quantum ibrido, mentre le firme sono classiche. Qualunque affermazione più ampia dovrebbe essere accompagnata da un nome che puoi trovare nell'output di ssh -Q kex.

Continua a curare anche gli aspetti meno appariscenti. Uno scambio di chiavi post-quantum non risolve una password facile da indovinare né 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 resta l'intervento più importante. Se le fasi di negoziazione descritte 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?

Esegui ssh -v yourserver 2>&1 | grep 'kex: algorithm' e leggi 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 a sua volta il valore predefinito. OpenSSH 10.1, rilasciato il 2025-10-06, ha iniziato a mostrare un avviso quando la connessione non ne negozia nessuno dei due. Verifica il comportamento della tua build con ssh -Q kex e ssh -G <host>, perché è la release di Ubuntu installata a determinare quali di questi nomi sono disponibili.

Devo generare una chiave SSH post-quantistica?

No, perché OpenSSH non dispone di questo tipo di chiave. Finora il lavoro post-quantistico riguarda lo scambio di chiavi, che non richiede file di chiavi da parte tua né alcuna configurazione. 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 saranno disponibili in una release futura. Continua a usare una chiave Ed25519 e proteggi adeguatamente la posizione in cui è 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. Aggiorna OpenSSH sul server oppure verifica che nessuno abbia impostato una direttiva KexAlgorithms nel relativo sshd_config, escludendo i nomi moderni. Impostare WarnWeakCrypto no nasconde il messaggio, ma lascia la connessione esattamente vulnerabile come prima.