"WARNING: connection is not using a post-quantum key exchange algorithm": cosa significa

Il messaggio completo

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Compare prima della richiesta di login, su stderr. La connessione prosegue e il codice di uscita non cambia. È iniziato con OpenSSH 10.1, quindi potresti vederlo per la prima volta dopo l'aggiornamento del tuo client, su un server che non è cambiato affatto.

Cosa significa

Lo scambio di chiavi crea il segreto che cifra la sessione. Gli algoritmi classici, come curve25519-sha256, sono sicuri contro i computer di oggi. Un computer quantistico abbastanza grande potrebbe romperli, e qualcuno può registrare ora il traffico cifrato e provarci più tardi. È il "store now, decrypt later" del messaggio.

L'avviso non significa che qualcuno ti stia attaccando, che il tuo login sia oggi esposto a un attacco quantistico o che le tue chiavi vadano sostituite. Ciò che è in gioco è per quanto tempo il contenuto delle tue sessioni deve restare segreto. Password digitate in una sessione o dump di database copiati attraverso di essa sono il genere di cose a cui pensare.

Controllare cosa è stato negoziato

ssh -v user@server true 2>&1 | grep -E 'remote software version|kex: algorithm'

Contro un server che fa comparire l'avviso:

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13
debug1: kex: algorithm: curve25519-sha256@libssh.org

E un buon risultato, senza avviso:

debug1: kex: algorithm: mlkem768x25519-sha256

I nomi post-quantistici contengono mlkem o sntrup. Per vedere cosa supporta il tuo client:

ssh -Q kex | grep -E 'mlkem|sntrup'

Soluzione 1: il server è troppo vecchio

Aggiorna OpenSSH sul server, il che di solito significa aggiornare la distribuzione.

Dispositivi di rete e apparati con una propria implementazione SSH richiedono un aggiornamento del firmware dal produttore. Fino ad allora, o su un server che non puoi modificare, vedi la soluzione 3.

Soluzione 2: un'impostazione toglie gli algoritmi

Un server recente può comunque far comparire l'avviso se una guida di hardening ha elencato a mano KexAlgorithms da prima che questi algoritmi esistessero. Sul server:

sudo sshd -T | grep -i '^kexalgorithms'

Se mlkem768x25519-sha256 non è nell'elenco, trova la riga KexAlgorithms in /etc/ssh/sshd_config o in /etc/ssh/sshd_config.d/ e rimuovila per tornare ai valori predefiniti, oppure aggiungi l'algoritmo. Poi convalida e ricarica. Sui sistemi di tipo Red Hat il servizio si chiama sshd:

sudo sshd -t && sudo systemctl reload ssh

Può esserne la causa anche il tuo client. Controllalo:

ssh -G server | grep -i '^kexalgorithms'

Cerca una riga KexAlgorithms in ~/.ssh/config se quell'elenco non ha nomi post-quantistici.

Per rivedere le altre impostazioni toccate da una guida del genere, vedi come mettere in sicurezza sshd_config.

Soluzione 3: silenziarlo per un host

Quando l'aggiornamento non è possibile e hai accettato il rischio per quell'host, aggiungi questo a ~/.ssh/config:

Match host legacy.example.com
  WarnWeakCrypto no-pq-kex

Limitalo a quell'host, così l'avviso resta utile altrove. Per un solo comando, usa ssh -o WarnWeakCrypto=no-pq-kex user@server. Anche l'opzione -q lo nasconde, ma nasconde anche altri messaggi.

Gli script che leggono stderr, o che considerano un fallimento qualsiasi output su di esso, possono iniziare a fallire dopo l'aggiornamento di un client. Correggi il server, oppure imposta l'opzione per quell'host nella configurazione dello script.

Domande

L'avviso post-quantum è pericoloso?

Non c'è un pericolo immediato. La connessione è cifrata con un algoritmo classico. Il rischio è che il traffico registrato oggi venga decifrato in futuro da un computer quantistico.

Quale versione di OpenSSH fa sparire l'avviso?

Un server con OpenSSH 9.0 o successivo offre sntrup761x25519, e dalla 9.9 anche mlkem768x25519-sha256. Basta uno dei due.

Come tolgo l'avviso per un solo server?

Aggiungi WarnWeakCrypto no-pq-kex in un blocco Match host o Host per quel server in ~/.ssh/config.

Fonti

• Crittografia post-quantistica, OpenSSH
• Note di rilascio di OpenSSH
• ssh_config(5), WarnWeakCrypto
• sshd_config(5), KexAlgorithms

Guide collegate

• Come rendere più sicuro sshd_config: una checklist che puoi provare
• SSH "no matching key exchange method found" o "no matching host key type found": come risolvere
• Il file di configurazione SSH, con esempi
• Come fare il debug di una connessione SSH

Altro in Messaggi di errore

• Tunnel SSH: "bind: Address already in use" e "remote port forwarding failed"
• "channel 3: open failed: administratively prohibited: open failed"
• client_loop: send disconnect: Broken pipe: come evitare che SSH si disconnetta
• ssh: connect to host port 22: Connection refused, come risolvere
• "kex_exchange_identification: read: Connection reset by peer"
• ssh: connect to host port 22: Operation timed out / Connection timed out, come risolvere

Tutte le guide