Si vous avez déjà vu ce message, vous savez sans doute de quel protocole parle cet article. Depuis octobre 2025, OpenSSH l’affiche chaque fois qu’un serveur ne parvient pas à négocier un échange de clés post-quantique. La plupart des entreprises utilisent SSH pour administrer leurs machines et transférer des fichiers entre elles. C’est précisément ce trafic qu’un attaquant «harvest-now-decrypt-later» cherche à enregistrer aujourd’hui.

OpenSSH propose un échange de clés post-quantique par défaut depuis avril 2022. Quatre ans plus tard, la plupart des serveurs ne prennent toujours en charge aucun échange de clés post-quantique. En mai 2026, Forescout a analysé 160 millions de serveurs SSH exposés sur Internet : seuls 12 % en supportaient un. Ce troisième article de notre série sur la PQC couvre les deux chantiers de la migration de SSH, l’échange de clés et l’authentification, et mesure ce que coûte chacun.

Le chiffrement fonctionne comme pour TLS. Le client et le serveur établissent d’abord un secret partagé de manière sécurisée, puis chiffrent tout avec un chiffrement symétrique comme AES ou ChaCha20. Cette partie résiste déjà aux attaques quantiques. L’échange de clés et les signatures, eux, n’y résistent pas. Avec un ordinateur quantique cryptographiquement pertinent, quiconque ayant enregistré une session peut retrouver le secret partagé et la déchiffrer. La même machine peut aussi falsifier des signatures : un attaquant peut alors se faire passer pour votre serveur ou se connecter à la place de l’un de vos utilisateurs.

SSH échange les clés différemment de TLS 1.3. Les deux parties envoient d’abord un message KEXINIT qui liste les algorithmes qu’elles prennent en charge, notamment pour l’échange de clés et pour la clé d’hôte («host key»). Pour chaque catégorie, c’est le premier algorithme de la liste du client également pris en charge par le serveur qui est retenu. Ce n’est qu’ensuite que le client envoie sa moitié de l’échange de clés. Il n’envoie donc jamais de «key share» post-quantique à un serveur qui ne le supporte pas.

OpenSSH 10.0 a fait de mlkem768x25519-sha256 l’échange de clés par défaut, avec la même association de X25519 et de ML-KEM-768 que dans TLS. Il remplace sntrup761x25519-sha512, l’échange post-quantique par défaut d’OpenSSH depuis 2022, qui n’est pas un standard du NIST.

Les signatures ont suivi en octobre 2026, quand OpenSSH 10.6 a activé ssh-mldsa44-ed25519. Chaque signature associe une signature ML-DSA-44 à une signature Ed25519, et les deux doivent être valides. Les serveurs peuvent l’utiliser pour leur clé d’hôte, et les utilisateurs pour se connecter.

Ce sont les signatures qui coûtent le plus : près de 40 fois leur taille classique. Dans TLS, c’est un vrai problème, car le serveur envoie toute une chaîne de certificats et chaque certificat porte sa propre clé publique et sa propre signature. Par défaut, SSH n’utilise pas de chaîne de certificats. Chaque partie envoie une clé et une signature, et le surcoût reste limité. C’est pourquoi les signatures post-quantiques sont déjà utilisables dans SSH, alors que le web attend les Merkle Tree Certificates.

Les signatures hybrides sont toutefois plus contestées que l’échange de clés hybride. Filippo Valsorda estime que les signatures composites ajoutent de la complexité pour un gain minime, ML-DSA étant assez mûr pour être utilisé seul. OpenSSH a malgré tout livré la version composite. C’est celle que vos outils prendront en charge, et donc celle à déployer pour SSH.

Nous avons mesuré de vraies connexions SSH entre le même client et le même serveur, chaque fois sur le même chemin réseau. Les tailles et les durées couvrent tout, du handshake TCP jusqu’au moment où l’utilisateur est connecté. L’échange de clés et les signatures migrent de manière indépendante, nous les avons donc mesurés séparément.

Les clés d’hôte et d’utilisateur restent en Ed25519. Nous avons seulement activé ou désactivé l’échange de clés hybride de chaque côté, ce qui donne les mêmes quatre configurations que dans notre article sur TLS :

