OpenSSH 10.6p2 : la faille qui permet d'entrer en SSH avec un mot de passe très long sur Alpine Linux

Publié le 6 novembre 2026 · L'équipe mitza.es

SSH est la « clé maîtresse » avec laquelle on administre la plupart des serveurs Linux : il sert à se connecter à une machine à distance et à y exécuter des commandes. Si quelqu'un parvient à contourner son mot de passe, le serveur est entre ses mains. Le 5 novembre 2026, le projet OpenSSH a publié la version 10.6p2 et Alpine Linux a diffusé le même jour un avis de sécurité sur une faille de ce type. Nous la résumons à la date du 6 novembre 2026, en nous en tenant à ce que les deux projets ont publié.

Ce que disent OpenSSH et Alpine

Les notes de version d'OpenSSH 10.6p2 parlent de corriger un contournement de l'authentification par mot de passe exploitable via sshd qui « touche certains systèmes Linux lorsqu'ils sont compilés et exécutés avec la prise en charge de PAM désactivée ». Le projet lui-même considère que la cause racine se situe en dehors de sshd, et décrit le correctif comme une mesure de sécurité critique pour les systèmes Linux avec la bibliothèque musl et PAM désactivé.

L'avis d'Alpine, de la même date, précise le mécanisme : la fonction crypt() de musl renvoie le texte * comme indicateur d'erreur lorsque la clé dépasse 256 octets. Un attaquant qui envoie un mot de passe très long (de 257 à 1 024 octets) peut finir par s'authentifier sans connaître le mot de passe, à condition que deux conditions soient réunies : qu'il existe un compte dont le champ de mot de passe est * (un compte sans mot de passe de connexion) et qu'il y ait au moins un autre compte dont le mot de passe est chiffré avec un hash de type $5$ ou $6$. Selon Alpine, l'attaque fonctionne toujours et ne demande aucune nouvelle tentative.

Ces détails techniques servent à comprendre le risque ; inutile de les retenir. L'important, c'est la conséquence : dans certaines configurations, le mot de passe cesse de protéger l'accès.

Qui est concerné

• Alpine Linux avec le paquet openssh-server, qui est compilé sans PAM, et aussi avec openssh-server-pam s'il a UsePAM no. Avec openssh-server-pam et UsePAM yes, il n'y a pas de problème.
• Toutes les versions d'Alpine examinées : de la 3.21 à la 3.24 et edge, ainsi que les anciennes sans mises à jour régulières (3.16 à 3.20).
• Images cloud d'Alpine (tiny-cloud) de la 3.18.11 à la 3.24.3 (formats comme qcow2, VHD ou AMI), si la machine contient un mot de passe avec un hash $6$.
• Non concerné : quiconque utilise des conteneurs Docker dans lesquels sshd n'est pas exécuté. Si vous avez un conteneur avec un serveur SSH à l'intérieur, traitez-le comme n'importe quel autre serveur.

Alpine est courant dans les conteneurs et les machines virtuelles légères, et moins sur les serveurs généralistes. Si votre entreprise a un VPS, un serveur à elle ou un équipement réseau, la question utile est simple : quel système d'exploitation utilise-t-il et le port SSH est-il ouvert sur internet ? Si vous ne le savez pas, demandez-le à la personne qui l'administre.

Versions corrigées

OpenSSH corrige la faille dans la 10.6p2. Chez Alpine, les paquets corrigés par branche sont les suivants :

• 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

Alpine a aussi publié des paquets corrigés pour les branches plus anciennes (3.16 à 3.20) et de nouvelles images cloud à partir des versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4. Consultez l'avis original d'Alpine avant d'agir, car c'est la source qui peut être mise à jour. Redémarrez le service SSH après la mise à jour : selon Alpine, mettre à jour le paquet ne redémarre pas un sshd qui était déjà en cours d'exécution, et tant qu'il n'est pas redémarré, c'est la version vulnérable qui continue de tourner (sous Alpine, rc-service sshd restart).

Est-elle exploitée ?

