Aller au contenu
Dernière minuteOutils dev

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

4 min de lecture

XLinkedIn

Traduit automatiquement de l'original anglais, vérifié et édité par Claire Whitmore. La version anglaise fait foi. Notre méthode

Capture de l'avis de sécurité d'Alpine Linux qui liste qui est touché par le contournement de mot de passe d'openssh-server : le paquet, PasswordAuthentication et les comptes marqués d'une étoile.
Photo: Alpine Linux

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-pam avec UsePAM no.
  • PasswordAuthentication vaut yes, la valeur par défaut.
  • Un compte a * comme champ de mot de passe, par exemple root, 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.

BrancheVersion de l'image (construite le)Paquet installéVersion corrigée d'Alpinesshd -V
3.213.21.9 (21 oct.)9.9_p2-r19.9_p2-r1OpenSSH_9.9p2
3.223.22.7 (21 oct.)10.0_p1-r1110.0_p1-r11OpenSSH_10.0p2
3.233.23.7 (21 oct.)10.2_p1-r110.2_p1-r1OpenSSH_10.2p1
3.243.24.3 (21 oct.)10.3_p1-r210.3_p1-r2OpenSSH_10.3p1
edge3.25.0_alpha20260805 (6 août)10.6_p2-r010.6_p2-r0OpenSSH_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 yes et ont root:*. Sous 3.24, le sshd par défaut a rejeté UsePAM yes comme « Unsupported option ». Le programme séparé sshd.pam du paquet openssh-server-pam affichait toujours usepam no sous 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 à chpasswd a écrit un hachage $6$.
  • Faire marcher un utilisateur à clé seule crée un compte *. Sous 3.24, adduser -D appuser a écrit !, et sshd a refusé sa clé : « User appuser not allowed because account is locked ». La commande BusyBox passwd -u a laissé le ! en place. Après usermod -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

  1. Security advisory: openssh-server password authentication bypass - Alpine Linux
  2. OpenSSH 10.6p2 release notes - OpenSSH
  3. sshhole - sshhole.com
  4. Critical OpenSSH Flaw Could Let Attackers Bypass Password Authentication on Alpine Linux Servers - Cyber Security News
  5. 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