OpenSSH 10.6p2 corrige un contournement de mot de passe sur Alpine Linux
OpenSSH 10.6p2 et Alpine ont corrigé le 5 novembre une connexion SSH sans mot de passe. Un test de Tech AI Wire sur cinq images Alpine montre qui est exposé.
Par Claire Whitmore
4 min de lecture
Traduit automatiquement de l'original anglais, vérifié et édité par Claire Whitmore. La version anglaise fait foi. Notre méthode

En chiffres
- octets : la longueur de mot de passe qui passe
- 257-1 024
- connexions de test dans l'étude du chercheur ; seul musl sans PAM s'est comporté autrement
- 17 600
- versions d'Alpine avec paquets corrigés, plus edge
- 3.16-3.24
Alpine Linux et le projet OpenSSH ont publié le 5 novembre 2026 des correctifs pour un bug qui permet de se connecter en SSH à certains serveurs Alpine sans aucun mot de passe. Toute personne qui fait tourner le serveur SSH par défaut d'Alpine avec les connexions par mot de passe activées doit le mettre à jour et le redémarrer aujourd'hui.
La faille « demande une seule connexion, marche à chaque fois et ne demande aucune nouvelle tentative », selon l'avis de sécurité d'Alpine. Özgün Kültekin, de Wakefield, l'a signalée. Aucun numéro CVE n'avait été attribué lors de la publication d'Alpine, et aucun des deux projets ne signale d'attaque.
Comment fonctionne le contournement
Le bug se trouve là où OpenSSH rencontre musl, la petite bibliothèque C qu'Alpine utilise à la place de glibc. Il n'apparaît que lorsque sshd, le serveur SSH, tourne sans PAM. PAM est le système de connexion commun utilisé par la plupart des distributions Linux.
Sans PAM, sshd calcule le hachage du mot de passe saisi avec crypt(). Il compare ensuite le résultat à l'entrée du compte dans /etc/shadow. Alpine explique que le crypt() de musl renvoie * comme erreur pour une clé de plus de 256 octets. Un compte sans mot de passe stocke ce même *. Un mot de passe de 257 à 1 024 octets « correspond » donc. Un compte sans sel utilisable emprunte le sel d'un autre compte. Le sel est le texte aléatoire qui rend chaque hachage unique. C'est pourquoi un compte local doit avoir un vrai hachage $5$ ou $6$.
Les notes de version d'OpenSSH 10.6p2 qualifient la mise à jour de « contournement de sécurité critique » et placent la cause « hors de sshd ». Elle suit OpenSSH 10.6, sorti en octobre avec des signatures post-quantiques.
L'analyse de Kültekin nomme le bug « sshhole » et le fait remonter à deux commits de musl d'août 2012. Sur environ 17 600 connexions de test, seul musl sans PAM s'est comporté autrement. L'analyse cite aussi OpenWrt, Buildroot et Yocto. Alpine et OpenSSH ne les mentionnent pas.
Qui est concerné, selon l'avis d'Alpine
Une machine n'est exposée que si les quatre conditions sont réunies :
- sshd vient du paquet
openssh-server, compilé sans PAM, ou d'openssh-server-pamavecUsePAM no. PasswordAuthenticationvautyes, la valeur par défaut.- Un compte a
*comme champ de mot de passe, par exempleroot, un utilisateur à clé seule ou un utilisateur d'annuaire venu de sssd. - Au moins un compte local a un hachage
$5$ou$6$.
Les conteneurs qui ne lancent pas sshd sont sûrs, tout comme les comptes verrouillés marqués !. Le réglage par défaut PermitRootLogin prohibit-password bloque les connexions par mot de passe pour root. Il ne protège pas un compte qui peut devenir root avec doas. Les images tiny-cloud d'Alpine, de 3.18.11 à 3.24.3, livrent justement un utilisateur alpine avec * et doas sans mot de passe.
Test : cinq images Alpine et leurs réglages par défaut
Lors d'un test de Tech AI Wire le 5 novembre, sous macOS 26.6.2 avec Docker 28.4.0, les images officielles alpine ont installé openssh-server depuis les miroirs actuels d'Alpine.
| Branche | Version de l'image (construite le) | Paquet installé | Version corrigée d'Alpine | sshd -V |
|---|---|---|---|---|
| 3.21 | 3.21.9 (21 oct.) | 9.9_p2-r1 | 9.9_p2-r1 | OpenSSH_9.9p2 |
| 3.22 | 3.22.7 (21 oct.) | 10.0_p1-r11 | 10.0_p1-r11 | OpenSSH_10.0p2 |
| 3.23 | 3.23.7 (21 oct.) | 10.2_p1-r1 | 10.2_p1-r1 | OpenSSH_10.2p1 |
| 3.24 | 3.24.3 (21 oct.) | 10.3_p1-r2 | 10.3_p1-r2 | OpenSSH_10.3p1 |
| edge | 3.25.0_alpha20260805 (6 août) | 10.6_p2-r0 | 10.6_p2-r0 | OpenSSH_10.6p2 |
Quatre résultats comptent :
- Une nouvelle installation reçoit le correctif, mais les images sont plus anciennes. Chacune indique une version antérieure aux versions corrigées 3.21.10, 3.22.8, 3.23.8 et 3.24.4. Les branches stables portent le correctif dans d'anciennes versions d'OpenSSH. Vérifiez donc la révision du paquet, pas
sshd -V. - Les réglages par défaut remplissent trois conditions. Les cinq tournent avec
PasswordAuthentication yeset ontroot:*. Sous 3.24, le sshd par défaut a rejetéUsePAM yescomme « Unsupported option ». Le programme séparésshd.pamdu paquetopenssh-server-pamaffichait toujoursusepam nosous 3.21 et 3.24. - Une image neuve ne remplit pas la quatrième. Aucun compte n'a de hachage
$5$ou$6$tant que personne ne définit de mot de passe. Un seul appel àchpasswda écrit un hachage$6$. - Faire marcher un utilisateur à clé seule crée un compte
*. Sous 3.24,adduser -D appusera écrit!, et sshd a refusé sa clé : « User appuser not allowed because account is locked ». La commande BusyBoxpasswd -ua laissé le!en place. Aprèsusermod -p '*', la connexion par clé a fonctionné.
Comment vérifier et corriger un serveur Alpine
Trois commandes montrent où en est un serveur. Sous 3.24, le test a affiché :
$ apk list -I "openssh-server*"
openssh-server-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
openssh-server-common-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
$ sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ awk -F: '$2=="*" {print $1}' /etc/shadow
root
Un paquet plus ancien que la version corrigée du tableau doit être mis à jour. Alpine a aussi corrigé les branches qui ne sont plus prises en charge, de 3.16 à 3.20. Lancez apk upgrade -U -a, puis rc-service sshd restart. « Mettre à jour le paquet ne remplace pas à lui seul le démon en cours d'exécution », prévient l'avis.
Si la mise à jour doit attendre, le contournement d'Alpine est un fichier, /etc/ssh/sshd_config.d/00-no-passwords.conf, qui contient PasswordAuthentication no. Vérifiez d'abord que la connexion par clé marche et gardez la session en cours ouverte. Dans le test, ce fichier a fait passer sshd -T de yes à no sous 3.21 et 3.24. Cherchez ensuite dans /var/log/messages les lignes « Accepted password for » visant un compte sans mot de passe.
Ce que cela change pour les développeurs
Cherchez openssh-server dans les Dockerfiles. Les images qui lancent sshd pour des runners de CI ou du développement à distance sont celles qui comptent. Reconstruisez-les avec docker build --pull --no-cache, pour qu'une couche mise en cache avant le 5 novembre ne ramène pas l'ancien paquet.
Faites de PasswordAuthentication no la règle sur toute machine Alpine qui n'a besoin que de clés. Selon Alpine, mettre à jour ou couper les connexions par mot de passe « ferme la brèche ». Le test montre pourquoi ce réglage compte : la méthode habituelle pour donner une connexion qui marche à un utilisateur à clé seule crée le compte * dont ce bug a besoin.
Surveillez l'arrivée d'un numéro CVE et les annonces d'OpenWrt, Buildroot et Yocto sur leurs versions exposées. L'équipe d'OpenSSH dit aussi qu'elle publiera des versions plus souvent pour l'instant.
Sources
- Security advisory: openssh-server password authentication bypass - Alpine Linux
- OpenSSH 10.6p2 release notes - OpenSSH
- sshhole - sshhole.com
- Critical OpenSSH Flaw Could Let Attackers Bypass Password Authentication on Alpine Linux Servers - Cyber Security News
- Alpine Linux 3.21.10, 3.22.8, 3.23.8 and 3.24.4 Patches Critical SSH Password Bypass - Linux Compatible
Articles liés

GitLab CVE-2026-97229 : Alpine signale une tentative d'exploitation
Alpine Linux indique qu'un attaquant a tenté d'exploiter CVE-2026-97229 sur son serveur GitLab les 20 et 21 octobre. Mettre GitLab à jour n'a pas suffi : le correctif se trouve dans Ruby.

OpenSSH 10.6 ajoute des signatures post-quantiques et accélère ses versions
OpenSSH 10.6, sorti le 6 octobre, ajoute un type de signature post-quantique, désactive la compression LZ77 et promet des correctifs plus rapides face à l'afflux de rapports de bugs produits par l'IA.

Gzip 1.15 corrige une course qui supprimait le mauvais fichier
Gzip 1.15 apporte 119 commits issus de 75 semaines de travail. Il corrige une course pouvant supprimer le mauvais fichier et un dépassement de tampon en .lzh.