WardtermClient SSH
FR
Télécharger

"WARNING: connection is not using a post-quantum key exchange algorithm" : ce que cela signifie

Votre client OpenSSH, en version 10.1 ou plus récente, a négocié un échange de clés classique avec ce serveur, parce que le serveur, ou un réglage, ne propose rien de post-quantique. La connexion fonctionne et elle est chiffrée. Le risque est que le trafic enregistré soit déchiffré dans des années par un ordinateur quantique. La vraie solution est OpenSSH 9.0 ou plus récent sur le serveur, idéalement 9.9 ou plus. Si vous acceptez le risque pour un hôte, faites taire l'avertissement pour lui avec WarnWeakCrypto no-pq-kex.

Mis à jour le . Reproduit avec OpenSSH 10.3 sur macOS face à un vrai serveur OpenSSH 6.6 sous Ubuntu 14.04, et face à OpenSSH 10.0 sous Debian 13 limité aux algorithmes classiques. L'avertissement et WarnWeakCrypto ont été revérifiés avec OpenSSH 10.6 sous Alpine.

Le message complet

** 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

Il apparaît avant l'invite de connexion, sur stderr. La connexion se poursuit, et le code de sortie ne change pas. Il existe depuis OpenSSH 10.1 : vous pouvez donc le voir pour la première fois après la mise à jour de votre client, sur un serveur qui n'a pas changé du tout.

Ce que cela signifie

L'échange de clés crée le secret qui chiffre la session. Les algorithmes classiques, comme curve25519-sha256, sont sûrs face aux ordinateurs d'aujourd'hui. Un ordinateur quantique assez puissant pourrait les casser, et quelqu'un peut enregistrer le trafic chiffré dès maintenant pour essayer plus tard. C'est le "store now, decrypt later" du message.

L'avertissement ne signifie pas que quelqu'un vous attaque, que votre connexion est exposée aujourd'hui à une attaque quantique, ni que vos clés doivent être remplacées. L'enjeu est la durée pendant laquelle le contenu de vos sessions doit rester secret. Les mots de passe saisis dans une session ou les dumps de base de données copiés à travers elle sont le genre de choses à envisager.

Vérifier ce qui a été négocié

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

Face à un serveur qui déclenche l'avertissement :

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

Et un bon résultat, sans avertissement :

debug1: kex: algorithm: mlkem768x25519-sha256

Les noms post-quantiques contiennent mlkem ou sntrup. Pour voir ce que prend en charge votre propre client :

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

Solution 1 : le serveur est trop ancien

Mettez OpenSSH à jour sur le serveur, ce qui signifie en général mettre à jour la distribution.

Version du serveurPrise en charge post-quantique
Antérieure à 9.0Pas par défaut
9.0 et suivantessntrup761x25519-sha512@openssh.com, activé par défaut, aussi nommé sntrup761x25519-sha512 depuis la 9.9
9.9 et suivantesAussi mlkem768x25519-sha256
10.0 et suivantesmlkem768x25519-sha256 préféré par défaut

Les équipements réseau et les appliances qui ont leur propre implémentation SSH demandent une mise à jour du firmware par le constructeur. D'ici là, ou sur un serveur que vous ne pouvez pas modifier, voir la solution 3.

Solution 2 : un réglage retire les algorithmes

Un serveur récent peut quand même déclencher l'avertissement si un guide de durcissement a listé KexAlgorithms à la main, à une époque où ces algorithmes n'existaient pas. Sur le serveur :

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

Si mlkem768x25519-sha256 n'est pas dans la liste, trouvez la ligne KexAlgorithms dans /etc/ssh/sshd_config ou dans /etc/ssh/sshd_config.d/, et supprimez-la pour revenir aux valeurs par défaut, ou ajoutez l'algorithme. Puis validez et rechargez. Sur les systèmes de type Red Hat, le service s'appelle sshd :

sudo sshd -t && sudo systemctl reload ssh

Votre client peut aussi en être la cause. Vérifiez-le :

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

Cherchez une ligne KexAlgorithms dans ~/.ssh/config si cette liste ne contient aucun nom post-quantique.

Pour revoir les autres réglages qu'un tel guide a pu modifier, voir comment durcir sshd_config.

Solution 3 : faire taire l'avertissement pour un hôte

Quand la mise à jour est impossible et que vous avez accepté le risque pour cet hôte, ajoutez ceci à ~/.ssh/config :

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

Limitez-le à cet hôte, pour que l'avertissement reste utile ailleurs. Pour une seule commande, utilisez ssh -o WarnWeakCrypto=no-pq-kex user@server. L'option -q le masque aussi, mais elle masque d'autres messages également.

Les scripts qui lisent stderr, ou qui considèrent toute sortie dessus comme un échec, peuvent se mettre à échouer après une mise à jour du client. Corrigez le serveur, ou définissez l'option pour cet hôte dans la configuration du script.

Questions

L'avertissement post-quantique est-il dangereux ?

Pas de danger immédiat. La connexion est chiffrée avec un algorithme classique. Le risque est que le trafic enregistré aujourd'hui soit déchiffré plus tard par un ordinateur quantique.

Quelle version d'OpenSSH fait disparaître l'avertissement ?

Un serveur en OpenSSH 9.0 ou plus récent propose sntrup761x25519, et à partir de 9.9 aussi mlkem768x25519-sha256. L'un ou l'autre suffit.

Comment désactiver l'avertissement pour un seul serveur ?

Ajoutez WarnWeakCrypto no-pq-kex dans un bloc Match host ou Host propre à ce serveur dans ~/.ssh/config.

Sources

Autres guides : Messages d'erreur

Tous les guides