SSH post-quantique : ce qui change sur Ubuntu

Ce qui a changé avec SSH post-quantique

SSH post-quantique est déjà activé par défaut pour la plupart des utilisateurs. Personne n’a eu besoin de le configurer. Un client OpenSSH récent qui se connecte à 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 pour le déchiffrer dans plusieurs années. Cette protection est réelle, mais sa portée est plus limitée que ne le laisse entendre l’expression « SSH résistant aux attaques 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 toute connexion SSH : les deux extrémités négocient un secret partagé, puis ce secret chiffre tout le trafic 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

Chaque nom d’algorithme ci-dessous provient d’une commande que vous pouvez exécuter vous-même. C’est volontaire. Les valeurs par défaut évoluent avec chaque version 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 le signaler. Apprenez ces commandes et vous n’aurez plus besoin d’articles sur le sujet, y compris celui-ci.

Commencez par vérifier ce que votre build sait faire.

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. Sur 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 : quelles opérations ce binaire pourrait-il effectuer ? Il ne répond pas à la question qui vous intéresse : qu’est-ce que cette connexion va réellement proposer ? 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. Chacune affiche une seule ligne kexalgorithms, dans l’ordre de préférence, et le premier nom de cette ligne est le premier choix du côté concerné. C’est cette ligne qui est transmise 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, tout en l’excluant volontairement 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és fondé sur les réseaux euclidiens, standardisé par FIPS 203) avec le jeu de paramètres 768, ainsi que l’échange de clés 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 obtenir ceci :

debug1: kex: algorithm: curve25519-sha256

Cet algorithme ne comporte aucune composante post-quantique. curve25519-sha256 est uniquement un échange de clés Diffie-Hellman sur courbe elliptique. Un ordinateur quantique suffisamment puissant pourrait le casser. C’est la raison pour laquelle l’algorithme par défaut a changé.

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. 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. Le plus ancien des deux équipements détermine donc jusqu’où la négociation peut descendre dans la liste. Mettre à niveau votre ordinateur portable ne met pas à niveau une session vers un serveur qui ne connaît pas ML-KEM.

ssh -v est utile à connaître au-delà de cette seule ligne, car c’est également dans cette sortie que vous pouvez identifier la cause d’une erreur Permission denied (publickey) lorsqu’une connexion est refusée.

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 rendu l’échange hybride disponible par défaut

Les notes de version amont établissent 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.

• La version 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.
• La version 9.0, publiée le 2022-04-08, l’a activée. Les notes indiquent qu’OpenSSH allait « utiliser par défaut la méthode d’échange de clés hybride Streamlined NTRU Prime + x25519 ». C’est dans cette version que l’échange de clés post-quantique est devenu le fonctionnement normal.
• La version 9.9, publiée le 2024-09-19, a ajouté mlkem768x25519-sha256 comme deuxième option. Cette même version a attribué à l’ancienne méthode son nom enregistré auprès de l’IANA, sntrup761x25519-sha512. Les versions plus récentes l’affichent donc sous les deux appellations.
• La version 10.0, publiée le 2025-04-09, a défini mlkem768x25519-sha256 comme méthode par défaut pour l’accord de clés.
• La version 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 composant 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. Depuis cette date, toute paire de machines exécutant OpenSSH 9.0 ou une version ultérieure effectue un échange de clés post-quantique, sans configuration particulière et sans avertissement pour la personne qui saisit ssh.

Version d’Ubuntu concernée

Ubuntu fige une version d’OpenSSH lors de la publication d’une version, puis y rétroporte les correctifs de sécurité sans modifier son numéro de version. La version 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érieur au comportement par défaut de la version 9.0 ; une installation standard négocie donc curve25519-sha256.
• Ubuntu 24.04 LTS fournit 1:9.6p1, postérieur à la version 9.0 et antérieur à la version 9.9 ; son choix par défaut est donc sntrup761x25519-sha512@openssh.com et il ne prend pas en charge ML-KEM.
• Ubuntu 25.10 fournit 1:10.0p1, dont le choix 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.

Examinez une paire réelle de machines. Un ordinateur portable sous Ubuntu 26.04 se connecte à un serveur sous Ubuntu 24.04. Le premier choix du client, mlkem768x25519-sha256, ne figure pas dans la liste du serveur sous OpenSSH 9.6. Le choix post-quantique suivant du client qui est pris en charge par le serveur est sntrup761x25519-sha512@openssh.com ; c’est donc le nom que ssh -v affiche. L’échange de clés de la session est post-quantique, bien que le serveur ait été construit en 2024, sans aucune configuration supplémentaire.

Le cas d’Ubuntu 22.04 produit le résultat inverse et montre précisément pourquoi ssh -Q kex est trompeur lorsqu’il est utilisé seul. OpenSSH 8.9 connaît le nom sntrup761x25519-sha512@openssh.com ; ssh -Q kex affiche donc ce nom sur cette machine. Cependant, la proposition par défaut l’exclut, et la négociation utilise finalement curve25519-sha256. Avec un client OpenSSH 10.1 ou ultérieur, la connexion l’indique :

** 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, et non 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 « harvest now, decrypt later »

La menace est simple. Un attaquant qui peut voir votre trafic enregistre aujourd’hui les octets chiffrés et les stocke. Il ne peut pas les lire aujourd’hui. Il les conserve jusqu’à ce qu’un ordinateur quantique suffisamment puissant pour casser X25519 existe, puis il les lit. Cette méthode est appelée harvest now, decrypt later, ou store now, decrypt later. Elle ne demande rien d’ingénieux à l’attaquant dans l’immédiat. Il lui faut de l’espace disque et de la patience.

