Contexte de la version
OpenSSH 10.6 a été publié le 6 octobre 2026, suivant la version 10.5. Le projet indique un rythme de diffusion accéléré, motivé par un afflux de rapports de vulnérabilités provenant d’outils d’intelligence artificielle. Cette stratégie vise à livrer rapidement les correctifs plutôt que d’attendre le prochain cycle de version.
Modifications de sécurité majeures
Le correctif sftp(1) renforce la validation des chemins renvoyés par le serveur afin d’empêcher les copies récursives d’écrire hors du répertoire cible, une faille signalée par Junghoon Cho. Le module sshd(8) ne conserve plus les informations d’identification GSSAPI lorsqu’une authentification échoue, limitant ainsi la persistance de crédentiels sensibles, grâce au rapport de Moritz Theile. De plus, sshd réinitialise l’état GSSAPI avant chaque tentative, évitant toute confusion entre sessions successives.
Une vulnérabilité de type side‑channel a été décrite dans le pré‑print arXiv 2609.07709 (2026) : l’utilisation du dictionnaire LZ77 partagé entre canaux permet à un attaquant de récupérer du texte en clair via une attaque par texte choisi. En réponse, OpenSSH 10.6 désactive le codeur LZ77 dans les options Compression, réduisant l’efficacité de la compression mais éliminant le vecteur d’attaque. Les développeurs recommandent d’appliquer la compression au niveau de l’application plutôt qu’au protocole SSH.
Le client ssh(1) refuse désormais les noms d’utilisateur contenant les caractères « $ » et « \ » lorsqu’ils sont fournis en ligne de commande, afin d’éviter des injections potentielles dans des contextes de shell (ProxyCommand, Match exec). Cette restriction ne s’applique pas aux noms définis dans les fichiers de configuration, comme indiqué par SecBuddyF de KeenLab Tencent.
Le générateur de clés ssh-keygen(1) corrige la prise en compte de l’heure d’été, qui pouvait entraîner des écarts de ±1 heure (ou ±2 heures dans le fuseau Antarctica/Troll), évitant ainsi la création de certificats avec des dates d’expiration erronées.
Dépréciations et impacts de compatibilité
Le drapeau -R de scp(1), utilisé pour les copies « remote‑to‑remote », est désormais marqué comme obsolète. Il continue de fonctionner mais génère un avertissement, et sera ignoré dans une version future. Ce drapeau nécessite des identifiants sur l’hôte distant et repose sur un quoting de shell fragile, ce qui crée des risques de sécurité lorsqu’il y a divergence entre les règles de quoting du client et du serveur.
Sur les plateformes qui ne supportent pas le passage de descripteurs de fichiers et qui exigent les privilèges root pour l’allocation de PTY (ex. : SCO OpenServer 5, QNX 6), sshd(8) désactive les options GatewayPorts et StreamLocalForwarding. Cette décision élimine une surface d’attaque mais rend impossible le tunneling sur ces systèmes anciens, à moins que la communauté ne propose des alternatives sans élévation de privilèges.
Gestion des rapports de bugs assistés par IA
Le communiqué souligne que de nombreux rapports de sécurité proviennent d’outils d’IA, mais que la plupart sont jugés non exploitables dans un modèle de menace réaliste. Néanmoins, plusieurs de ces rapports ont été confirmés indépendamment par d’autres chercheurs, ce qui justifie le passage à des versions plus fréquentes. Le processus de triage combine l’analyse humaine, des cas de test et, lorsque possible, des correctifs proposés par les contributeurs.
