Faille OpenSSH : un mot de passe de 300 lettres ouvre-t-il Linux ?

Une faille corrigée le 5 novembre 2026 dans OpenSSH laissait entrer par SSH avec un mot de passe de 257 à 1 024 caractères, sur certains comptes. Elle ne touche que les Linux construits avec la bibliothèque musl et sans PAM, comme Alpine Linux.

Ce qu'il faut retenir

• La faille est réelle : OpenSSH 10.6p2, publié le 5 novembre, la contourne.
• Elle exige une combinaison précise : musl, sshd sans PAM, connexion par mot de passe autorisée, et un compte dont le mot de passe est marqué « * ».
• Les comptes verrouillés (marqués « ! ») ne sont pas touchés, d'après l'avis d'Alpine.
• Le chiffre de « dix ans » repris dans la presse n'apparaît pas dans l'avis d'Alpine, qui ne donne aucune date de début.

Un mot de passe de 300 lettres ouvre-t-il n'importe quel Linux ?

Non. La plupart des serveurs Linux utilisent la bibliothèque glibc et PAM, qui ne sont pas concernés. Il faut réunir quatre conditions :

1. sshd compilé sans PAM (le paquet openssh-server d'Alpine, ou sa version PAM avec UsePAM no) ;
2. PasswordAuthentication yes, réglage par défaut d'OpenSSH ;
3. un compte dont le champ de mot de passe vaut *, comme root dans les images Alpine de base ou un utilisateur qui se connecte seulement par clé ;
4. au moins un autre compte local avec un mot de passe haché en $5$ ou $6$.

Le chercheur Özgün Kültekin, de l'entreprise Wakefield, a signalé le bug. Les notes d'OpenSSH 10.6p2 parlent d'un « contournement d'authentification par mot de passe » qui touche certains Linux sans PAM, et d'une cause située en dehors de sshd, que le logiciel peut contourner.

Pourquoi 257 caractères changent tout

Quand tu tapes un mot de passe, sshd le transforme avec la fonction crypt() et compare le résultat à la valeur stockée pour le compte. Avec musl, si le mot de passe dépasse 256 octets, crypt() ne calcule rien et renvoie « * ». Or « * » est aussi la valeur stockée pour un compte sans mot de passe. Les deux sont identiques, la comparaison réussit et la porte s'ouvre, en une seule tentative.

L'avis d'Alpine ajoute un détail : sshd emprunte le sel d'un autre compte quand le champ stocké est trop court pour en contenir un, d'où la condition numéro 4. La fiche CVE de la faille lui attribue 8,1 sur 10 sur l'échelle de gravité CVSS.

Et les « dix ans » du titre de Numerama ?

Numerama titre sur une faille ouverte « pendant dix ans ». L'avis d'Alpine, lui, dit seulement que toutes les versions testées sont touchées, y compris les anciennes 3.16 à 3.20, et ne précise pas le début de l'exposition. Prendre « dix ans » au pied de la lettre est donc risqué, et Numerama évoque aussi des comptes « verrouillés » alors qu'Alpine range les comptes marqués « ! » parmi les non touchés.

Notre conclusion : la faille est sérieuse pour les serveurs concernés, et l'idée que 300 lettres ouvriraient n'importe quel serveur Linux est fausse. Les conteneurs Alpine qui ne lancent pas sshd ne sont pas concernés non plus.

Que faire si ton serveur tourne sous Alpine ?

Mets à jour le paquet avec apk upgrade -U -a, puis relance sshd avec rc-service sshd restart : la mise à jour seule ne redémarre pas le programme déjà lancé. Si tu ne peux pas mettre à jour tout de suite, mets PasswordAuthentication no dans la configuration et relance sshd, en gardant une session ouverte pour tester ta connexion par clé. Alpine conseille aussi de chercher les lignes « Accepted password for » dans /var/log/messages pour des comptes qui n'ont pas de mot de passe.

C'est la même famille de problème que les frigos de supermarchés piratés début novembre : une porte d'entrée banale, laissée ouverte par défaut. Les versions corrigées d'Alpine vont de 3.21.10 à 3.24.4 selon la branche.