Le 5 novembre 2026, OpenSSH a publié la version portable 10.6p2 pour éviter un contournement de connexion sur certaines configurations Linux utilisant musl sans PAM. Alpine a diffusé des paquets corrigés. Pour les petites équipes qui administrent leurs applications par SSH, la priorité est de vérifier les machines réellement exposées et le processus qui tourne après la mise à jour.
Une combinaison de réglages à vérifier
Alpine détaille les conditions : connexions par mot de passe autorisées, compte dont le champ de mot de passe contient une étoile et autre compte local possédant un hash de type SHA-256 ou SHA-512. Cette combinaison peut permettre un accès sans connaître le mot de passe. L’avis ne signifie donc pas que toute installation Linux ou tout conteneur Alpine est vulnérable.
La clé personnelle ne décrit pas le serveur
Un administrateur peut se connecter uniquement par clé alors que sshd accepte encore les mots de passe pour d’autres comptes. C’est la configuration effective du serveur qui compte. L’analyse de BleepingComputer aide à distinguer compte sans mot de passe et service refusant cette méthode; The Hacker News replace le problème dans le périmètre des systèmes musl. Les tests publiés par Check Point ajoutent que l’autre compte utilisé doit être actif.
Mettre à jour sans perdre l’accès
Suivez l’avis Alpine pour la branche installée, puis redémarrez sshd. Les distributions peuvent intégrer le correctif sans reprendre le numéro amont 10.6p2 : comparez le paquet complet à l’avis officiel. Si vous devez désactiver provisoirement les connexions par mot de passe, conservez une session de maintenance et vérifiez d’abord qu’une nouvelle connexion autorisée par clé fonctionne. Évitez de fermer votre seul accès avant cette vérification.
Contrôler aussi les traces de connexion
Alpine recommande d’examiner les connexions par mot de passe acceptées pour des comptes censés ne pas en posséder, puis les usages de doas et les changements de comptes ou de clés autorisées. Une équipe doit distinguer deux preuves : le serveur est corrigé et aucune intrusion n’a été identifiée. La première ne fournit pas automatiquement la seconde. En cas de doute, faites examiner la machine avant d’y réinstaller des secrets.
Le lien avec Soclyde
Pour une TPE utilisant Alpine, les mots de passe des consoles d’hébergement ou de secours restent à organiser même si SSH utilise des clés. Soclyde conserve ces identifiants dans un coffre chiffré sur les appareils. Il ne corrige pas sshd et ne remplace pas la vérification des connexions. Après une intrusion avérée, le renouvellement des accès doit être effectué dans les services concernés.
À retenir
Inventoriez les hôtes Alpine qui exécutent sshd, contrôlez leur configuration et conservez la preuve du paquet installé et du redémarrage. Pour préparer la gestion des accès après un incident, consultez notre guide mot de passe piraté : que faire.
