Imaginez un videur de boîte de nuit qui compare le nom sur votre carte à sa liste. Si sur votre carte d’identité est, le nom est tellement long que le système s’embrouille et écrit « erreur », le videur pourrait vous laisser entrer. C’est, en gros, ce qui se passe avec la faille OpenSSH sur Alpine Linux publiée le 5 novembre 2026. Si vous hébergez un serveur, un NAS, un routeur ou une image cloud sous Alpine, voici comment savoir en dix minutes si vous êtes concerné, et comment colmater la brèche.
🟥 EN BREF : sur Alpine Linux, une faille permet, dans certaines conditions, de se connecter en SSH sans connaître le bon mot de passe. Les correctifs existent pour toutes les versions d’Alpine, de la 3.16 à « edge ». Mettre à jour le paquet ne suffit pas : il faut aussi redémarrer le service SSH.
Ce qui s’est passé, en deux minutes
Le 5 novembre 2026, le projet Alpine Linux a publié un avis de sécurité intitulé « openssh-server password authentication bypass ». Un attaquant qui peut joindre le port SSH peut, dans les conditions décrites plus bas, ouvrir une session sans mot de passe valide. Le chercheur à l’origine du signalement est Özgün Kültekin, de la société Wakefield. Le correctif a été réalisé avec l’équipe d’OpenSSH (Damien Miller et Darren Tucker) et publié dans OpenSSH 10.6p2. Le même jour, le journal LWN relayait l’alerte, et Damien Miller invitait les exploitants de systèmes touchés à agir immédiatement : désactiver l’authentification par mot de passe, ou couper SSH.
Le site dédié à la faille, sshhole.com, la présente comme un bug ancien, dont les origines techniques remontent à 2016 environ.
🟦 DÉFINITIONS POUR DÉBUTANTS
- SSH (Secure Shell) : le protocole qui permet de se connecter à distance, de façon chiffrée, à un serveur. OpenSSH en est l’implémentation la plus répandue, et sshd est le programme (le « démon ») qui écoute les connexions sur le serveur.
- Alpine Linux : une distribution Linux très légère, omniprésente dans les conteneurs Docker, les routeurs, certains NAS et les images cloud.
- musl : une bibliothèque de base du système (la « libc ») utilisée par Alpine. Debian, Ubuntu et Fedora utilisent une autre bibliothèque, glibc. C’est cette différence qui compte ici.
Pourquoi ça marche : l’histoire du videur
Voici le mécanisme, sans le moindre outil d’attaque.
- Sur Linux, les mots de passe ne sont pas stockés en clair. Le fichier /etc/shadow contient une empreinte (un « hash ») de chaque mot de passe. Pour vérifier une connexion, sshd transforme le mot de passe saisi avec une fonction nommée crypt(), puis compare le résultat à l’empreinte stockée.
- Pour un compte sans mot de passe (par exemple un utilisateur qui se connecte uniquement avec une clé SSH), le champ contient simplement le caractère *.
- Quand crypt() rencontre un problème, la version de musl renvoie… * comme code d’erreur. Elle le fait notamment quand le mot de passe fourni dépasse 256 octets.
- Résultat : pour un compte dont le champ est *, le « résultat » (l’erreur *) est identique à la valeur stockée (*). La comparaison réussit, et la porte s’ouvre.
D’après l’avis d’Alpine, il faut en plus qu’un autre compte local possède une vraie empreinte de type $5$ ou $6$ (SHA-256 ou SHA-512), parce que sshd emprunte alors le « sel » de ce compte lors du calcul.
L’analogie a ses limites : le videur ne se trompe pas par hasard, il suffit d’un mot de passe dont la taille déclenche l’erreur. Ce n’est pas un piratage de chiffrement, c’est un oubli de gestion d’erreur qui a duré des années.
Êtes-vous concerné ? La checklist en 5 conditions
Selon l’avis officiel, la faille est exploitable uniquement si les cinq conditions sont réunies :
| # | Condition | Où vérifier |
| 1 | Le serveur SSH est openssh-server sans PAM, ou openssh-server-pam avec UsePAM no | Paquets installés, configuration |
| 2 | PasswordAuthentication vaut yes (valeur par défaut d’OpenSSH) | Configuration de sshd |
| 3 | Au moins un compte a * comme champ mot de passe | /etc/shadow |
| 4 | Au moins un compte local a une empreinte $5$ ou $6$ | /etc/shadow |
| 5 | L’attaquant envoie un mot de passe de 257 à 1 024 octets | Côté attaquant |
Quels comptes ont * ? D’après l’avis : le compte root dans les images de base depuis Alpine 3.16 environ (mais il n’est atteignable que si PermitRootLogin yes est activé), les utilisateurs « clé uniquement », les utilisateurs venant d’annuaires (nslcd, winbind, sssd) et l’utilisateur alpine des images tiny-cloud.
🟦 Qui n’est pas concerné ? D’après l’avis Alpine et LWN : les systèmes glibc (Debian, Ubuntu, Fedora), les connexions qui passent par PAM (UsePAM yes), les comptes verrouillés avec !, les serveurs avec PasswordAuthentication no. sshhole.com ajoute Dropbear et OpenBSD.
Le cas des conteneurs Docker
Un conteneur Alpine ne fait tourner aucun serveur SSH par défaut : il n’est donc pas exposé à cette faille. Le risque concerne les conteneurs où quelqu’un a installé et lancé sshd. Le site sshhole.com affirme que des images publiques pourraient être exploitables dans leur configuration documentée ; LWN, de son côté, ne parle pas des conteneurs. Si vous avez construit une image avec openssh-server, vérifiez-la.
Le cas des images cloud officielles
D’après l’avis, les images officielles d’Alpine (qcow2, VHD, AMI) des versions 3.18.11 à 3.24.3 contiennent un utilisateur alpine avec un champ * et un doas (l’équivalent d’sudo) sans mot de passe. Elles sont sûres au premier démarrage, mais deviennent exploitables dès qu’un hash $6$ existe sur la machine, par exemple après la création d’un utilisateur avec mot de passe. Les images construites à partir de 3.21.10, 3.22.8, 3.23.8 et 3.24.4 sont corrigées.
Étape 1 : vérifier votre machine (lecture seule)
Connectez-vous en administrateur sur le serveur Alpine, puis lancez ces commandes. Elles ne modifient rien.
cat /etc/alpine-release # votre version d'Alpine
apk info -v | grep openssh # version du paquet OpenSSH installé
sshd -T | grep -i passwordauthentication
awk -F: '$2=="*"{print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/{n++} END{print n+0}' /etc/shadow
pidof sshdCe que vous cherchez :
- Version du paquet : comparez avec le tableau des versions corrigées plus bas. Si elle est inférieure, vous n’êtes pas à jour.
- passwordauthentication yes : l’authentification par mot de passe est active.
- La première commande awk affiche les comptes dont le champ mot de passe est *. S’il n’y en a aucun, la condition 3 n’est pas remplie.
- La seconde awk compte les comptes ayant une empreinte $5$ ou $6$. Un résultat supérieur à zéro remplit la condition 4.
- Un ancien daemon encore actif : pour un processus sshd (pidof sshd donne ses numéros), testez readlink /proc/NUMÉRO/exe. Si la réponse contient « deleted », c’est l’ancienne version qui tourne encore, même si le paquet est à jour.
Ces commandes de contrôle sont reprises de l’avis officiel pour sshd -T et du script de contrôle publié par un auteur tiers (DEV Community) pour le reste. Adaptez-les à votre cas. Selon la compilation, sshd -T peut aussi ne pas afficher usepam.
🟨 ASTUCE : si vous avez une flotte de machines, notez dans un tableur la version d’Alpine, la version d’openssh, l’état de PasswordAuthentication et la présence de comptes *. En dix minutes, vous saurez où agir en premier.
Étape 2 : corriger, la bonne méthode
Solution recommandée : mettre à jour ET redémarrer
apk upgrade -U -a
rc-service sshd restartapk upgrade -U -a met à jour l’index puis tous les paquets. rc-service sshd restart relance le service.
🟥 ATTENTION : le redémarrage est indispensable. Le paquet mis à jour ne remplace pas le programme déjà en cours d’exécution. Sans redémarrage, votre machine reste vulnérable. Gardez une session ouverte pendant l’opération, au cas où.
| Branche Alpine | Version fixe de openssh |
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
La branche 3.21 a atteint la fin de son support le 1er novembre 2026, mais Alpine a quand même publié des paquets corrigés pour toutes les branches jusqu’à la 3.16. Les versions antérieures à la 3.16 n’ont pas de correctif : pour elles, il faut appliquer la contre-mesure ci-dessous (et planifier une migration).
Solution de secours : désactiver les mots de passe SSH
Si vous ne pouvez pas mettre à jour tout de suite, voici la contre-mesure de l’avis Alpine. Avant de commencer, vérifiez que votre connexion par clé fonctionne, sinon vous risquez de vous enfermer dehors :
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthenticationExplications : la première commande crée un dossier de configuration, la deuxième y dépose un fichier qui interdit les mots de passe, la troisième teste la configuration (sshd -t) avant de relancer le service, la dernière doit afficher passwordauthentication no.
🟥 ATTENTION : ce dossier sshd_config.d n’est lu par défaut que depuis Alpine 3.19. Sur une version antérieure, modifiez directement /etc/ssh/sshd_config (l’avis officiel fournit une commande sed qui crée une copie de sauvegarde .bak).
Étape 3 : chercher des traces d’intrusion
Mettre à jour ne suffit pas si quelqu’un est déjà entré. L’avis d’Alpine recommande de vérifier :
- les journaux dans /var/log/messages : cherchez des lignes Accepted password for concernant des comptes qui n’ont pas de mot de passe (alpine, root, un utilisateur « clé uniquement »). Un tel accès n’a aucune raison légitime d’exister ;
- l’utilisation de doas, la création de nouveaux utilisateurs, les fichiers récents et les authorized_keys (les clés SSH autorisées) ;
- en cas de doute : considérez la machine comme compromise, comme le recommande l’avis, et réinstallez-la si vous ne pouvez pas exclure une intrusion.
Autre point rassurant : la source citée par Security Boulevard indique n’avoir relevé aucune exploitation dans la nature à la date du 5 novembre ; l’exploitation y est décrite en laboratoire. À prendre avec prudence, la situation peut évoluer.
Les bons réflexes pour la suite
- Désactivez les mots de passe SSH partout et utilisez uniquement des clés. C’est la meilleure défense, et elle protège aussi contre les attaques par force brute.
- N’exposez pas SSH sur Internet si ce n’est pas nécessaire : passez par un VPN, ou limitez par adresse IP avec un pare-feu.
- Abonnez-vous aux avis de sécurité de votre distribution : Alpine publie les siens sur son site officiel.
- Redémarrez les services après chaque mise à jour de sécurité. C’est la leçon la plus facile à oublier de cette affaire.
Ce que nous ne savons pas encore
- Le numéro CVE. L’avis d’Alpine indique qu’aucun CVE n’avait été attribué au moment de sa rédaction, et LWN comme sshhole.com n’en donnent pas.
- La date exacte du signalement. Seule la publication du 5 novembre est datée.
- L’étendue réelle sur les routeurs ou systèmes embarqués utilisant musl (OpenWrt, Buildroot, Yocto sont cités par sshhole.com). Chaque fabricant devra publier ses propres correctifs.
Cette faille est un cas d’école. Ce n’est pas un algorithme cassé : c’est un code d’erreur qui, par malchance, ressemble à une valeur légitime, et qui a dormi des années. Le message pour les auto-hébergeurs est simple : les mots de passe SSH sont une dette de sécurité. Les clés SSH, elles, n’auraient pas été concernées. Si vous ne deviez retenir qu’une chose : désactivez les mots de passe, mettez à jour, redémarrez.
FAQ
Ma machine est sous Debian ou Ubuntu : suis-je concerné ? Non, d’après l’avis Alpine, LWN et sshhole.com : ces systèmes utilisent la bibliothèque glibc, pas musl.
Mes conteneurs Docker Alpine sont-ils vulnérables ? Seulement s’ils font tourner un serveur SSH (openssh-server installé et démarré). Un conteneur sans sshd n’est pas exposé par cette faille.
J’ai fait apk upgrade, c’est suffisant ? Non. Il faut redémarrer sshd (rc-service sshd restart), sinon l’ancien programme continue de tourner.
Mon serveur n’accepte que les clés SSH. Dois-je m’inquiéter ? Si PasswordAuthentication no est bien actif, vous n’êtes pas exposé, selon l’avis. Vérifiez-le avec sshd -T.
Y a-t-il un numéro CVE ? L’avis officiel d’Alpine n’en cite pas. Un site tiers évoque CVE-2026-123158.
Le root est-il en danger ? Sur Alpine, le champ de root est * dans les images de base depuis la 3.16, mais il n’est atteignable que si PermitRootLogin yes est activé. Le paramètre par défaut d’OpenSSH, prohibit-password, bloque la connexion par mot de passe.
