> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # SSHole (CVE-2026-123158) : contournement du mot de passe SSH sur Alpine Linux > OpenSSH sur musl sans PAM, dont Alpine Linux, accepte un mot de passe trop long. Faille exploitée. Exposition, correctifs Alpine, conteneurs et mitigation. *Publié le 13 novembre 2026* > [!WARNING] > > **CVE-2026-123158 — OpenSSH sshd, systèmes musl sans PAM.** La faille permet de se connecter en SSH sans connaître le mot de passe. Elle est exploitée : la CISA l'a ajoutée à son catalogue des vulnérabilités activement exploitées (KEV) le 9 novembre 2026. Les VPS Debian, Ubuntu et AlmaLinux ne sont pas touchés. Vérifiez en revanche vos machines et conteneurs Alpine qui exposent sshd. ## Le problème en deux phrases Compilé sans PAM, sshd vérifie un mot de passe en le hachant avec la fonction `crypt()` de la bibliothèque C, puis en comparant le résultat au champ stocké dans `/etc/shadow`. Avec la bibliothèque musl, `crypt()` renvoie `*` quand le mot de passe dépasse 256 octets : c'est justement le contenu du champ des comptes sans mot de passe, et la connexion est acceptée. Versions touchées : * **OpenSSH avant 10.6p2**, sur Linux, compilé avec musl et sans PAM ; * **Alpine Linux**, toutes les branches de 3.16 à 3.24 et edge, selon l'avis Alpine. Le correctif est sorti le 5 novembre 2026 : OpenSSH 10.6p2, et des paquets corrigés pour chaque branche d'Alpine. Le score publié par NVD et cve.org est de 8.1 (complexité d'attaque élevée). Red Hat retient un score préliminaire de 9.8. Ubuntu classe la faille en priorité haute. > [!NOTE] > > GreyNoise a observé une première exploitation réussie le 7 novembre 2026, deux jours après la publication du correctif et d'un exploit public. Les sessions relevées enchaînent reconnaissance, lecture de `/etc/shadow` et création d'un compte `server_manager` doté d'une règle `doas` sans mot de passe. ## Évaluer son exposition Selon l'avis Alpine, une machine est exposée si **toutes** ces conditions sont réunies : * sshd vient du paquet `openssh-server` (compilé sans PAM), ou de `openssh-server-pam` avec `UsePAM no` ; * `PasswordAuthentication` vaut `yes`, la valeur par défaut d'OpenSSH ; * un compte a `*` comme champ de mot de passe : `root` dans l'image de base, un utilisateur qui ne se connecte que par clé, un utilisateur d'annuaire ; * au moins un autre compte local a un mot de passe haché en `$5$` ou `$6$`. L'attaquant doit connaître le nom du compte visé. `root` reste protégé par le réglage par défaut `PermitRootLogin prohibit-password`, sauf si un autre compte accessible peut devenir root, par exemple avec `doas`. | Profil | Exposition | Action | | - | - | - | | VPS Debian, Ubuntu, AlmaLinux, Rocky Linux, RHEL (sshd du système) | Non affecté | Aucune action sur l'hôte | | Alpine avec sshd et `PasswordAuthentication yes`, accessible depuis Internet | **Critique** | Mettre à jour aujourd'hui et redémarrer sshd | | Conteneur Alpine qui exécute sshd et publie son port | **Critique** | Reconstruire l'image avec le paquet corrigé ; à défaut, couper les mots de passe | | Image cloud Alpine tiny-cloud de 3.18.11 à 3.24.3 | **Critique** dès qu'un mot de passe est défini | Mettre à jour ou couper les mots de passe sur chaque instance | | Alpine avec `PasswordAuthentication no`, ou `openssh-server-pam` avec `UsePAM yes` | Non affecté | Mettre à jour lors de la prochaine maintenance | | Conteneur Alpine sans sshd | Non affecté | Aucune action | | Équipement embarqué sous musl sans PAM (images Yocto, par exemple) | Possible | Interroger le fournisseur | > [!NOTE] > > Les images tiny-cloud officielles (qcow2, VHD, AMI) livrent un utilisateur `alpine` sans mot de passe et autorisé à `doas` sans mot de passe. Elles sont sûres au premier démarrage, et deviennent exploitables dès qu'un mot de passe haché apparaît sur la machine, par exemple un mot de passe console défini par l'administrateur. ## VPS Debian, Ubuntu, AlmaLinux : l'hôte n'est pas exposé Ubuntu indique que son OpenSSH est lié à glibc et utilise PAM, donc non vulnérable, sur toutes ses versions. Red Hat déclare ses produits non affectés. Debian classe la faille « unimportant » pour son paquet et n'intègre le correctif qu'en unstable et forky. Le sshd de votre VPS n'appelle donc aucune action. Ce qu'il faut vérifier, ce sont les conteneurs Alpine qui tournent dessus. ```bash theme={null} # Conteneurs en cours : nom, image, ports publiés docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}' # Pour un conteneur qui publie un port SSH : distribution et présence de sshd docker exec cat /etc/alpine-release docker top | grep sshd ``` Un conteneur qui répond par un numéro de version Alpine et qui fait tourner sshd relève de la section suivante. Même logique pour un pod Kubernetes construit sur une image Alpine qui lance sshd. ## Mettre à jour Alpine Linux Le correctif est la mise à jour du paquet `openssh`, suivie d'un redémarrage de sshd. **La mise à jour seule ne remplace pas le démon déjà lancé.** | Branche | Paquet `openssh` corrigé | | - | - | | 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` | | 3.20 | `9.7_p1-r6` | | 3.19 | `9.6_p1-r3` | | 3.18 | `9.3_p2-r4` | | 3.17 | `9.1_p1-r7` | | 3.16 | `9.0_p1-r6` | Les versions ponctuelles 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent le paquet corrigé. Alpine a aussi publié des paquets pour les branches qui ne reçoivent plus de mises à jour régulières, jusqu'à 3.16. ```bash theme={null} # Alpine : installer le correctif puis redémarrer sshd apk upgrade -U -a rc-service sshd restart # Contrôler la version installée apk list -I | grep openssh ``` ### Conteneurs Docker Si l'image est la vôtre, reconstruisez-la sur une version d'Alpine qui contient le correctif (3.21.10, 3.22.8, 3.23.8, 3.24.4 ou ultérieure), puis recréez le conteneur. ```bash theme={null} # Reconstruire en tirant la dernière image de base docker build --pull --no-cache -t . ``` En attendant, vous pouvez corriger un conteneur en cours d'exécution : ```bash theme={null} docker exec apk upgrade -U -a docker restart ``` Cette correction disparaît à la prochaine recréation du conteneur : seule la reconstruction de l'image est durable. Pour une image tierce, attendez la version corrigée de l'éditeur et appliquez la mitigation ci-dessous en attendant. ## Mitigation en attendant le correctif Alpine recommande de désactiver l'authentification par mot de passe. Avant de commencer, vérifiez que la connexion par [clé SSH](https://help.onetsolutions.net/fr/vps/ssh-keys) fonctionne et gardez votre session ouverte jusqu'à avoir testé une nouvelle connexion. À exécuter en root : ```bash theme={null} # Fichier de configuration complémentaire (lu par Alpine à partir de 3.19) mkdir -p /etc/ssh/sshd_config.d echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf # Passer à no chaque ligne PasswordAuthentication, en ajouter une en tête, sauvegarder l'original en .bak sed -i.bak -e '1i PasswordAuthentication no' \ -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \ /etc/ssh/sshd_config # Valider la configuration et redémarrer sshd sshd -t && rc-service sshd restart ``` La commande `sed` modifie aussi les lignes situées dans un bloc `Match`. ## Vérifier la mitigation ```bash theme={null} sshd -T | grep -i passwordauthentication ``` Attendu : `passwordauthentication no`. Après une mise à jour, comparez la sortie de `apk list -I | grep openssh` avec le tableau de votre branche. ## Chercher des traces Des exploitations sont constatées depuis le 7 novembre. Sur une machine Alpine exposée, cherchez des connexions par mot de passe sur des comptes qui n'en ont pas : ```bash theme={null} # Connexions acceptées par mot de passe grep 'Accepted password for' /var/log/messages # Comptes sans mot de passe (champ *) awk -F: '$2 == "*" {print $1}' /etc/shadow ``` Une ligne `Accepted password for` sur l'un de ces comptes (`root`, `alpine`, un utilisateur à clé) signe une intrusion. Passez aussi en revue l'usage de `doas`, les comptes, fichiers et clés `authorized_keys` récents. Un compte `server_manager` que vous n'avez pas créé est un indicateur relevé par GreyNoise. Si vous ne pouvez pas exclure une connexion, traitez la machine comme compromise. ## Annuler la mitigation Une fois le paquet corrigé installé, si vous avez besoin des mots de passe : ```bash theme={null} rm /etc/ssh/sshd_config.d/00-no-passwords.conf cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config sshd -t && rc-service sshd restart ``` ## Et après ? La connexion par clé sans mot de passe reste la meilleure configuration pour un serveur exposé : gardez `PasswordAuthentication no` même après la mise à jour. Pour une autre faille OpenSSH récente, lisez [regreSSHion (CVE-2024-6387)](https://blog.onetsolutions.net/fr/regresshion-cve-2024-6387.md). Pour toute question technique, ouvrez un ticket depuis votre [espace client OnetSolutions](https://help.onetsolutions.net/fr/console/support). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.