Faille OpenSSH sur Alpine : votre serveur est-il concerné ?

Le contournement de l’authentification par mot de passe d’OpenSSH sur Alpine ne touche pas tous les serveurs ni tous les conteneurs Alpine. Vérifiez si un démon SSH est en cours d’exécution, s’il autorise l’authentification par mot de passe, si PAM est actif et si les conditions relatives aux comptes décrites dans l’avis d’Alpine sont réunies. Le seul usage de clés SSH ne suffit pas à conclure que vous êtes à l’abri : l’authentification par mot de passe peut rester activée en parallèle. Avis d’Alpine.

OpenSSH a publié sa version portable 10.6p2 le 5 novembre 2026, avec une mesure de contournement critique pour les systèmes Linux utilisant musl sans PAM. Selon le projet OpenSSH, la cause du problème se situe en dehors de sshd. L’identifiant CVE-2026-123158 est désormais attribué, alors que l’avis d’Alpine indiquait initialement qu’aucun identifiant n’avait encore été attribué. Notes de version d’OpenSSH, fiche CVE publiée.

Le tableau ci-dessous rassemble les conditions énoncées par Alpine pour vous aider à déterminer si la faille vous concerne. Il s’agit d’une interprétation de l’avis, pas d’une analyse de votre infrastructure ni d’une reproduction de la vulnérabilité. Les versions des paquets correspondent à la situation du 6 novembre ; consultez l’avis cité pour les évolutions ultérieures.

Quels serveurs SSH Alpine sont concernés ?

Plusieurs conditions doivent être réunies pour qu’une configuration soit vulnérable. La présence d’Alpine, l’installation d’un paquet OpenSSH ou un numéro de version apparemment ancien ne suffisent pas à établir que ces conditions sont réunies.

Alpine décrit un mécanisme d’authentification sans PAM, avec les connexions par mot de passe activées, un compte répondant aux critères dont le champ de mot de passe contient *, et un autre compte local dont le mot de passe est haché avec $5$ ou $6$. Le paquet standard openssh-server utilise le mécanisme sans PAM. Installer openssh-server-pam ne change pas cette condition si UsePAM reste à no. Conditions préalables décrites par Alpine.

Utilisez ce tableau pour ce contournement précis. La mention « non concerné » suppose que vous avez établi la configuration active pour le compte et la connexion en question.

Ces catégories synthétisent l’avis d’Alpine. Elles ne décrivent pas la sécurité globale du système et ne permettent pas de déterminer si une compromission a déjà eu lieu.

La valeur du champ de mot de passe est déterminante. Alpine distingue la valeur de substitution * du marqueur de verrouillage ! ; ne considérez pas comme équivalents tous les champs qui semblent désactiver un mot de passe. Vérifiez les conditions relatives aux comptes dans le cadre de vos procédures d’administration autorisées, sans copier les empreintes de mots de passe dans des tickets ou des discussions. Ne modifiez pas ces champs pour improviser une solution de contournement.

Examinez aussi attentivement les règles d’accès de root. Un réglage qui bloque la connexion directe de root par mot de passe ne permet pas de savoir si un autre compte répondant aux critères est exposé. De même, un réseau privé change les personnes qui peuvent joindre un service ; il ne change pas le fait que sa configuration d’authentification corresponde ou non à l’avis.

Les clés SSH vous protègent-elles ?

« Nous utilisons des clés SSH » et PasswordAuthentication no sont deux faits différents. Une connexion réussie avec une clé prouve que l’authentification par clé fonctionne. Elle ne prouve pas que le serveur refuse l’authentification par mot de passe pour cet utilisateur ou pour les autres.

Cette distinction passe facilement inaperçue dans une petite équipe. Tout le monde peut avoir cessé de saisir des mots de passe depuis des années alors que le démon accepte toujours les tentatives d’authentification par mot de passe. Examinez le réglage du serveur au lieu de le déduire des habitudes de connexion de l’équipe. Alpine cite explicitement la désactivation de l’authentification par mot de passe parmi les cas exclus de ce contournement. Conseils de configuration d’Alpine.

Le même raisonnement vaut pour PAM, le système d’authentification utilisé par le paquet serveur alternatif. Confirmez à la fois le paquet installé et le réglage actif de UsePAM. Un inventaire des paquets qui mentionne « PAM » ne suffit pas si le service est configuré pour ne pas l’utiliser.

