OpenSSH 10.6p2 : vérifier les systèmes musl sans perdre l’accès SSH

État au 8 novembre 2026. Portable OpenSSH 10.6p2 est paru le 5 novembre. Il apporte un contournement critique contre une possible faille d’authentification par mot de passe sur certains systèmes Linux utilisant musl sans PAM. Ce guide aide les administrateurs à déterminer leur exposition et à valider une mise à jour sans se couper l’accès. Ce n’est pas un essai personnel du produit ou d’une attaque. [1]

Quels systèmes vérifier ?

Il faut identifier le serveur OpenSSH réellement exécuté, pas seulement la distribution. L’avis musl vise OpenSSH antérieur à 10.6p2 avec UsePAM=no et PasswordAuthentication=yes ; les compilations sans PAM doivent aussi être prises en compte. Alpine est un exemple, non une liste exhaustive. Le mainteneur exclut de cette faille précise les systèmes non Linux, Linux/glibc et ceux utilisant PAM pour les mots de passe. L’avis musl exclut Dropbear. Ce n’est pas un certificat général de sécurité. [2] [4]

Prérequis et restauration préparée

Il faut un accès administrateur autorisé, la documentation du paquet ou de l’image et une console ou récupération indépendante de SSH. Gardez une session existante ouverte, sans la considérer comme un secours garanti. Protégez les copies de configuration, fichiers inclus, versions et éléments de restauration ; ne placez jamais les clés privées du serveur dans un ticket ou une conversation. Pour une appliance, utilisez le micrologiciel pris en charge, pas des exécutables remplacés isolément.

Cinq étapes vers un état vérifié

  1. Inventoriez le serveur : déterminez paquet, libc, prise en charge PAM et service actif grâce aux informations des paquets, avis du fournisseur et métadonnées d’image. ssh -V indique le client local, pas le serveur. Si disponible, sshd -V identifie l’exécutable invoqué sans prouver que le processus actif utilise ce fichier. Évaluez les correctifs rétroportés via l’avis fournisseur, pas uniquement la version. [3]
  2. Lisez les réglages effectifs : avec le bon exécutable et le fichier utilisé par le service, employez sshd -t pour vérifier configuration/clés et sshd -T pour afficher les réglages, avec les droits et chemins nécessaires. Pour les règles Match, fournissez les paramètres -C adaptés selon le manuel installé. Examinez ensemble compilation PAM, UsePAM et mots de passe. Une configuration valide ne prouve pas la correction de la faille. [3]
  3. Agissez immédiatement si la combinaison est concernée : musl indique PasswordAuthentication no comme mesure provisoire. Vérifiez d’abord une connexion par clé dans une nouvelle session distincte et l’accès à la console de secours. Modifiez ensuite la configuration effective de façon contrôlée, validez-la et redémarrez selon le fournisseur. Sans accès sûr, ne basculez pas à l’aveugle : passez par console/responsable ou limitez l’exposition selon la procédure d’urgence autorisée. N’activez pas PAM ou d’autres méthodes à titre d’essai. [2] [4]
  4. Installez le correctif fournisseur : utilisez le paquet ou l’image approuvé pour le système ou l’appliance, contenant le contournement 10.6p2 ou un rétroportage documenté, depuis une source fiable. Préparez restauration et maintenance, puis renouvelez le service actif selon la documentation. Évitez dépôt tiers improvisé, compilation superposée et désactivation globale des protections.
  5. Reconnectez-vous et validez : dans une connexion neuve, vérifiez clés, droits administratifs requis et usages SFTP/automatisation nécessaires. Contrôlez à nouveau paquet/image, règles effectives et journaux ; aucun essai d’exploitation n’est nécessaire. Fermez l’ancienne session après validation seulement. En cas d’échec, restaurez le socle protégé depuis la console ; ne conservez pas durablement un service non corrigé exposé à nouveau avec mots de passe.

Comment confirmer le résultat

La mesure est terminée lorsque le correctif documenté est actif dans le service et que de nouvelles connexions et tâches fonctionnent. Paquet installé, bannière ou ancienne session ne suffisent pas. Après une désactivation temporaire des mots de passe, n’envisagez leur réactivation qu’après confirmation du correctif et accord opérationnel. Conserver l’accès par clé uniquement reste une décision de sécurité distincte.

Limites et sources

Ce guide ne modifie aucun serveur automatiquement et ne remplace ni l’avis de la distribution ni l’autorisation locale. Une ancienne version peut être corrigée ; tous les appareils musl n’utilisent pas OpenSSH. Faites préciser compilation et rétroportage par le fournisseur et privilégiez la limitation d’exposition en attendant. Aucune attribution CVE universelle, détection d’attaque ou migration réalisée n’est revendiquée.