Ce problème concerne le chiffrement, mais pas les signatures, et cette asymétrie détermine tout le reste. Un texte chiffré enregistré conserve sa valeur tant 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 permettra à quelqu’un d’usurper l’identité d’un serveur en 2035. Cela ne lui permettra pas de revenir en arrière et de falsifier une connexion de 2026. L’échange de clés devait donc être corrigé en priorité, tandis que la partie liée aux signatures peut attendre.

Le mode hybride exécute les deux algorithmes et utilise les deux résultats pour produire la clé de session. Pour retrouver le secret derrière mlkem768x25519-sha256, un attaquant doit casser ML-KEM 768 et X25519. Cette association est volontaire : ML-KEM est beaucoup plus récent que X25519 et a été beaucoup moins longtemps étudié par les 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. Un enregistrement de cette session effectué aujourd’hui ne deviendra donc pas lisible à l’arrivée des ordinateurs quantiques.

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, tout comme rsa-sha2-512 et les types ECDSA (algorithme de signature numérique à courbe elliptique). Un attaquant disposant d’un ordinateur quantique opérationnel pourrait falsifier cette signature et usurper l’identité de votre serveur, mais uniquement pendant une connexion active à ce moment-là, et jamais contre du trafic enregistré aujourd’hui.

Votre clé de connexion n’est pas protégée non plus. La clé de ~/.ssh/id_ed25519 est du même type de signature classique, et le même raisonnement s’applique. Cette année, la protection de cette clé dépend de son emplacement et des personnes qui peuvent la lire. Une gestion rigoureuse des clés SSH réduit donc davantage votre risque réel que n’importe quel nom d’algorithme présenté sur cette page.

Vous n’avez rien à faire à ce sujet, car il n’existe encore rien vers quoi basculer. OpenSSH a indiqué que la prise en charge des signatures post-quantiques arriverait dans une prochaine version. Tant qu’elle n’est pas publiée, OpenSSH ne propose aucun type de clé d’hôte post-quantique ni aucun type de clé utilisateur post-quantique, et ssh-keygen n’en propose aucun non plus. 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 (sécurité de la couche transport) 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 de ce côté. 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. Il faut donc analyser cette pile 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 le passage à une version plus récente d’Ubuntu vous donne une version plus récente d’OpenSSH. L’activation des mises à niveau de sécurité automatiques permet d’appliquer ces correctifs sans devoir y penser. Compiler OpenSSH depuis les sources pour obtenir un nom d’algorithme plus récent 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 téléchargez malgré tout les sources, vérifiez le téléchargement avec la somme de contrôle publiée avant de le compiler.

N’écrivez pas vous-même une ligne KexAlgorithms. C’est la seule action qui aggrave systématiquement la situation. Un guide de renforcement de la sécurité datant de 2018 vous fournit une liste qui était correcte en 2018, et son collage dans sshd_config remplace la liste par défaut au lieu de la compléter. Tous les algorithmes apparus depuis sont désormais 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 nouvelle installation 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 + en début de liste comme un ajout, un - en début de liste comme une suppression et un ^ en début de liste comme un déplacement au début.

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 nomme un algorithme absent de la compilation empêche sshd de démarrer. Sur un serveur distant, vous ne pouvez alors plus vous reconnecter. Gardez donc une deuxième session ouverte pendant l’opération. 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 les arguments marketing sur la « sécurité post-quantique » comme une affirmation limitée à une seule couche. Lorsqu’un fournisseur qualifie un produit de sûr face aux ordinateurs quantiques, il décrit la couche qu’il a nommé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 exacte est la suivante : l’échange de clés est hybride et post-quantique, tandis que les signatures restent classiques. Toute affirmation plus large doit être accompagnée d’un nom que vous pouvez retrouver dans la sortie de ssh -Q kex.

Continuez à effectuer les tâches moins visibles. Un échange de clés post-quantique ne protège pas contre un mot de passe facile à deviner ni contre une clé privée copiée sur un ordinateur portable ensuite volé. Ce sont ces éléments qui permettent réellement de prendre le contrôle des serveurs. Le renforcement SSH standard sur un VPS reste donc l’essentiel. Si les étapes de négociation décrites ici ne vous étaient pas familières, ce que fait SSH lors d’une connexion présente les étapes supposées connues dans cette page.

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’elle 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 définit donc la limite.

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

OpenSSH 9.0, publiée le 2022-04-08, a activé sntrup761x25519-sha512@openssh.com par défaut pour l’échange de clés. OpenSSH 9.9, publiée le 2024-09-19, a ajouté mlkem768x25519-sha256, puis OpenSSH 10.0, publiée le 2025-04-09, l’a activé par défaut à sa place. 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 ceux dont vous disposez.

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

Non, car OpenSSH ne propose pas de type de clé de ce genre. Les évolutions post-quantiques concernent pour l’instant l’échange de clés. Celui-ci n’a besoin d’aucun fichier de clé de votre part ni d’aucune configuration. 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 arriveraient dans une future version. 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 aucune composante post-quantique. L’avertissement concerne le serveur, et non 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 ligne KexAlgorithms dans son sshd_config, ce qui exclurait les noms modernes. Définir WarnWeakCrypto no masque le message, mais la connexion reste exactement aussi faible qu’avant.