SSH post-quantique : mlkem768x25519-sha256 dans OpenSSH

OpenSSH propose dès aujourd'hui un accord de clés post-quantique, sans bibliothèque supplémentaire ni correctif. La méthode hybride mlkem768x25519-sha256 a été ajoutée dans OpenSSH 9.9 (19 septembre 2024) et est devenue l'accord de clés par défaut dans OpenSSH 10.0 (9 avril 2025). Ce guide montre comment lire la méthode réellement négociée par une session, comment privilégier la méthode hybride sur les versions qui la prennent en charge sans l'utiliser par défaut, ce que signifie l'avertissement d'OpenSSH 10.1 concernant un accord de clés non post-quantique, et pourquoi les clés d'hôte SSH restent classiques.

Ce que fait réellement mlkem768x25519-sha256

Le nom décrit la construction : ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, un KEM ou mécanisme d'encapsulation de clés) avec le jeu de paramètres 768, X25519 (Diffie-Hellman sur courbe elliptique Curve25519) et SHA-256 comme fonction de hachage. Le NIST a publié ML-KEM sous la référence FIPS 203 le 13 août 2024 (FIPS 203), et la page de référence ML-KEM présente ses jeux de paramètres et son statut.

La méthode est hybride : la clé de session est dérivée à la fois du secret partagé ML-KEM et du secret partagé X25519. Un client et un serveur qui la négocient restent protégés tant qu'au moins l'un des deux composants résiste. C'est le choix prudent tant que les implémentations post-quantiques sont récentes, et c'est ce vers quoi orientent les recommandations européennes : un accord de clés hybride plutôt qu'un échange purement post-quantique.

L'accord de clés est la première priorité en SSH, pour la même raison qu'en TLS. Un attaquant qui enregistre aujourd'hui une session chiffrée peut la stocker et l'attaquer plus tard. C'est le principe « récolter maintenant, déchiffrer plus tard » (HNDL, harvest now, decrypt later), décrit dans notre article récolter maintenant, déchiffrer plus tard. Si l'échange était purement classique, un ordinateur quantique suffisamment puissant permettrait de déchiffrer rétroactivement le trafic enregistré. L'authentification est différente : un attaquant capable de falsifier une signature d'hôte doit l'utiliser pendant une connexion active, de sorte que la migration des signatures peut intervenir plus tard sans exposer les sessions passées.

Étape 1 : vérifier vos versions et ce que négocient vos sessions

Quelles méthodes le binaire prend-il en charge

ssh -V
ssh -Q kex
ssh -Q kex | grep mlkem

ssh -Q kex liste les méthodes d'échange de clés compilées dans le binaire, indépendamment de la configuration. Si mlkem768x25519-sha256 apparaît, la version la prend en charge. Les deux extrémités doivent la prendre en charge : effectuez donc la même vérification sur le serveur. Un client récent qui dialogue avec un serveur ancien se rabat sur ce que les deux ont en commun.

Quelle méthode cette session a-t-elle utilisée

ssh -v user@server 2>&1 | grep -i 'kex: algorithm'

La sortie détaillée est envoyée sur la sortie d'erreur standard, d'où la redirection. Une session utilisant la méthode hybride affiche une ligne de la forme debug1: kex: algorithm: mlkem768x25519-sha256. C'est la vérification la plus utile, car elle indique ce qui a été négocié et non ce que vous pensez avoir configuré.

Quelle est la configuration effective

ssh -G server | grep -i kexalgorithms
sudo sshd -T | grep -i kexalgorithms

ssh -G affiche la configuration client qui s'appliquerait à cette destination, une fois tous les blocs Host et les inclusions résolus. sshd -T affiche la configuration effective du serveur et nécessite les droits root. Exécutez les deux avant toute modification et conservez la sortie : elle constitue une preuve d'inventaire.

Chronologie des versions

Source : les notes de version d'OpenSSH. Lecture pratique : à partir de la 9.9, la méthode est déjà disponible ; à partir de la 10.0, elle est privilégiée pour vous ; entre la 9.0 et la 9.9, vous disposez toujours d'un accord de clés post-quantique grâce à sntrup761x25519-sha512@openssh.com.

Étape 2 : privilégier mlkem768x25519-sha256 sans casser les pairs plus anciens

La directive est KexAlgorithms, utilisée dans ssh_config côté client et dans sshd_config côté serveur. Elle accepte trois préfixes : ^ place les méthodes indiquées en tête de la liste par défaut intégrée, + les ajoute à la fin et - les retire. Les placer en tête est l'option sûre, car le reste de la liste par défaut demeure disponible en repli.

Côté client, dans ~/.ssh/config ou dans un fichier complémentaire sous /etc/ssh/ssh_config.d/ :

Host *
    KexAlgorithms ^mlkem768x25519-sha256

Côté serveur, dans /etc/ssh/sshd_config ou dans un fichier complémentaire sous /etc/ssh/sshd_config.d/ :

KexAlgorithms ^mlkem768x25519-sha256

Si vous préférez une liste ordonnée explicite, conservez les méthodes classiques en fin de liste afin que les pairs pas encore mis à niveau puissent toujours se connecter :

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

