OpenSSH 10.6p2 : une faille permet de se connecter sans mot de passe sur Alpine Linux

Le 5 novembre 2026, l'équipe OpenSSH a publié en urgence OpenSSH 10.6p2. Cette version contourne une faille critique de sshd : sur certains systèmes Linux, un attaquant qui peut joindre le port SSH se connecte sans connaître aucun mot de passe. Il suffit d'une seule connexion, sans essais répétés. La faille touche les systèmes Linux qui utilisent la bibliothèque C musl avec un sshd compilé sans PAM, ce qui est le cas par défaut sur Alpine Linux. Debian, Ubuntu, Rocky Linux, AlmaLinux et toutes les distributions basées sur glibc ne sont pas concernées. Aucun identifiant CVE n'était attribué au moment de la publication. Si vous administrez un serveur VPS Linux, un serveur dédié ou des conteneurs sous Alpine, voici comment savoir si vous êtes exposé et comment corriger.

Sources : notes de version OpenSSH 10.6p2, avis de sécurité Alpine Linux du 5 novembre 2026, message du mainteneur de musl.

Ce que permet la faille

Quand sshd est compilé sans PAM, il vérifie lui-même le mot de passe : il le passe dans la fonction crypt() de la bibliothèque C, qui calcule son empreinte (hash), puis compare le résultat au champ mot de passe stocké dans /etc/shadow. Pour un compte sans mot de passe, ce champ contient simplement une étoile *. C'est normal pour les comptes qui se connectent uniquement par clé SSH, et c'est le cas de root dans l'image de base d'Alpine depuis la version 3.16 environ.

Le problème vient de la façon dont crypt() de musl signale une erreur : quand le mot de passe soumis dépasse 256 octets, elle renvoie la chaîne *. Ce résultat est identique au champ stocké des comptes sans mot de passe. Un attaquant envoie donc un mot de passe très long, entre 257 et 1 024 octets selon l'avis d'Alpine, et sshd croit à une correspondance. Il lui faut seulement :

• le nom d'un compte dont le champ mot de passe vaut * ;
• au moins un autre compte local avec un vrai mot de passe (empreinte $5$ ou $6$), dont sshd réutilise le sel. Un seul utilisateur avec mot de passe suffit à rendre joignables tous les comptes qui n'en ont pas.

OpenSSH estime que la cause se trouve hors de sshd, mais que la faille passe par lui et qu'il peut la bloquer : c'est ce que fait la version 10.6p2. Rich Felker, mainteneur de musl, considère de son côté que ce n'est pas un bug de musl mais une mauvaise utilisation de crypt() par le programme appelant, et indique que ce comportement sera probablement modifié dans la prochaine version de musl.

Qui est concerné

Selon l'avis d'Alpine, vous êtes exposé si toutes ces conditions sont réunies :

• vous utilisez le paquet openssh-server d'Alpine, compilé sans PAM, ou openssh-server-pam avec UsePAM no ;
• PasswordAuthentication vaut yes, ce qui est la valeur par défaut d'OpenSSH si vous ne l'avez pas changée ;
• la machine a un compte dont le champ mot de passe vaut * : root, un utilisateur créé avec adduser sans mot de passe, un compte venu d'un annuaire (LDAP, Active Directory) via musl-nscd, ou l'utilisateur alpine des images cloud officielles ;
• au moins un compte local a une empreinte de mot de passe $5$ ou $6$.

Le compte root reste protégé par le réglage par défaut PermitRootLogin prohibit-password, sauf si vous l'avez passé à yes. Mais cette protection ne suffit pas si un autre compte exposé peut devenir root, par exemple avec doas. C'est le cas des images cloud officielles d'Alpine (de 3.18.11 à 3.24.3) : leur utilisateur alpine n'a pas de mot de passe et peut utiliser doas sans mot de passe. Elles sont sûres au premier démarrage, mais deviennent attaquables dès qu'un mot de passe est défini sur la machine.

Toutes les versions d'Alpine vérifiées par l'équipe sont touchées : de 3.21 à 3.24 et edge, ainsi que les anciennes versions 3.16 à 3.20.

