SSH post-quantique : ce qui change sur Ubuntu

Ce qui a changé avec SSH post-quantique

SSH post-quantique est déjà activé pour la plupart des utilisateurs. Personne n’a eu besoin de le configurer. Un client OpenSSH récent qui communique avec un serveur OpenSSH récent sélectionne par défaut un échange de clés post-quantique hybride. La clé de session résiste ainsi à un attaquant qui enregistre votre trafic aujourd’hui et le déchiffre dans plusieurs années. La protection est réelle, mais sa portée est plus limitée que ne le laisse entendre l’expression « SSH résistant aux ordinateurs quantiques ».

Commençons par deux termes. SSH (secure shell) est le protocole utilisé pour vous connecter à un serveur. L’échange de clés, généralement appelé « kex », est la première étape de chaque connexion SSH : les deux extrémités négocient un secret partagé, puis ce secret chiffre tout ce qui suit. C’est l’échange de clés qui a changé. Rien d’autre.

Ne faites pas confiance à cette page, exécutez les commandes

Tous les noms d’algorithmes ci-dessous proviennent d’une commande que vous pouvez exécuter vous-même. C’est volontaire. Les valeurs par défaut changent avec chaque release d’OpenSSH. Un guide écrit il y a deux ans peut donc mentionner un algorithme que votre machine ne privilégie plus, sans pouvoir vous en informer. Apprenez ces commandes pour ne plus dépendre des articles sur ce sujet, y compris celui-ci.

Commencez par vérifier les fonctionnalités prises en charge par votre build.

ssh -V
ssh -Q kex

ssh -V affiche une ligne de version qui commence par OpenSSH_, suivie du suffixe du paquet Ubuntu et de la version d’OpenSSL. ssh -Q kex affiche un algorithme d’échange de clés par ligne. Avec un build prenant en charge la cryptographie post-quantique, vous trouverez dans cette liste des noms tels que mlkem768x25519-sha256 et sntrup761x25519-sha512@openssh.com, à côté de noms classiques comme curve25519-sha256.

Ce que votre build prend en charge n’est pas ce qu’il propose

C’est la distinction que la plupart des articles omettent. ssh -Q kex répond à une question : que pourrait faire ce binaire ? Il ne répond pas à la question qui vous intéresse : que proposera réellement cette connexion ? Les deux listes sont différentes, et c’est dans l’écart entre elles que les anciennes recommandations causent de vrais problèmes.

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

ssh -G <host> affiche la configuration effective du client pour cet hôte, après application de ~/.ssh/config et /etc/ssh/ssh_config. sshd -T fait de même pour le serveur. Chacun affiche une seule ligne kexalgorithms, dans l’ordre de préférence, et le premier nom de cette ligne correspond au premier choix du côté concerné. C’est cette ligne qui est envoyée sur le réseau.

L’écart n’est pas théorique. OpenSSH 8.5, publié le 2021-03-03, a ajouté sntrup761x25519-sha512@openssh.com et l’a volontairement exclu de la liste par défaut. Dans cette version, ssh -Q kex affiche l’algorithme, contrairement à ssh -G, ce qui signifie que le binaire peut effectuer un échange de clés post-quantique, mais qu’aucune connexion ne le propose.

Lire l’algorithme négocié par votre connexion

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

Entre un client récent et un serveur récent, cette commande affiche :

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 est un algorithme hybride. Il utilise ML-KEM (mécanisme d’encapsulation de clé sur réseau de modules, standardisé par FIPS 203) avec le jeu de paramètres 768, ainsi que Diffie-Hellman sur courbe elliptique X25519. Les deux résultats sont combinés dans la clé de session.

Avec un serveur plus ancien, vous pouvez voir ceci :

debug1: kex: algorithm: curve25519-sha256

Ce nom ne comporte aucune composante post-quantique. curve25519-sha256 utilise uniquement Diffie-Hellman sur courbe elliptique, qu’un ordinateur quantique suffisamment puissant peut casser. C’est la raison du changement de valeur par défaut.

Une règle de négociation explique pourquoi une seule machine ancienne peut limiter une session. Le client envoie sa liste par ordre de préférence, puis le serveur envoie la sienne. L’algorithme choisi est le premier nom de la liste du client qui figure également dans celle du serveur. La préférence du client est prioritaire. C’est donc le plus ancien des deux équipements qui détermine jusqu’où la négociation peut aller dans la liste. Mettre à niveau votre ordinateur portable ne met pas à niveau une session vers un serveur qui n’a jamais pris en charge ML-KEM.

Supprimez grep et ssh -v pour afficher le reste de la négociation, notamment la ligne qui fait l’objet de la section suivante :