Validez la configuration avant de la recharger, et rechargez le service plutôt que de le redémarrer :

sudo sshd -t
# the service name varies by distribution: ssh on Debian and Ubuntu, sshd on many others
sudo systemctl reload sshd

Un ordre d'opérations qui évite de vous retrouver bloqué : testez d'abord en préproduction, gardez une session privilégiée ouverte pendant le rechargement, puis ouvrez une seconde session et relancez la vérification ssh -v avant de fermer la première. Ne retirez pas les méthodes classiques de la liste d'un serveur tant que tous les clients qui s'y connectent n'ont pas été inventoriés : serveurs de rebond, exécuteurs d'automatisation, agents de sauvegarde, sondes de supervision, équipements réseau et bibliothèques SSH embarquées sont les causes habituelles d'interruption de service dans ce cas.

Étape 3 : interpréter correctement l'avertissement d'OpenSSH 10.1

OpenSSH 10.1 (6 octobre 2025) émet un avertissement lorsqu'une connexion négocie un accord de clés non post-quantique. L'option s'appelle WarnWeakCrypto et elle est activée par défaut. Deux points comptent pour l'exploitation.

Premièrement, il s'agit d'un avertissement, pas d'un blocage : la connexion aboutit quand même. Il vous signale que c'est l'autre extrémité de la connexion qui requiert votre attention. Deuxièmement, sntrup761x25519-sha512@openssh.com est lui-même un hybride post-quantique : une session qui le négocie n'est donc pas le cas visé par cet avertissement. Cette méthode n'est simplement pas fondée sur une norme du NIST, ce qui explique pourquoi ML-KEM est l'orientation retenue pour l'interopérabilité et pour les exigences d'achat.

Traitez chaque avertissement comme une ligne d'inventaire : quel pair, quelle version, quelle équipe en est responsable. Si vous souhaitez plus tard refuser les échanges exclusivement classiques au lieu d'être simplement averti, définissez une liste KexAlgorithms explicite ne contenant que des méthodes post-quantiques, et ne le faites qu'une fois que vos vérifications montrent que tous les pairs les prennent en charge.

Étape 4 : les clés d'hôte restent classiques pour l'instant

En SSH, l'accord de clés et l'authentification sont négociés séparément. Les clés d'hôte et les clés utilisateur relèvent d'algorithmes de signature : ssh-ed25519, rsa-sha2-256, rsa-sha2-512 et les variantes ECDSA. Les versions mentionnées ci-dessus ont modifié l'accord de clés, pas les types de clés d'hôte : la situation réaliste aujourd'hui est donc un échange hybride protégeant une session toujours authentifiée par une clé d'hôte classique. Vous pouvez voir laquelle a été utilisée dans la même sortie détaillée :

ssh -v user@server 2>&1 | grep -i 'host key'

Cette situation intermédiaire est acceptable pour la raison indiquée plus haut : la falsification d'une signature exige une attaque pendant la connexion et n'expose pas les sessions enregistrées par le passé. Le NIST a normalisé ML-DSA sous la référence FIPS 204 le 13 août 2024 (voir la page ML-DSA), et la migration des signatures SSH dépend de travaux complémentaires sur le protocole et les implémentations. D'ici là, consignez cet écart au lieu de le masquer, privilégiez les clés d'hôte ed25519 et, lorsque RSA est utilisé, suivez les recommandations de taille de clé applicables à votre organisation.

Ce qu'il faut consigner pour les audits et les inventaires

SSH est souvent absent des inventaires cryptographiques qui couvrent pourtant correctement TLS. L'exigence 12.3.3 de PCI DSS v4.0.1 impose que les suites de chiffrement et les protocoles utilisés soient documentés et revus au moins tous les 12 mois, et elle est obligatoire depuis le 31 mars 2025 (voir PCI DSS v4.0.1). Au titre de DORA, l'article 6 du règlement délégué (UE) 2024/1774 de la Commission exige une politique de chiffrement et de contrôles cryptographiques comprenant des dispositions relatives à la mise à jour ou au changement de technologie cryptographique en fonction de l'évolution de la cryptanalyse, et l'article 7 exige une gestion des clés couvrant l'ensemble de leur cycle de vie (voir la page consacrée aux RTS DORA). Ce que ces textes exigent littéralement, c'est la politique et l'inventaire. La correspondance ci-dessous est notre interprétation de la manière d'en apporter la preuve pour SSH, et non la citation d'une exigence. Il s'agit d'une information, et non d'un conseil juridique.

Étape suivante : vérifier le reste de votre surface

SSH n'est qu'un protocole parmi d'autres, et la même construction hybride existe en TLS sous le nom X25519MLKEM768. Le moyen le plus rapide de savoir où en sont vos services publics est d'analyser votre domaine avec PQC Status, qui indique les groupes d'échange de clés négociés, les versions de TLS et la chaîne de certificats. Associez ce résultat aux vérifications SSH ci-dessus, une ligne par hôte, et vous disposerez du point de départ d'un véritable inventaire cryptographique plutôt que d'une supposition.