OpenSSH 10.6 coupe la compression LZ77 et bloque les métacaractères des noms d’utilisateur pour combler deux failles

6 octobre 2026. OpenSSH 10.6 est publié, et les mainteneurs l’assument d’entrée : cette version casse volontairement deux comportements qui fonctionnaient. D’un côté, la compression SSH perd son codeur LZ77 et devient moins efficace ; de l’autre, les noms d’utilisateur contenant $ ou \ sont rejetés sur la ligne de commande. Pourquoi c’est important : ces deux ruptures referment une fuite de texte clair et une injection de shell, deux classes de faille que la recherche sur SSH, dopée par l’IA, a fait remonter en quelques semaines.

La compression SSH laissait fuiter du texte clair

Le premier changement vise la compression. SSH peut transporter plusieurs flux sur une même connexion chiffrée — un shell interactif, un transfert de port, un proxy SOCKS. Quand la compression est activée, tous ces canaux partagent le même état de compression. Or la compression est désactivée par défaut dans OpenSSH : l’attaque ne marche donc que sur les configurations qui l’ont explicitement activée.

C’est précisément ce partage qui est en cause. Les chercheurs Fabian Bäumer et Marcus Brinkmann, de la Ruhr University Bochum, l’ont démontré dans leur article « Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels ». Un attaquant capable d’injecter du texte choisi dans un canal, puis d’observer le trafic chiffré qui en ressort, peut s’appuyer sur la compression pour récupérer les secrets qui circulent dans un autre canal de la même session.

La fuite vient de la mémoire du LZ77. Au lieu de ré-encoder une séquence d’octets déjà vue, l’algorithme pointe vers l’occurrence précédente. Comme OpenSSH partageait cet historique entre les canaux, une donnée contrôlée par l’attaquant pouvait modifier la façon dont un secret, ailleurs dans la session, était compressé. Quand une supposition correspondait à une partie du secret, le trafic devenait légèrement plus court — un bit d’information de plus pour l’attaquant.

Le correctif choisi est radical : supprimer entièrement le dictionnaire partagé. Le format Deflate utilise le LZ77 pour repérer les répétitions, puis le codage de Huffman pour représenter les valeurs fréquentes en moins de bits. OpenSSH 10.6 désactive la partie LZ77 dans ssh comme dans sshd, tout en conservant Huffman. La compression fonctionne donc encore, mais moins bien, et OpenSSH recommande désormais de déplacer la compression au niveau applicatif, où elle sera à la fois plus performante et insensible à cette attaque.

La plupart des sessions interactives ne verront pas la différence. En revanche, les tâches automatisées qui poussent de gros volumes compressibles sur des liaisons contraintes — sauvegardes, synchronisations de bases — devront revoir leur réglage après la mise à jour.

Concrètement, la bascule applicative se fait souvent sans douleur : rsync dispose de son propre -z, tar se combine avec gzip ou zstd avant l’envoi, et les outils de sauvegarde comme Borg ou Restic compressent et chiffrent déjà avant d’ouvrir la session SSH. Ceux qui compressaient au niveau du tunnel pour économiser la bande passante y gagneront au change : la compression applicative connaît la structure des données, donc elle compresse mieux, et elle est insensible à la fuite puisque le secret n’est jamais mélangé à du contenu influençable dans un même dictionnaire.

Une attaque cousine de CRIME et de BREACH

Cette fuite n’est pas un cas isolé : elle appartient à la famille des attaques par oracle de compression, documentées de longue date sur TLS. CRIME, dévoilé en 2012, et BREACH, en 2013, exploitaient le même principe — une compression partagée entre des données contrôlées par l’attaquant et des secrets — pour récupérer des cookies de session et des jetons d’authentification. Ce qui change ici, c’est le vecteur : SSH, un protocole longtemps jugé à l’abri parce que sa compression est rarement activée.

Le rapprochement vaut une règle de sécurité générale : toute compression partagée entre du contenu influençable et un secret est suspecte, quel que soit le protocole. C’est la raison pour laquelle les navigateurs ont désactivé la compression sur les flux TLS qui transportent des secrets, et pourquoi la recommandation d’OpenSSH — compresser au niveau applicatif, là où la donnée est déjà protégée par ailleurs — rejoint la leçon de l’histoire.

