Paramètres post-quantiques par défaut d'OpenSSH et avertissement d'échange de clés non post-quantique

Objectif

État au 25 octobre 2026. Résoudre un avertissement d'échange de clés non post-quantique en vérifiant les extrémités réellement impliquées et leurs paramètres. Vérifier de nouveau les recommandations post-quantiques d'OpenSSH, la documentation du paquet installé et la configuration effective avant de modifier la politique. Les versions repères ci-dessous décrivent les fonctionnalités du projet amont, pas le niveau des derniers correctifs de sécurité.

Les recommandations d'OpenSSH indiquent un mécanisme post-quantique par défaut depuis la version 9.0, utilisant initialement l'hybride sntrup. L'algorithme mlkem768x25519-sha256 est pris en charge depuis la version 9.9 et est devenu le choix par défaut dans la version 10.0. OpenSSH 10.1, publié le 6 octobre 2025, a introduit un avertissement lorsqu'une connexion sélectionne un échange non post-quantique.

Prérequis

Disposer d'un compte de test autorisé, d'un accès à la configuration des deux extrémités et d'une session d'administration existante ou d'une console pour rétablir l'accès en cas de problème. L'avertissement concerne la protection contre un futur déchiffrement du trafic enregistré. Il n'établit pas à lui seul une interception, une compromission ou un échec de vérification de la clé d'hôte.

Étapes

1. Identifier l'implémentation SSH réelle à chaque extrémité, y compris dans les appliances et les services Git intégrés. Exécuter ssh -V sur le client. Un paquet au nom similaire ou la version du client ne permet pas d'établir ce que prend en charge un service distant.

2. Examiner les capacités locales avec ssh -Q kex, puis les paramètres appliqués à la destination réelle :

   ssh -G server.example
   

   Examiner kexalgorithms et les paramètres propres à l'hôte qui s'appliquent. La liste des algorithmes pris en charge n'est pas la liste effective des algorithmes autorisés, et aucune des deux ne constitue le résultat négocié.

3. Sur un serveur OpenSSH, utiliser sshd -T avec des privilèges suffisants pour examiner la configuration effective. Utiliser ses paramètres de connexion -C lorsqu'il faut évaluer les paramètres conditionnels pertinents. Examiner les fichiers inclus et les restrictions gérées centralement avant toute modification.

4. Privilégier les mises à jour prises en charge par le fournisseur et la suppression des restrictions obsolètes qui empêchent l'utilisation des algorithmes hybrides. Les anciennes implémentations peuvent annoncer sntrup761x25519-sha512@openssh.com ; les notes de version 9.9 ajoutent explicitement le nom non qualifié sntrup761x25519-sha512. Cette dénomination est plus précise que la forme abrégée utilisée dans la présentation des mécanismes post-quantiques. Une extrémité utilisant l'ancien hybride n'a pas à être classée comme limitée aux mécanismes classiques simplement parce qu'elle ne dispose pas de ML-KEM. Confirmer les noms exacts acceptés par chaque version de compilation.

5. Valider une configuration serveur modifiée avec sshd -t avant la procédure normale de rechargement de la plateforme. Garder ouverte la session de secours. Établir une connexion distincte sans réutiliser une session multiplexée :

   ssh -vv -S none server.example
   

   Lire l'algorithme d'échange de clés sélectionné dans la sortie de diagnostic et vérifier que l'authentification de l'hôte et l'ouverture de session fonctionnent normalement. Fermer la session de test une fois l'opération terminée. Éviter de publier des journaux de diagnostic sans en masquer les noms d'hôte ou les informations de compte.

6. Si une ancienne extrémité ne peut pas encore être mise à niveau, documenter son responsable, la sensibilité des données et son plan de remplacement. Laisser l'avertissement visible sauf si une exception examinée et de portée restreinte est nécessaire. Désactiver l'avertissement via WarnWeakCrypto modifie le signalement ; cela n'améliore pas la cryptographie.

Résultat attendu

Une nouvelle connexion sélectionne un échange hybride autorisé, ou une exception explicite et consignée subsiste pour une ancienne implémentation. Les clients existants continuent de se connecter comme prévu et la vérification de la clé d'hôte reste obligatoire.

Limites et base de vérification

Cette procédure repose sur la documentation amont, et non sur des tests réalisés sur un parc. L'empaquetage et les politiques appliqués en aval peuvent différer. Ne pas désactiver les vérifications strictes des clés d'hôte, supprimer les contrôles d'authentification ou remplacer les clés des utilisateurs dans le seul but de traiter un avertissement d'échange de clés. Un échange hybride réussi apporte une preuve sur l'établissement de la clé de cette connexion, sans signifier que tous les mécanismes d'authentification sont post-quantiques.