OpenSSH 10.6, sortie le 6 octobre 2026, renforce la sécurité des connexions SSH au prix de quelques changements visibles : la compression devient moins efficace, un algorithme de signature post-quantique entre officiellement dans la boîte à outils, et certains noms d’utilisateur sont désormais refusés en ligne de commande. Pour qui administre des serveurs, cette version mérite une lecture attentive avant la mise à jour.
Les points :
Pourquoi la compression SSH perd-elle de son efficacité ? #
Le changement le plus concret concerne l’option Compression. Selon les notes de version officielles d’OpenSSH 10.6, ssh et sshd désactivent désormais le codage par dictionnaire LZ77, afin de limiter une fuite d’information liée au dictionnaire de compression partagé entre les canaux d’une même session.
Le projet le classe lui-même parmi les changements potentiellement incompatibles : la compression reste disponible, mais elle compresse moins bien. Sur un lien rapide, l’effet sera à peine perceptible. Sur une connexion lente où l’on comptait sur la compression pour des transferts volumineux, il vaut mieux mesurer avant et après.
À lire Python 3.15 est disponible : imports paresseux, UTF-8 par défaut et un JIT plus rapide
Le même chapitre précise que les charges compressées ne peuvent plus dépasser la taille maximale d’un paquet, un garde-fou supplémentaire du côté du protocole.
Que change la signature post-quantique ssh-mldsa44-ed25519 ? #
OpenSSH avait déjà fait de l’échange de clés post-quantique un sujet prioritaire. La version 10.6 franchit une étape côté signatures avec ssh-mldsa44-ed25519, un algorithme hybride qui associe ML-DSA-44 à Ed25519. Le principe de l’hybride : une signature reste solide tant qu’au moins l’un des deux mécanismes résiste.
Point d’attention signalé dans l’annonce : l’algorithme abandonne le suffixe @openssh.com utilisé par l’implémentation expérimentale. Les clés générées avec cette version d’essai doivent être régénérées ou supprimées. Si vous aviez testé ces clés sur un serveur de préproduction, c’est le moment de faire le ménage dans vos fichiers authorized_keys.
WarnWeakCrypto arrive côté serveur
L’option WarnWeakCrypto devient disponible dans sshd_config et elle est activée par défaut. Elle journalise les connexions dont l’échange de clés n’est pas post-quantique. Concrètement, vos logs vont commencer à signaler les clients anciens : une bonne occasion de repérer les scripts, robots de déploiement ou postes qui n’ont pas suivi.
À lire Comprendre le CIM Informatique : Définition, Applications et Perspectives
Quels correctifs de sécurité faut-il retenir ? #
La liste est longue, mais trois points touchent directement l’exploitation quotidienne. D’abord, sftp valide plus strictement les chemins renvoyés par le serveur : lors d’une copie récursive, un serveur malveillant ne peut plus faire écrire des fichiers hors du répertoire cible.
Ensuite, ssh rejette les caractères $ et \ dans les noms d’utilisateur passés en ligne de commande. La directive User des fichiers de configuration n’est pas concernée. Un script qui construit dynamiquement une commande ssh utilisateur@hôte à partir d’une donnée externe gagne ici une protection, mais un compte au nom exotique peut se retrouver bloqué.
Enfin, l’option restrict d’authorized_keys s’applique désormais correctement au tunneling. Pour les clés de service censées ne faire qu’une chose, c’est une correction qui compte.
Les autres changements notables
Côté clés privées au format OpenSSH, le nombre de tours de dérivation par défaut passe de 24 à 32, avec un plafond d’un million de tours imposé à l’écriture comme au chargement. ssh-keygen corrige aussi une gestion de l’heure d’été qui pouvait décaler d’une heure la date d’expiration de certificats. Et l’option -R de scp, qui permet de copier entre deux hôtes distants, est dépréciée pour raisons de sécurité, comme le résume LWN : elle sera ignorée dans une version future.
À lire Comprendre le CPM Informatique : Stratégies et Avantages pour Votre Entreprise
Pourquoi OpenSSH va publier plus souvent ? #
C’est sans doute le passage le plus intéressant de l’annonce. L’équipe explique recevoir de nombreux rapports de sécurité produits avec l’aide d’outils d’IA. Beaucoup n’ont pas d’impact réel dans un modèle de menace réaliste, mais le projet dit les accueillir volontiers, surtout lorsqu’ils sont accompagnés d’un tri humain, de cas de test ou de correctifs.
Surtout, certaines failles trouvées par l’IA ont été redécouvertes indépendamment par d’autres chercheurs. Le projet en tire une conclusion pragmatique : si plusieurs personnes trouvent la même chose, des attaquants peuvent la trouver aussi. D’où le choix de sortir des versions plus fréquemment plutôt que de regrouper les correctifs jusqu’à la prochaine version planifiée.
Comment préparer la mise à jour sur vos serveurs ? #
La plupart des administrateurs recevront OpenSSH 10.6 via les paquets de leur distribution, avec un délai variable selon les politiques de rétroportage. En attendant, quelques vérifications simples évitent les surprises : chercher les clés post-quantiques expérimentales encore déployées, repérer les usages de scp -R dans les scripts, et vérifier qu’aucun compte de service n’utilise un nom contenant $ ou \.
Après la mise à jour, un œil sur les journaux de sshd permettra de voir ce que WarnWeakCrypto remonte. C’est l’inventaire gratuit des clients à moderniser, et un bon point de départ pour une politique d’accès plus stricte.
À lire CDO Informatique : Rôle, Importance et Perspectives d’Avenir
Questions fréquentes #
Faut-il désactiver la compression SSH après OpenSSH 10.6 ?
Non, l’option reste fonctionnelle. Elle est simplement moins efficace, car le codage LZ77 par dictionnaire est désactivé pour des raisons de sécurité.
Mes clés Ed25519 actuelles restent-elles valables ?
Oui. Seules les clés créées avec l’implémentation expérimentale de la signature post-quantique, sous le nom suffixé @openssh.com, doivent être régénérées ou supprimées.
Que signale WarnWeakCrypto dans les logs ?
L’option, activée par défaut côté serveur, journalise les connexions dont l’échange de clés n’est pas post-quantique. Elle ne bloque rien : elle informe.