debug1: kex: host key algorithm: ssh-ed25519

Quelle version d’OpenSSH a activé par défaut l’échange hybride

Les notes de version amont présentent une séquence claire. Les dates sont plus importantes que les numéros de version, car elles montrent depuis combien de temps cette fonctionnalité fonctionne discrètement.

• 8.5, publiée le 2021-03-03, a ajouté sntrup761x25519-sha512@openssh.com et l’a laissée désactivée par défaut.
• 9.0, publiée le 2022-04-08, l’a activée. Les notes indiquent qu’OpenSSH « utilise par défaut la méthode d’échange de clés hybride Streamlined NTRU Prime + x25519 ». C’est la version avec laquelle un échange de clés post-quantique est devenu le comportement normal.
• 9.9, publiée le 2024-09-19, a ajouté mlkem768x25519-sha256 comme deuxième option. La même version a attribué à l’ancienne méthode son nom enregistré auprès de l’IANA, sntrup761x25519-sha512, si bien que les builds récentes la listent sous les deux appellations.
• 10.0, publiée le 2025-04-09, a fait de mlkem768x25519-sha256 la méthode par défaut pour l’accord de clés.
• 10.1, publiée le 2025-10-06, a ajouté un avertissement côté client lorsqu’une connexion négocie un échange de clés sans composante post-quantique. Ce comportement est contrôlé par l’option WarnWeakCrypto dans ssh_config et il est activé par défaut.

Avril 2022 est la date à retenir. Toute paire de machines utilisant OpenSSH 9.0 ou une version ultérieure effectue un échange de clés post-quantique depuis cette date, sans configuration et sans avertissement pour la personne qui saisit ssh.

Quelle version d’Ubuntu l’inclut

Ubuntu fige une version d’OpenSSH à chaque release, puis y rétroporte les correctifs de sécurité sans modifier son numéro de version. La release d’Ubuntu utilisée détermine donc l’algorithme par défaut. Vérifiez la machine concernée avec ssh -V au lieu de vous fier à une liste. En août 2026, l’archive contient les versions suivantes :

• Ubuntu 22.04 LTS fournit 1:8.9p1, antérieure à la version 9.0 par défaut ; une installation standard négocie donc curve25519-sha256.
• Ubuntu 24.04 LTS fournit 1:9.6p1, postérieure à la version 9.0 et antérieure à la version 9.9 ; son algorithme par défaut est donc sntrup761x25519-sha512@openssh.com et elle ne prend pas en charge ML-KEM.
• Ubuntu 25.10 fournit 1:10.0p1, dont l’algorithme par défaut est mlkem768x25519-sha256.
• Ubuntu 26.04 LTS fournit 1:10.2p1, qui utilise mlkem768x25519-sha256 par défaut et avertit lorsque les connexions ne sont pas post-quantiques.

Examinons une paire réelle de machines. Un ordinateur portable sous 26.04 se connecte à un serveur sous 24.04. Le premier choix du client, mlkem768x25519-sha256, ne figure pas dans la liste du serveur sous 9.6. Le choix post-quantique suivant du client que le serveur prend en charge est sntrup761x25519-sha512@openssh.com, et c’est le nom que ssh -v affiche. L’échange de clés de la session est post-quantique, malgré un serveur compilé en 2024 et sans aucune configuration manuelle.

Le cas de 22.04 fonctionne dans l’autre sens et montre précisément pourquoi ssh -Q kex seul peut induire en erreur. OpenSSH 8.9 connaît le nom sntrup761x25519-sha512@openssh.com ; ssh -Q kex sur cette machine l’affiche donc dans la liste, mais la proposition par défaut l’exclut, et la négociation aboutit à curve25519-sha256. Depuis un client OpenSSH 10.1 ou ultérieur, la connexion l’indique clairement :

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

Cet avertissement concerne le serveur auquel vous vous connectez, pas votre client. La solution consiste à mettre à niveau le serveur. Définir WarnWeakCrypto no supprime le message, sans modifier la connexion.

Pourquoi utiliser un mode hybride, et que signifie « récolter maintenant, déchiffrer plus tard »

La menace est simple. Un attaquant qui peut observer votre trafic enregistre aujourd’hui les données chiffrées et les conserve. Il ne peut pas les lire aujourd’hui. Il les garde jusqu’à ce qu’un ordinateur quantique suffisamment puissant pour casser X25519 existe, puis il les déchiffre. Cette méthode s’appelle harvest now, decrypt later ou store now, decrypt later. Elle ne demande rien d’ingénieux à l’attaquant dans le présent. Il lui faut de l’espace disque et de la patience.

