OpenSSH 10.6p2: musl-Systeme prüfen, ohne den SSH-Zugang zu verlieren

Stand: 8. November 2026. Portable OpenSSH 10.6p2 ist seit dem 5. November verfügbar. Anlass ist ein kritischer Workaround gegen eine mögliche Umgehung der Passwortanmeldung auf bestimmten Linux-Systemen mit musl und ohne PAM. Diese Anleitung hilft Administratoren, Betroffenheit und Updateweg zu prüfen, ohne sich beim Eingriff auszusperren. Sie ist kein selbst durchgeführter Produkt- oder Angriffstest. [1]

Welche Systeme gehören in die Prüfung?

Entscheidend ist der tatsächlich laufende OpenSSH-Server, nicht allein der Name der Distribution. Die musl-Meldung nennt OpenSSH vor 10.6p2 mit UsePAM=no und PasswordAuthentication=yes; fehlender PAM-Buildsupport muss ebenfalls berücksichtigt werden. Alpine ist ein Beispiel, keine pauschale Liste aller betroffenen Geräte. Der OpenSSH-Maintainer grenzt Nicht-Linux-, glibc- und für Passwortanmeldung PAM-nutzende Systeme von genau dieser Lücke ab. Dropbear ist laut musl-Meldung nicht betroffen. Das ist keine allgemeine Sicherheitsfreigabe. [2] [4]

Voraussetzungen und gesicherter Rückweg

Erforderlich sind autorisierter Administrationszugriff, Paket-/Image-Dokumentation und eine funktionierende Konsole oder ein anderer vom SSH-Dienst unabhängiger Rettungszugang. Eine bestehende SSH-Sitzung offen halten, aber nicht als garantierten Rückweg betrachten. Konfiguration einschließlich Include-Dateien, Paketstand und nötige Wiederherstellungsdaten geschützt sichern; private Hostschlüssel nie in Tickets oder Chats kopieren. Bei Appliances den unterstützten Firmwareweg verwenden, nicht beliebige Binärdateien ersetzen.

In fünf Schritten zum geprüften Zustand

1. Bestand feststellen: Serverpaket, libc, PAM-Build und aktiven Dienst aus Paketverwaltung, Herstellerhinweisen und Image-Metadaten ermitteln. ssh -V zeigt den lokalen Client und beweist nicht den Serverstand. Falls die installierte Version es unterstützt, zeigt sshd -V die Version der aufgerufenen Serverdatei; auch das beweist nicht, dass der laufende Prozess bereits diese Datei verwendet. Anbieter-Backports anhand des Advisories bewerten, nicht nur Versionsnummern vergleichen. [3]
2. Effektive Einstellungen lesen: Mit dem richtigen Serverprogramm und derselben Konfigurationsdatei wie beim Dienst sshd -t zur Syntax-/Schlüsselprüfung und sshd -T zur Ausgabe wirksamer Einstellungen nutzen; notwendige Rechte und Dateipfade beachten. Bei Match-Regeln passende -C-Verbindungsparameter nach lokalem Handbuch angeben. UsePAM, Passwortanmeldung und Paket-Build zusammen bewerten. Ein erfolgreicher Konfigurationstest beweist keine geschlossene Sicherheitslücke. [3]
3. Bei betroffener Kombination unverzüglich handeln: Das musl-Advisory nennt PasswordAuthentication no als Zwischenmaßnahme. Zuerst Schlüsselanmeldung in einer zweiten, neuen Sitzung und Rettungskonsole prüfen, dann die wirksame Konfiguration kontrolliert ändern, testen und den Dienst nach Anbieteranleitung neu starten. Fehlt ein sicherer Zugang, nicht blind umschalten: über Konsole/Verantwortliche den Zugang absichern oder die Exposition nach dem genehmigten Notfallverfahren begrenzen. Nicht probeweise PAM oder andere Anmeldearten aktivieren. [2] [4]
4. Herstellerfix einspielen: Das für Betriebssystem beziehungsweise Appliance freigegebene Paket oder Image mit dem 10.6p2-Workaround beziehungsweise dokumentiertem Backport aus vertrauenswürdiger Quelle verwenden. Vorher Wiederherstellung und Wartungsfenster sichern; anschließend den tatsächlich laufenden Server entsprechend der Anbieteranleitung erneuern. Kein fremdes Repository, kein spontanes Quellcode-Overlay und kein globales Abschalten von Schutzfunktionen als Abkürzung.
5. Neu verbinden und abnehmen: In einer frischen Verbindung Schlüsselanmeldung, erforderliche Verwaltungsrechte und benötigte SFTP-/Automationsabläufe prüfen. Paket-/Image-Stand, wirksame Regeln und Dienstprotokolle erneut kontrollieren; kein Exploitversuch erforderlich. Erst nach erfolgreicher Abnahme die alte Sitzung schließen. Bei Fehlern über die Rettungskonsole den gesicherten Zustand kontrolliert wiederherstellen; keinen ungepatchten, erneut exponierten Passwortzugang als dauerhafte Lösung belassen.

Woran Sie den Erfolg erkennen

Abgeschlossen ist die Maßnahme erst mit dokumentiertem Anbieterfix im laufenden Dienst und bestandenen Neuanmeldungen/Arbeitsabläufen. Nur ein installiertes Paket, ein Banner oder eine noch offene Altsitzung reicht nicht. War Passwortanmeldung vorübergehend deaktiviert, erst nach bestätigtem Fix und betrieblicher Freigabe über eine erneute Aktivierung entscheiden. Beibehaltene Schlüsselpflicht kann sinnvoll sein, ist aber eine eigenständige Sicherheitsentscheidung.

Grenzen und Quellen

Diese Anleitung verändert keinen Server automatisch. Sie ersetzt weder das konkrete Distributions-Advisory noch eine lokale Freigabe. Nicht jede ältere Versionszeichenfolge ist ungepatcht; nicht jedes musl-Gerät nutzt OpenSSH. Unklare Build-/Backportangaben beim Anbieter klären und betroffene Systeme bis dahin priorisiert absichern. Keine pauschale CVE-Zuordnung, Angriffserkennung oder erfolgreich durchgeführte Migration wird behauptet.

• [1] OpenSSH: 10.6p2 release, 5 November 2026
• [2] Rich Felker: Advisory for OpenSSH+musl users, 5 November 2026
• [3] OpenSSH manual: sshd(8)
• [4] Damien Miller: urgent security release, 5 November 2026