Où trouve-t-on Alpine Linux avec sshd ?

Alpine est très utilisée parce qu'elle est légère : son image de conteneur de base pèse quelques mégaoctets, et une installation serveur occupe peu d'espace disque et consomme très peu de RAM. On la croise surtout dans trois cas :

• Serveurs et machines virtuelles minimalistes : un petit serveur virtuel, une passerelle VPN, un serveur DNS, un relais SMTP ou un serveur FTP installés sous Alpine pour économiser les ressources. Sur une plateforme de virtualisation comme Proxmox ou KVM, chaque machine virtuelle Alpine a son propre sshd et doit être vérifiée séparément.
• Conteneurs : de nombreuses images Docker sont basées sur Alpine (nginx:alpine, postgres:16-alpine, python:alpine…). Elles ne sont concernées que si vous avez ajouté un serveur SSH dans le conteneur, ce qui reste rare mais existe pour certains environnements de développement ou des conteneurs LXC utilisés comme des petits serveurs.
• Images cloud officielles d'Alpine (qcow2, VHD, AMI), décrites plus haut.

Sur un serveur touché, tout ce qu'il héberge est en jeu : serveur web (Apache, Nginx), sites PHP, bases de données MySQL ou PostgreSQL, scripts Python, panel d'administration, fichiers clients. Un attaquant connecté avec un compte qui peut utiliser doas ou sudo obtient les droits root sur toute la machine.

Ne sont pas concernés :

• les distributions basées sur glibc (Debian, Ubuntu, Rocky Linux, AlmaLinux, Fedora…) et les systèmes non Linux ;
• les serveurs qui passent par PAM (openssh-server-pam avec UsePAM yes) ;
• les serveurs où PasswordAuthentication no est déjà réglé, y compris les images cloud configurées par cloud-init, qui l'écrit par défaut ;
• les conteneurs Docker qui ne font pas tourner sshd, même basés sur Alpine ;
• les comptes verrouillés, dont le champ vaut ! et non * ;
• Dropbear et les autres serveurs SSH qui ne sont pas OpenSSH, selon le mainteneur de musl.

Vérifier votre serveur en une minute

Connectez-vous en SSH et commencez par la distribution. Si la commande n'affiche pas Alpine (ou une autre distribution basée sur musl), vous n'êtes pas concerné :

cat /etc/os-release | grep -E '^(ID|VERSION_ID)='

Sur Alpine, regardez la configuration réellement appliquée par sshd :

sshd -T | grep -iE '^(usepam|passwordauthentication|permitrootlogin)'

Si vous lisez passwordauthentication yes et usepam no (ou aucune ligne usepam), listez ensuite les comptes sans mot de passe et ceux qui en ont un :

awk -F: '$2 == "*" {print "sans mot de passe : " $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "avec mot de passe : " $1}' /etc/shadow

Si les deux listes contiennent chacune au moins un compte, votre serveur est exposé tant qu'il n'est pas mis à jour.

Corriger : mettre à jour et redémarrer sshd

Alpine a publié des paquets corrigés pour toutes ses branches, jusqu'à 3.16, y compris celles qui ne reçoivent plus de mises à jour habituelles :

Les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 d'Alpine contiennent déjà le paquet corrigé. Mettez à jour, puis redémarrez sshd : la mise à jour du paquet ne remplace pas le démon déjà lancé, qui reste vulnérable tant qu'il tourne.

apk upgrade -U -a
rc-service sshd restart
apk info -v openssh-server

Sur les autres systèmes musl qui compilent OpenSSH eux-mêmes, passez à OpenSSH 10.6p2 ou appliquez le correctif de votre distribution.

Si vous ne pouvez pas mettre à jour tout de suite

Désactivez la connexion par mot de passe : un seul de ces deux gestes (mise à jour ou désactivation) suffit à fermer la faille. Avant de commencer, vérifiez que votre connexion par clé SSH fonctionne et gardez votre session ouverte jusqu'à avoir testé une nouvelle connexion, sinon vous risquez de perdre l'accès. Notre guide configurer une clé SSH sans perdre l'accès détaille la méthode.