Les métacaractères dans les noms d’utilisateur

Le second changement cible les commandes construites depuis des entrées externes. Un outil interne, un job CI ou un agent peut exécuter quelque chose comme ssh "$INPUT_USER@host". Ce nom d’utilisateur finit ensuite potentiellement dans ProxyCommand, Match exec ou une autre directive transmise au shell, où des caractères comme $ et \ deviennent soudain de la syntaxe de shell au lieu d’une simple partie du nom.

Ce n’est pas la première fois que le projet resserre ce chemin. La version 10.3 avait déjà corrigé un bug voisin : les noms d’utilisateur en ligne de commande étaient vérifiés trop tard, après avoir pu être expansés via ssh_config. Avec la 10.6, les caractères $ et \ sont désormais refusés dans les noms passés en ligne de commande. La restriction ne s’applique toutefois pas au nom défini par la directive User dans un fichier de configuration SSH : les comptes légitimes qui contiennent ces caractères continuent de fonctionner ainsi, mais les scripts et les outils d’agents qui les transmettent directement devront changer.

Les autres ruptures : post-quantique et scp -R

Deux changements supplémentaires peuvent casser des automatisations. L’algorithme de signature hybride post-quantique ssh-mldsa44-ed25519 perd son suffixe expérimental @openssh.com : les clés créées avec l’ancienne implémentation doivent être régénérées ou supprimées. La version amorce aussi la fin de scp -R pour les copies de distant à distant — la commande fonctionne encore en 10.6, mais émet un avertissement et finira par être ignorée.

Ce rythme n’est pas anodin. OpenSSH constate une hausse de la recherche en sécurité menée avec des modèles d’IA, et ces modèles s’améliorent dans la découverte de failles exploitables. Le projet prévient que les adversaires qui ne signalent pas ce qu’ils trouvent « seront probablement capables de découvrir ces bugs eux aussi » et prévoit, pour l’instant, de publier des correctifs plus souvent plutôt que d’attendre son calendrier habituel.

Ce qu’il faut vérifier avant la mise à jour

Trois contrôles suffisent pour un parc classique. Premièrement, détectez qui active la compression : ssh -G <hôte> | grep -i compression renvoie la valeur effective par hôte, et la directive Compression yes dans /etc/ssh/ssh_config ou ~/.ssh/config est le réglage à chercher. Deuxièmement, auditez les scripts qui construisent user@host : tout nom d’utilisateur issu d’une variable, d’un webhook ou d’une entrée utilisateur est un candidat à l’injection, même s’il ne contient pas encore $ ou \. Troisièmement, listez vos clés post-quantiques : ssh-keygen -l -f <clé> affiche l’algorithme, et toute clé ssh-mldsa44-ed25519 créée avant la 10.6 est à régénérer.

Ces contrôles sont rapides et non destructifs, et ils transforment une mise à jour potentiellement cassante en une opération vérifiable. Pour un environnement qui ne compresse pas et n’utilise pas de métacaractères dans ses identifiants, la mise à jour est transparente.

Verdict

Si vous activez la compression SSH sur des transferts volumineux et compressibles, déplacez-la au niveau applicatif avant ou juste après la mise à jour : c’est à la fois la recommandation d’OpenSSH et la protection contre la fuite de texte clair. Si votre automatisation construit des noms d’utilisateur à partir de variables ou d’entrées externes, auditez-les maintenant pour repérer les $ et \ : la 10.6 les rejettera, et laisser un script casser en production est le scénario à éviter. Si vous utilisez des clés ssh-mldsa44-ed25519, régénérez-les immédiatement. Pour tout le reste — sessions interactives, configurations par défaut — la mise à jour est transparente : la compression étant désactivée par défaut, l’essentiel du parc n’est pas exposé à la fuite.

Références

• The New Stack — OpenSSH 10.6 deliberately breaks two features in the name of security (7 octobre 2026)
• LWN — OpenSSH 10.6 released (6 octobre 2026)
• OpenSSH — Release notes
• Bäumer & Brinkmann, Ruhr University Bochum — Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels