OpenSSH sur Alpine : contournement critique de l’authentification par mot de passe, que vérifier sur VPS et conteneurs

Le 5 novembre 2026, Portable OpenSSH 10.6p2 a été publié avec une mitigation critique : un contournement de l’authentification par mot de passe exploitable via sshd sur les systèmes Linux basés sur musl avec PAM désactivé. C’est le profil typique d’Alpine Linux, souvent utilisé dans des conteneurs et des images cloud légères. Le même jour, Alpine a publié une alerte dédiée.

Pour une PME tessinoise, la question pratique n’est pas seulement « sommes-nous sur Alpine ou Ubuntu ? », mais : où tourne un sshd joignable, sur quel système et avec quelle méthode de connexion ? Beaucoup de bureaux utilisent des VPS Ubuntu ou un hébergement Infomaniak (glibc + PAM) : ils sont hors du périmètre indiqué. Le risque augmente si vous (ou un fournisseur) faites tourner des conteneurs ou des VM Alpine avec SSH exposé et le login par mot de passe encore actif.

Ce que disent OpenSSH et Alpine

Dans les notes de version, l’équipe OpenSSH indique que la cause racine est considérée comme externe à sshd, mais qu’elle est exploitable via sshd et peut y être évitée. Le signalement est d’Özgün Kültekin (Wakefield). Alpine résume l’impact opérationnel : dans des conditions de configuration typiques des installations Alpine sans PAM, quiconque peut atteindre le port SSH peut s’authentifier sans connaître de mot de passe valide. Au moment de l’alerte Alpine, aucun identifiant CVE n’avait encore été attribué.

Damien Miller (OpenSSH), dans son annonce de release reprise par LWN, a clarifié trois points utiles pour les exploitants :

• le problème concerne Linux avec musl et sans PAM (Alpine en est l’exemple typique) ;
• il ne concerne pas les systèmes non Linux, Linux avec glibc, ni Linux qui utilise PAM pour l’authentification par mot de passe ;
• la publication a été accélérée parce que des agents d’IA redécouvrent des bogues déjà connus en quelques heures, si bien que de longs embargos aident surtout les attaquants.

Il confirme aussi qu’une compilation avec PAM disponible mais UsePAM no reste dans le périmètre. Alpine précise que le paquet openssh-server-pam avec UsePAM yes n’est pas concerné ; en revanche openssh-server (sans PAM) ou PAM avec UsePAM no l’est si PasswordAuthentication vaut yes.

Qui est hors périmètre, qui est dedans

Hors périmètre typique (selon OpenSSH et Alpine) : serveurs de type Debian/Ubuntu avec glibc et authentification par mot de passe via PAM ; systèmes avec PasswordAuthentication no ; conteneurs qui n’exécutent pas sshd ; images cloud déjà configurées (souvent via cloud-init) pour n’accepter que des clés SSH.

À vérifier immédiatement : hôtes Alpine (branches supportées et plus anciennes) avec sshd en écoute, OpenSSH sans PAM ou avec PAM désactivé, et login par mot de passe encore activé. Cela vaut aussi pour de petits VPS, bastions, runners CI et appliances basées sur Alpine laissées joignables depuis Internet « juste pour un accès d’urgence ».

Que vérifier au bureau

1. Inventaire SSH. Lister chaque machine, VM et conteneur où tourne sshd et depuis où il est joignable (réseau interne seulement, VPN, Internet). Si le port 22 (ou un autre port SSH) est ouvert sur Internet, c’est la priorité absolue. Le même inventaire sert lorsqu’on contrôle les services exposés : nous en avons parlé pour les NAS et la redirection de ports dans l’article du 4 novembre.
2. Système d’exploitation et libc. Sur des hôtes Ubuntu/Debian/Infomaniak typiques, vous êtes hors du cas musl+sans-PAM. Sur Alpine, images « slim » ou appliances basées sur musl, traitez l’hôte comme potentiellement concerné jusqu’à vérification du paquet et de la configuration.
3. Méthode de connexion. Préférer les clés SSH et désactiver le login par mot de passe lorsqu’il n’est pas nécessaire. Les niveaux de sécurité des accès (mot de passe, SMS, passkey) sont expliqués dans notre article sur les cinq niveaux de l’OFCS.
4. Version OpenSSH et redémarrage du démon. Alpine souligne que la mise à jour du paquet ne remplace pas à elle seule le démon en cours d’exécution : il faut redémarrer sshd après l’upgrade. Les branches Alpine indiquées dans l’alerte (d’edge à 3.16 et suivantes) ont des paquets corrigés ; OpenSSH en amont pointe vers 10.6p2 pour la mitigation.
5. Fournisseurs et conteneurs. Demander à qui gère l’hébergement, Kubernetes ou la CI s’il existe des nœuds ou images Alpine avec SSH exposé. Un conteneur sans sshd est hors périmètre ; un conteneur avec SSH et mots de passe ne l’est pas.

Mitigations défensives

Deux voies ferment la brèche, comme l’indique Alpine :

1. Mettre à jour le paquet OpenSSH/Alpine vers la version corrigée de votre branche et redémarrer sshd.
2. Si vous ne pouvez pas mettre à jour tout de suite : définir PasswordAuthentication no (clés uniquement), vérifier d’abord que la connexion par clé fonctionne et garder la session courante ouverte jusqu’à avoir testé une nouvelle connexion ; puis redémarrer sshd.

Nous ne publions ni étapes d’exploitation ni charges utiles : l’objectif est de fermer l’exposition, pas de la reproduire. Pour les autres failles récentes sur les piles web et serveurs, voir notre bilan de fin octobre.

Questions fréquentes

Notre VPS est sous Ubuntu chez Infomaniak : faut-il agir aujourd’hui ?

Selon OpenSSH, Linux avec glibc et authentification par mot de passe via PAM n’entre pas dans cette vulnérabilité. Maintenir OpenSSH à jour et préférer les clés SSH reste une bonne pratique, mais ce n’est pas le scénario Alpine/musl sans PAM.

Nous n’utilisons que des conteneurs Docker basés sur Alpine, sans SSH à l’intérieur : sommes-nous exposés ?

Alpine indique que ceux qui n’exécutent pas sshd dans le conteneur ne sont pas concernés. Le risque porte sur les environnements où SSH écoute et est joignable.

Nous avons mis à jour le paquet mais pas redémarré sshd : cela suffit-il ?

Non. Alpine avertit explicitement que la mise à jour du paquet ne remplace pas le démon déjà en cours : il faut redémarrer sshd.

Un CVE a-t-il déjà été attribué ?

À la date de l’alerte Alpine (5 novembre 2026), aucun identifiant CVE n’avait encore été attribué. Suivez les notes OpenSSH 10.6p2 et l’alerte Alpine, pas un numéro CVE inventé.

Notre approche

ElaraTeq Sagl aide les PME et cabinets au Tessin à inventorier les accès SSH, à choisir entre clés et mots de passe et à planifier les mises à jour sur VPS, conteneurs et hébergement en Suisse (hébergement, conseil). Pour vérifier votre exposition, vous pouvez nous contacter.

Sources

• OpenSSH, notes de version Portable OpenSSH 10.6p2, 5 novembre 2026
• Alpine Linux, Security advisory: openssh-server password authentication bypass, 5 novembre 2026
• Damien Miller, annonce OpenSSH 10.6p2, 5 novembre 2026
• LWN.net, Critical security vulnerability affects OpenSSH on Alpine Linux systems, 5 novembre 2026