Ajoutez la ligne suivante dans /etc/ssh/sshd_config, en remplaçant toute ligne PasswordAuthentication yes existante, y compris dans les blocs Match. Depuis Alpine 3.19, vous pouvez aussi la placer dans un fichier du dossier /etc/ssh/sshd_config.d/ :

PasswordAuthentication no

Vérifiez la configuration, redémarrez le démon et contrôlez le résultat, qui doit afficher passwordauthentication no :

sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

C'est de toute façon le réglage que nous recommandons sur tout serveur exposé sur Internet, quelle que soit sa distribution : voir notre guide sécuriser SSH sur un VPS Linux. Damien Miller, développeur d'OpenSSH, a conseillé sur Mastodon de désactiver la connexion par mot de passe « immédiatement » sur les systèmes touchés, ou de couper SSH en attendant la mise à jour (propos relayés par heise).

Réduire l'exposition du port SSH avec le pare-feu

La faille ne peut être exploitée que par quelqu'un qui joint votre port SSH. Limiter ce port à quelques adresses IP de confiance réduit donc fortement le risque, pour cette faille comme pour les suivantes. Sur Alpine, le pare-feu se configure par exemple avec iptables ou nftables. Avec nftables, la règle suivante n'accepte les connexions SSH que depuis l'adresse IP de votre bureau (remplacez 203.0.113.10 par la vôtre) :

nft add rule inet filter input tcp dport 22 ip saddr != 203.0.113.10 drop

Testez-la depuis une deuxième session avant de fermer la première, et vérifiez que la table inet filter existe sur votre serveur. Si votre adresse IP change souvent, passez plutôt par un VPN (WireGuard, Tailscale) et n'ouvrez SSH que sur l'interface du VPN. Le firewall ne remplace pas la mise à jour : il réduit seulement le nombre de personnes qui peuvent tenter l'attaque.

Savoir si votre serveur a été visé

Cherchez dans /var/log/messages les lignes Accepted password for qui concernent un compte sans mot de passe (root, alpine ou tout utilisateur qui se connecte normalement par clé) :

grep 'sshd.*Accepted password for' /var/log/messages

Une telle ligne est anormale : ces comptes ne peuvent pas se connecter légitimement par mot de passe. Vérifiez aussi l'usage de doas, les utilisateurs créés récemment, les fichiers modifiés et les clés ajoutées dans les fichiers authorized_keys. L'avis d'Alpine est clair : si vous ne pouvez pas exclure une connexion frauduleuse, considérez la machine comme compromise. Réinstallez-la, restaurez les données à partir d'un backup antérieur à la date de la faille, puis changez tous les secrets qui se trouvaient sur le serveur : mots de passe des bases de données, clés API, clés SSH, accès au nom de domaine et au compte de votre hébergeur. D'où l'intérêt de sauvegardes régulières, stockées hors du serveur. Notre guide analyser les connexions SSH dans les logs aide à faire ce tri.

Des correctifs OpenSSH plus fréquents

Dans ses notes de version, l'équipe OpenSSH explique recevoir beaucoup de signalements de failles trouvées par des modèles d'IA ou avec leur aide. Elle a observé plusieurs cas où une faille trouvée avec un outil d'IA a ensuite été redécouverte de façon indépendante par un autre chercheur. Elle en conclut que des attaquants qui ne signalent pas les failles peuvent probablement les trouver aussi. L'équipe publiera donc, pour l'instant, des versions plus fréquentes pour livrer les correctifs plus vite, au lieu de les regrouper dans la version suivante. Pour un administrateur, la conséquence est simple : appliquez les mises à jour de sécurité d'OpenSSH dès leur sortie, comme celles du noyau (voir notre actualité sur la faille TCP CVE-2026-98432).

Sur un hébergement mutualisé ou en infogérance, c'est l'hébergeur qui administre le serveur SSH et applique ces correctifs. Sur un VPS Linux KVM avec accès root, ces mises à jour sont sous votre contrôle : vous choisissez votre distribution, votre configuration SSH et le moment du redémarrage. Pour limiter l'exposition au quotidien, combinez connexion par clé, Fail2ban et limitation des tentatives de connexion.