OpenSSH 10.6p2 : contournement du mot de passe sous Alpine

OpenSSH 10.6p2 a été publiée le 5 novembre 2026. Ses notes de version annoncent la correction d'un contournement de l'authentification par mot de passe, exploitable par sshd, sur certains systèmes Linux compilés sans PAM. Le même jour, Alpine Linux a publié un avis qui détaille le mécanisme, les conditions et les paquets corrigés. La faille a été signalée par Özgün Kültekin, de Wakefield.

Deux précisions utiles avant d'agir. D'abord, aucun identifiant CVE n'avait été attribué à la date de l'avis d'Alpine ; certains articles de presse en citent un, nous ne le reprenons pas faute de source primaire. Ensuite, les mainteneurs d'OpenSSH considèrent que la cause racine se trouve hors de sshd et ont contourné le problème dans sshd : le correctif est donc dans le paquet OpenSSH, pas dans la bibliothèque C. Au moment où nous écrivons, aucun rapport public d'exploitation n'est connu de nous, mais le détail technique est public : partez du principe que des scans suivront.

Sans PAM, sshd hache le mot de passe saisi avec crypt() et compare le résultat au champ stocké dans /etc/shadow. Pour les comptes dont le champ est trop court pour contenir un sel, sshd emprunte celui d'un autre compte, afin de ne pas révéler par le temps de réponse qu'un nom d'utilisateur n'a pas de mot de passe.

Sur musl, crypt() renvoie la chaîne * comme valeur d'erreur quand la clé dépasse 256 octets. Or * est aussi, dans /etc/shadow, la valeur d'un compte sans mot de passe. La comparaison réussit : la connexion passe, sans que personne ait deviné quoi que ce soit. L'avis d'Alpine donne la fenêtre exploitable : un mot de passe de 257 à 1024 octets. Ce n'est ni un défaut cryptographique ni une corruption de mémoire, c'est une erreur de logique : une valeur d'erreur prise pour un résultat.

Non, pas pour cette faille : elle exige musl. L'objection mérite pourtant d'être posée, parce que la question utile pour un parc est ailleurs : où trouve-t-on de l'Alpine sans l'avoir choisi ? Une image de conteneur qui embarque un sshd pour le dépannage, une appliance réseau, un routeur sous OpenWrt, une image construite avec Buildroot ou Yocto : tous peuvent reposer sur musl, selon la manière dont ils ont été construits. Sur un VPS à système Debian ou Ubuntu, l'exposition vient d'un conteneur Alpine à sshd que vous y exécutez, pas du système hôte.

Un inventaire tient en deux commandes par machine : ls /lib/ld-musl* indique si le système utilise musl, et ps aux | grep sshd indique si un service SSH tourne. Faites-le aussi dans vos conteneurs, car une image reconstruite l'an dernier peut encore embarquer l'ancien paquet.

Un correctif supprime la faille ; il n'efface pas ce qu'un attaquant a fait avant. L'avis d'Alpine recommande de chercher, dans /var/log/messages, les lignes Accepted password for qui concernent des comptes censés ne pas avoir de mot de passe : alpine, root ou un utilisateur réservé aux connexions par clé. Une telle ligne est un indice fort, puisque ces comptes ne devraient jamais se connecter par mot de passe.

Pour les comptes qui apparaissent, vérifiez ensuite l'usage de doas, les utilisateurs créés récemment, les fichiers modifiés et le contenu de chaque authorized_keys. L'avis ne laisse aucun doute sur la conduite à tenir : si vous ne pouvez pas écarter une connexion, traitez la machine comme compromise, reconstruisez-la et renouvelez les secrets qu'elle contenait. Sur les images cloud officielles, le risque est plus élevé : l'utilisateur alpine y dispose de doas sans mot de passe, ce qui permet de passer root une fois entré.

Les messages ci-dessous sont ceux d'OpenSSH ; ils apparaissent côté client dans le terminal, côté serveur dans le journal du service.

Elle ne vient pas d'une mauvaise pratique spectaculaire : un compte sans mot de passe, un autre avec un mot de passe, une valeur par défaut. Chacun de ces choix est courant, et c'est leur combinaison sur un système peu fréquent qui crée l'exposition. La réponse durable est la même qu'avant la faille : sur tout serveur joignable depuis Internet, authentifiez-vous par clé, désactivez les mots de passe, et sachez quelles images et quels conteneurs embarquent un sshd.

Si vous avez déjà durci vos accès, cette alerte se règle en dix minutes par machine. Sinon, elle est l'occasion de le faire : la procédure complète est décrite dans notre guide de premier accès SSH, et la mise à jour d'OpenSSH 10.6 sans se couper l'accès l'est dans l'article consacré à cette version. Un VPS ServOrbit vous donne un accès root et le choix du système, ce qui vous laisse la maîtrise de ces paramètres.