Le chiffrement présente ce problème, contrairement aux signatures, et cette asymétrie détermine tout le reste. Un ciphertext enregistré conserve sa valeur aussi longtemps que les données qu’il contient restent sensibles. Une signature doit seulement rester infalsifiable au moment où elle est vérifiée. Casser un algorithme de signature en 2035 permettrait à quelqu’un d’usurper l’identité d’un serveur en 2035. Cela ne lui permettrait pas de revenir en arrière et de falsifier une connexion de 2026. Il fallait donc corriger d’abord l’échange de clés ; le volet des signatures peut attendre.

Le mode hybride signifie que les deux algorithmes sont exécutés et que leurs deux résultats alimentent la clé de session. Pour récupérer le secret derrière mlkem768x25519-sha256, un attaquant doit casser ML-KEM 768 et X25519. Cette combinaison est délibérée : ML-KEM est beaucoup plus récent que X25519 et a été soumis bien moins longtemps à l’analyse des cryptanalystes. Une faille découverte dans le nouvel algorithme ne vous fait donc pas perdre la protection dont vous disposiez déjà.

Ce qui est protégé et ce qui ne l’est pas

L’échange de clés est protégé. Le secret partagé qui chiffre votre session provient d’un échange hybride. L’enregistrement de cette session effectué aujourd’hui ne deviendra donc pas lisible lorsque les ordinateurs quantiques seront disponibles.

La clé d’hôte n’est pas protégée. La ligne debug1: kex: host key algorithm: ssh-ed25519 désigne une signature classique, comme rsa-sha2-512 et les types ECDSA (elliptic curve digital signature algorithm). Un attaquant disposant d’un ordinateur quantique opérationnel pourrait falsifier cette signature et usurper votre serveur, mais uniquement pendant une connexion active à ce moment-là, et jamais pour du trafic enregistré aujourd’hui.

Votre clé de connexion n’est pas protégée non plus. La clé indiquée dans ~/.ssh/id_ed25519 est le même type de signature classique, et le même raisonnement s’applique. Cette année, la protection de cette clé dépend de l’endroit où elle se trouve et des personnes qui peuvent la lire. Une gestion rigoureuse des clés SSH réduit donc beaucoup plus votre risque réel que le nom d’un algorithme présenté sur cette page.

Vous n’avez rien à faire concernant ces deux clés, car aucune solution de remplacement n’est disponible. OpenSSH a indiqué que la prise en charge des signatures post-quantiques arriverait dans une prochaine release. Tant que cette fonctionnalité n’est pas disponible, OpenSSH ne propose ni type de clé d’hôte post-quantique ni type de clé utilisateur post-quantique, et ssh-keygen ne vous en propose aucun. Un guide qui vous demande d’en générer une décrit un logiciel qui n’existe pas encore.

TLS sur le même serveur est une question distincte, avec une réponse différente. TLS (transport layer security) est le protocole utilisé par votre serveur web sur le port 443. Il repose sur une autre base de code et suit un calendrier différent. Mettre OpenSSH à niveau ne change donc rien à ce sujet. Si vous utilisez un certificat auto-signé pour un service privé sur le même VPS, sa signature et son échange de clés sont déterminés par OpenSSL et votre serveur web. Vous devez donc examiner cette stack séparément.

Ce qu’un opérateur prudent fait maintenant

Maintenez OpenSSH à jour, et arrêtez-vous là. C’est réellement toute la stratégie pour ce problème. sudo apt update && sudo apt upgrade vous maintient sur la version fournie par votre version d’Ubuntu, et passer à une version plus récente d’Ubuntu vous donne une version plus récente d’OpenSSH. Activez les mises à niveau de sécurité automatiques pour appliquer ces correctifs sans avoir à y penser. Compiler OpenSSH depuis les sources pour suivre le nom d’un algorithme est un mauvais compromis, car vous renoncez aux mises à jour de sécurité de la distribution pour le service le plus exposé du serveur. Si vous récupérez quand même les sources, vérifiez le téléchargement avec la somme de contrôle publiée avant de le compiler.

N’écrivez pas manuellement une ligne KexAlgorithms. C’est la seule action qui aggrave systématiquement la situation. Un guide de renforcement datant de 2018 vous donne une liste qui était correcte en 2018. La coller dans sshd_config remplace la liste par défaut au lieu de la compléter. Tous les algorithmes apparus depuis sont alors exclus. Un serveur qui aurait négocié mlkem768x25519-sha256 de lui-même passe donc discrètement à ce qui reste dans la liste imposée. Exécutez sudo sshd -T | grep -i '^kexalgorithms' sur tout serveur dont vous avez hérité. Si cette ligne est plus courte que celle d’une installation neuve de la même version, quelqu’un l’a imposée.

Si vous avez une raison réelle de modifier la liste, complétez-la au lieu de la remplacer. OpenSSH interprète un + placé au début comme un ajout, un - placé au début comme une suppression et un ^ placé au début comme un déplacement en tête de liste.

KexAlgorithms ^mlkem768x25519-sha256

Testez le fichier avant de vous y fier. sudo sshd -t analyse la configuration et n’affiche rien lorsqu’elle est valide. Une ligne KexAlgorithms qui désigne un algorithme absent de la build empêche sshd de démarrer. Sur une machine distante, cela signifie que vous ne pourrez plus vous connecter. Gardez donc une deuxième session ouverte pendant vos modifications. Lorsque les listes des deux côtés n’ont plus d’élément commun, le client l’indique clairement :

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

Considérez le marketing « quantum-safe » comme une affirmation limitée à une seule couche. Lorsqu’un éditeur qualifie un produit de quantum-safe, il décrit la couche qu’il a désignée. Il s’agit généralement d’un échange de clés. Demandez le nom de l’algorithme et le protocole auquel il s’applique. Pour OpenSSH en août 2026, la formulation honnête est que l’échange de clés est post-quantique hybride, tandis que les signatures restent classiques. Toute affirmation plus large doit s’accompagner d’un nom que vous pouvez retrouver dans la sortie de ssh -Q kex.

Continuez à appliquer les mesures de base. Un échange de clés post-quantique ne change rien à un mot de passe facile à deviner ni à une clé privée copiée sur un ordinateur portable ensuite volé. Ce sont ces éléments qui permettent réellement de compromettre des serveurs. Le renforcement SSH standard sur un VPS reste donc l’essentiel. Si les étapes de négociation présentées ici ne vous étaient pas familières, la page ce que fait SSH lors d’une connexion décrit les étapes supposées connues ici.

FAQ

Ma connexion SSH est-elle déjà post-quantique ?

Exécutez ssh -v yourserver 2>&1 | grep 'kex: algorithm' et lisez le nom qu’il affiche. mlkem768x25519-sha256 et sntrup761x25519-sha512@openssh.com sont des échanges hybrides post-quantiques. curve25519-sha256, ecdh-sha2-nistp256 et tout nom diffie-hellman-group sont classiques. Les deux extrémités doivent utiliser une version qui propose un nom post-quantique, car la négociation sélectionne le premier choix du client que le serveur prend également en charge. La machine la plus ancienne fixe donc la limite.

Quelle version d’OpenSSH a rendu l’échange de clés post-quantique disponible par défaut ?

OpenSSH 9.0, publiée le 2022-04-08, a défini sntrup761x25519-sha512@openssh.com comme échange de clés par défaut. OpenSSH 9.9, publiée le 2024-09-19, a ajouté mlkem768x25519-sha256, puis OpenSSH 10.0, publiée le 2025-04-09, a défini ce dernier comme échange par défaut. OpenSSH 10.1, publiée le 2025-10-06, a commencé à afficher un avertissement lorsqu’une connexion ne négocie aucun des deux. Vérifiez le comportement de votre propre build avec ssh -Q kex et ssh -G <host>, car votre version d’Ubuntu détermine lesquels sont disponibles.

Dois-je générer une clé SSH post-quantique ?

Non, car OpenSSH ne propose aucun type de clé de ce genre. Pour l’instant, les mécanismes post-quantiques concernent l’échange de clés. Celui-ci ne nécessite ni fichier de clé de votre part ni configuration particulière. Les clés d’hôte et les clés de connexion utilisent toujours des signatures classiques, comme Ed25519 et RSA. Le projet amont a indiqué que les signatures post-quantiques seraient intégrées dans une version future. Continuez à utiliser une clé Ed25519 et protégez son emplacement de stockage.

Pourquoi ssh indique-t-il que ma connexion n’est pas post-quantique ?

OpenSSH 10.1 et les versions ultérieures affichent ** WARNING: connection is not using a post-quantum key exchange algorithm. lorsque l’échange négocié ne comporte aucun composant post-quantique. L’avertissement concerne le serveur, pas votre client, car votre client a proposé un nom post-quantique et le serveur n’en a accepté aucun. Mettez à niveau l’OpenSSH du serveur ou vérifiez que personne n’a imposé une directive KexAlgorithms dans son sshd_config en excluant les noms modernes. Définir WarnWeakCrypto no masque le message, mais la connexion reste exactement aussi faible qu’auparavant.