OpenSSH sous Alpine : un contournement d’authentification à corriger

Une connexion possible sans mot de passe valide

Le 5 novembre 2026, OpenSSH et Alpine Linux ont publié des correctifs contre un contournement de l’authentification par mot de passe. Un attaquant pouvant atteindre le port SSH peut accéder à certains comptes sans connaître leur mot de passe. SSH est notamment utilisé pour administrer les machines à distance.

La vulnérabilité, identifiée CVE-2026-123158 dans le suivi officiel Alpine, concerne Linux avec la bibliothèque système musl et sans PAM actif, le mécanisme d’authentification modulaire. OpenSSH 10.6p2 apporte une protection dans le serveur sshd. Alpine fournit également des paquets corrigés dans ses différentes branches : leur numéro peut rester inférieur à 10.6p2.

Les configurations à faire examiner

Les entreprises concernées sont celles qui exploitent des machines Alpine exécutant sshd, y compris des instances cloud ou des conteneurs dans lesquels ce service est installé. Selon Alpine, les conditions suivantes doivent être réunies :

• le paquet openssh-server est utilisé sans PAM, ou openssh-server-pam fonctionne avec UsePAM no ;
• PasswordAuthentication est activé ;
• un compte accessible possède un champ de mot de passe égal à un astérisque dans /etc/shadow, ou relève des cas d’annuaire décrits par Alpine ;
• au moins un compte local possède une empreinte de mot de passe commençant par $5$ ou $6$.

Les comptes concernés peuvent être des utilisateurs prévus pour une connexion par clé, ou des utilisateurs d’annuaire passant par musl-nscd, notamment avec nslcd, winbind ou sssd. Pour root, le réglage par défaut PermitRootLogin prohibit-password protège l’accès direct ; PermitRootLogin yes l’expose si les autres conditions sont réunies. Un autre compte accessible peut toutefois permettre une élévation de privilèges, par exemple avec doas.

Alpine exclut les conteneurs sans sshd, les systèmes avec PasswordAuthentication no, ceux utilisant openssh-server-pam avec UsePAM yes et ceux sans aucune empreinte de mot de passe de type $. Les comptes verrouillés avec un point d’exclamation dans le champ de mot de passe sont également exclus. Les images configurées par cloud-init désactivent l’authentification par mot de passe.

Attention aux images officielles tiny-cloud de 3.18.11 à 3.24.3 : elles sont sûres au premier démarrage, mais leur utilisateur alpine, doté de doas sans mot de passe, devient exploitable dès qu’une empreinte $6$ apparaît sur la machine.

Les correctifs sont disponibles depuis le 5 novembre

Alpine a publié les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 avec le correctif. Les paquets openssh corrigés sont respectivement 9.9_p2-r1, 10.0_p1-r11, 10.2_p1-r1 et 10.3_p1-r2 ; edge dispose de 10.6_p2-r0.

Des paquets existent aussi pour les branches obsolètes : 3.20 avec 9.7_p1-r6, 3.19 avec 9.6_p1-r3, 3.18 avec 9.3_p2-r4, 3.17 avec 9.1_p1-r7 et 3.16 avec 9.0_p1-r6. Alpine précise que 3.21 a atteint sa fin de support le 1er novembre 2026 malgré ce correctif exceptionnel.

Dans sa mise à jour du 6 novembre, le CERT-FR insiste sur le redémarrage de sshd après installation du correctif ou modification de configuration. Alpine explique que la mise à jour du paquet seule ne remplace pas le service déjà lancé.

Les actions à confier à votre responsable informatique

• Recenser les serveurs concernés, leurs versions de paquets, les paramètres d’authentification et les comptes répondant aux conditions ci-dessus.
• Installer le paquet corrigé de la branche utilisée, puis redémarrer sshd. Comparer la révision complète du paquet aux références Alpine.
• Si la mise à jour est impossible, vérifier d’abord une connexion par clé, conserver la session courante ouverte, désactiver PasswordAuthentication, y compris dans les blocs Match, puis contrôler la configuration et redémarrer le service. À défaut, le CERT-FR recommande de désactiver le service.
• Examiner les journaux des machines exposées : rechercher les connexions « Accepted password for » concernant des comptes sans mot de passe, puis revoir les usages de doas et les utilisateurs, fichiers et clés autorisées récemment créés. Selon Alpine, si une connexion ne peut être exclue, traiter la machine comme compromise.

Pour ce suivi des accès et des correctifs, VCSTS entretient les protections du périmètre confié : mises à jour des composants couverts, revue des comptes et règles.