• Classique. Aucune des deux parties ne prend en charge mlkem768x25519-sha256.
• Client seul. Le client le propose et le serveur ne le prend pas en charge.
• Serveur seul. L’inverse.
• Les deux PQC. Les deux parties le prennent en charge, et c’est lui qu’elles négocient.

L’échange de clés hybride ajoute 2,6 Ko et fait passer le handshake de 6,0 Ko à 8,6 Ko, ce qui correspond à ce qu’on attend de la «key share» et du chiffré ML-KEM.

Quand une seule partie prend en charge l’hybride, SSH évite le surcoût que subit TLS. Les deux parties listent leurs algorithmes dans KEXINIT avant que quiconque n’envoie de «key share». Un client PQC n’envoie donc jamais sa «key share» de 1,2 Ko à un serveur classique. Les seuls octets en plus, environ 80, correspondent aux noms des algorithmes supplémentaires listés dans KEXINIT. Cette prudence a toutefois un prix : elle coûte à SSH un aller-retour réseau supplémentaire à chaque connexion, PQC ou non, alors que TLS 1.3 envoie sa «key share» dès le premier message. Mais pour la transition PQC, cela signifie que vous pouvez activer l’hybride sur les clients et les serveurs dans n’importe quel ordre, sans que personne n’en paie le prix entre-temps.

La durée ne bouge pas. Sur un bon réseau, les quatre configurations terminent à moins de 3 ms d’écart, ce qui reste dans le bruit de mesure. Un Wi-Fi dégradé n’y change rien non plus. Contrairement à TLS, SSH a besoin de nombreux allers-retours avant que l’utilisateur soit connecté, et chacun ajoute son propre délai. Quelques millisecondes de plus se perdent donc dans le bruit.

Avec l’échange de clés hybride activé, nous avons passé les clés en ssh-mldsa44-ed25519 : d’abord la clé utilisateur, puis la clé d’hôte, puis les deux. Les cas mixtes reflètent une vraie migration. La clé d’hôte est la partie facile. Un administrateur en génère une par serveur, et tout client à jour peut la vérifier sans posséder lui-même de clé hybride. Les clés utilisateur prennent plus de temps, car chaque utilisateur doit en créer une et l’ajouter sur chaque serveur auquel il se connecte.

Une clé utilisateur ssh-mldsa44-ed25519 fait passer le handshake de 8,6 Ko à 15,3 Ko, une clé d’hôte hybride le porte à 14,0 Ko, et les deux à 20,7 Ko, soit 2,4 fois la taille avec des clés Ed25519.

Pourquoi une clé utilisateur post-quantique coûte-t-elle plus cher qu’une clé d’hôte ? Chaque partie n’envoie qu’une signature, mais sa clé publique traverse le réseau plusieurs fois. La clé utilisateur est envoyée trois fois avant la connexion, contre deux pour la clé d’hôte : une fois par le serveur, et une fois par le client pour lier la connexion à ce serveur. Une troisième copie de la clé d’hôte suit juste après la connexion, lorsque le serveur partage ses clés d’hôte pour que le client puisse mettre à jour son known_hosts. Comme nous arrêtons la mesure à la connexion, elle n’est pas comptée ici.

La durée augmente aussi. Des clés post-quantiques des deux côtés ajoutent environ 10 ms au handshake sur un bon réseau, et 20 ms sur un Wi-Fi dégradé. Comme pour TLS, le coût vient des paquets supplémentaires, pas du temps de calcul des algorithmes post-quantiques. Chaque paquet supplémentaire donne aux pertes et à la gigue une chance de plus de ralentir la connexion.

Les signatures peuvent attendre. Une session enregistrée peut être déchiffrée des années plus tard, mais une signature falsifiée n’est utile à un attaquant que pendant une connexion en cours, et seulement une fois qu’un ordinateur quantique existe. La migration des signatures demande plus de travail. Les administrateurs doivent générer une clé d’hôte hybride sur chaque serveur. Chaque utilisateur doit générer une clé hybride, l’ajouter sur chaque machine à laquelle il se connecte et, surtout, supprimer ses anciennes clés classiques de ces serveurs.

Ce nettoyage est essentiel. Contrairement aux certificats TLS, les clés SSH n’expirent pas par défaut. Une ancienne clé oubliée dans authorized_keys suffit à un attaquant quantique pour se connecter à votre machine. Savoir quels serveurs négocient encore un échange de clés classique, et quelles clés traînent encore, commence par un inventaire cryptographique.