Ni OpenSSH ni Alpine ne signalent d'attaques observées. Alpine indiquait en outre que, lorsqu'elle a rédigé son avis, aucun identifiant CVE n'avait encore été attribué. Si vous voyez d'autres informations dans des médias ou des tableaux de bord de vulnérabilités (un numéro de CVE, un score ou des références à des attaques), comparez-les avec les avis officiels d'OpenSSH et d'Alpine avant de les tenir pour acquises. Il convient de la traiter malgré tout comme urgente : selon l'avis lui-même, l'attaque est simple et fiable.

Que faire dès aujourd'hui : la checklist

1. Identifiez vos serveurs dont le SSH est accessible et leur système d'exploitation (cat /etc/os-release). S'ils tournent sous Alpine, suivez les étapes ci-dessous.
2. Mettez à jour OpenSSH vers le paquet corrigé de votre branche et redémarrez sshd.
3. Si vous ne pouvez pas mettre à jour tout de suite, désactivez l'accès par mot de passe : mettez PasswordAuthentication no dans la configuration de sshd et redémarrez le service. Selon Alpine, l'une ou l'autre des deux mesures (correctif ou désactivation des mots de passe) referme la brèche. Avant de le faire, assurez-vous d'avoir un accès par clés ou par une autre voie, pour ne pas vous retrouver à la porte.
4. Examinez les journaux d'accès à la recherche de lignes « Accepted password for » concernant des comptes qui ne devraient pas pouvoir se connecter avec un mot de passe. C'est l'indice que suggère Alpine.
5. S'il y a des indices d'intrusion, changez les identifiants et les clés, isolez le serveur et consultez votre prestataire informatique ou l'INCIBE au 017.

Bonnes pratiques SSH qui réduisent ces risques

• Connectez-vous avec des clés, pas avec des mots de passe. Désactivez l'authentification par mot de passe dès que possible ; cette faille en est une bonne raison.
• Limitez qui peut se connecter : un pare-feu qui n'autorise que certaines adresses ou un VPN, et AllowUsers pour restreindre les comptes. Cela fait partie de ce que nous expliquons dans qu'est-ce qu'un pare-feu et de quoi une PME a besoin.
• Pas d'accès direct en tant qu'administrateur (root) : utilisez un utilisateur normal avec des droits élevés.
• Des outils contre les tentatives massives comme fail2ban, et des alertes quand quelqu'un d'inattendu se connecte.
• Un inventaire et un délai maximal de correctif pour les failles critiques (par exemple, 48 heures).
• Des sauvegardes testées, au cas où il faudrait reconstruire un serveur : règle 3-2-1.

Questions rapides

Suis-je concerné si j'utilise Ubuntu, Debian ou Red Hat ?

L'avis d'Alpine décrit un problème lié à la combinaison de musl, qu'utilise Alpine, avec sshd sans PAM. Les distributions basées sur glibc qui utilisent PAM ne correspondent pas à ce qui est décrit, mais le plus prudent est de consulter l'avis de votre distribution et la version d'OpenSSH installée. Et si le serveur est administré par mot de passe, c'est le bon moment de passer aux clés.

Et si mon site est sur un hébergement mutualisé ?

Alors l'administration du serveur incombe à l'hébergeur. Vous pouvez lui demander s'il utilise Alpine avec SSH exposé et quand il applique les correctifs de sécurité. Consultez aussi notre guide sur le nom de domaine et l'hébergement.

Et si j'ai un NAS ou un routeur avec SSH activé ?

L'avis d'Alpine ne les mentionne pas, nous ne pouvons donc pas dire qu'ils sont concernés. Mais beaucoup d'équipements réseau et de stockage fonctionnent sous Linux, et c'est le fabricant qui publie leurs correctifs : renseignez-vous sur l'état de SSH et désactivez-le si vous ne l'utilisez pas.

Comment Mitza peut vous aider

Nous faisons l'inventaire des serveurs, nous examinons les accès à distance et nous appliquons les correctifs et une configuration sécurisée de SSH. Voyez comment nous travaillons dans la maintenance informatique pour PME ou écrivez-nous depuis la page de contact.

À lire aussi : la faille critique du noyau Linux CVE-2026-98432 et audit de sécurité web.