Les images cloud nécessitent une vérification distincte. L’avis d’Alpine traite séparément tiny-cloud et cloud-init : évitez donc de supposer que toutes les images cloud ont la même configuration. Identifiez la configuration de l’image et les modifications apportées ensuite aux comptes, puis comparez-les aux précisions d’Alpine sur les images cloud. Le nom d’une image de base ne révèle pas ce qu’un administrateur a changé après le démarrage.

Quels paquets Alpine contiennent le correctif ?

Alpine a rétroporté la correction vers d’anciennes branches de paquets. Comparez votre branche et la révision complète du paquet au tableau d’Alpine, plutôt que d’exiger que chaque machine affiche la version amont 10.6p2.

Quelques versions corrigées, vérifiées le 6 novembre :

Source : tableau des paquets corrigés d’Alpine. Il s’agit d’un extrait, pas d’une liste exhaustive des versions prises en charge. Consultez l’avis pour les autres branches. Un rétroportage ne rétablit pas la prise en charge d’une version arrivée en fin de vie.

Pour un service concerné, suivez les instructions de mise à jour des paquets d’Alpine et redémarrez sshd. Pour un service Alpine géré par OpenRC, l’avis indique :

rc-service sshd restart

Si le démon est géré par un conteneur ou un autre gestionnaire de services, suivez la procédure du superviseur réellement utilisé. Si vous ne pouvez pas effectuer la mise à jour immédiatement, Alpine propose de désactiver l’authentification par mot de passe, puis de redémarrer le service pour atténuer le risque. Suivez les instructions d’atténuation d’Alpine plutôt que de recopier une modification de configuration dans un environnement que vous connaissez mal.

Avant de modifier l’accès distant, gardez ouverte une session authentifiée par clé et conservez l’accès à la console de secours. Prévoyez de vérifier une connexion autorisée depuis une autre session pour éviter qu’une erreur de configuration vous prive de l’accès au serveur.

Que vérifier après la mise à jour ?

Vérifiez la configuration dans le même contexte que le service, puis confirmez que la modification du service a bien pris effet. La vérification de la configuration et l’ouverture d’une nouvelle connexion répondent à deux questions différentes.

Le manuel officiel décrit sshd -t pour vérifier la configuration et les clés, et sshd -T pour afficher la configuration effective après analyse. Ajoutez -C pour évaluer les règles Match qui dépendent de la connexion. Par exemple :

sshd -t
sshd -T -C user=example,addr=192.0.2.10,host=example.test

L’utilisateur, l’adresse et le nom d’hôte sont ici des exemples. Remplacez-les par un contexte de connexion pertinent et examinez les autres contextes où les règles diffèrent. Utilisez le même exécutable, le même fichier de configuration et les mêmes options de démarrage que le service en cours d’exécution. Manuel officiel de sshd.

Ces commandes démarrent un nouveau processus. Elles n’interrogent pas les réglages déjà chargés par le démon en cours d’exécution. Leur réussite ne remplace donc pas la vérification que le redémarrage prévu s’est terminé et que le service corrigé fonctionne.

Après la modification, ouvrez une autre session autorisée, authentifiée par clé, tout en conservant votre accès existant. Confirmez que le compte prévu fonctionne toujours et que le service utilise les réglages d’authentification attendus. Ne tentez pas d’exploiter le contournement en production pour vous rassurer. Une nouvelle connexion réussie vérifie l’accès ; elle ne prouve ni que l’authentification par mot de passe est désactivée, ni qu’aucune compromission antérieure n’a eu lieu.

Confiez les vérifications en suspens à un responsable

Gardez visibles les conditions qui restent à vérifier. « Réglage PAM inconnu » ou « redémarrage non confirmé » indique au prochain ingénieur ce qu’il reste à établir ; une mention générale « Alpine vérifié » masque ce travail.

Si un service concerné fait l’objet d’un rapport de vulnérabilité, Kit Security peut réunir son responsable, son évaluation, les échanges internes et la vérification du correctif consignée dans le rapport. C’est toujours à votre équipe d’apporter les preuves relatives à l’hôte et au service ; le suivi des rapports ne découvre pas automatiquement les serveurs Alpine et ne vérifie pas l’état des démons.

Commencez par le service que votre équipe peut examiner dès maintenant. Établissez son mécanisme d’authentification, comparez son paquet au correctif prévu pour sa branche Alpine et confirmez la modification nécessaire du service. Veillez à ce qu’un responsable reste chargé des questions de configuration en suspens jusqu’à leur résolution.