senn-techAlpine-OpenSSH-Lücke: Ein langes Passwort öffnet Konten ohne Passwort, und wir haben 36 Hosts geprüft
Alpine Linux hat am 5. November 2026 ein Sicherheitsupdate für OpenSSH veröffentlicht. Wer über SSH auf einen Alpine-Server will und ein Passwort von 257 bis 1024 Bytes schickt, kommt unter bestimmten Bedingungen ohne das richtige Passwort hinein. Wir haben am selben Tag unsere Alpine-Systeme gelesen: 36 Hosts, davon erlauben 21 noch die Passwort-Anmeldung, und genau ein Host erfüllt alle Bedingungen des Angriffs. Er ist nur aus dem internen Netz erreichbar. Alle 36 sind inzwischen gepatcht, den Angriff selbst haben wir nirgends ausprobiert.
Was die Lücke ist
Die Lücke ist eine Anmeldelücke in OpenSSH auf Alpine Linux. Die C-Bibliothek musl gibt bei Schlüsseln über 256 Bytes den Fehlerwert * zurück, statt einen Hash zu berechnen. Der SSH-Server ohne PAM vergleicht diesen Wert mit dem Passwortfeld des Kontos. Bei Konten ohne Passwort, etwa reinen Schlüsselkonten, steht dort ebenfalls *. Der Vergleich stimmt, und der Angreifer ist drin, obwohl nur Schlüssel erlaubt sein sollten.
Für die Ausnutzung gibt Alpine vier Voraussetzungen an. Der Angreifer erreicht den SSH-Port. Der Server läuft ohne PAM, also mit dem normalen Paket openssh-server, oder mit openssh-server-pam und UsePAM no. PasswordAuthentication steht auf yes, was auch der Standard ist, wenn die Zeile fehlt. Und auf dem Rechner gibt es mindestens ein Konto mit * im Passwortfeld sowie mindestens ein anderes mit einem $5$- oder $6$-Hash. Nicht betroffen ist openssh-server-pam mit UsePAM yes. Eine CVE-Nummer war am Veröffentlichungstag nicht vergeben, gemeldet hat die Lücke Özgün Kültekin von Wakefield. The Hacker News berichtet über den Fund unter dem Namen "sshole".
Der Fix und was danach zu tun ist
Der Fix steckt im Paket openssh. Je Zweig steht die Revision im Advisory: 10.2_p1-r1 für 3.23, 10.3_p1-r2 für 3.24, 10.0_p1-r11 für 3.22 und 9.9_p2-r1 für 3.21, dazu Revisionen für 3.16 bis 3.20 und edge mit 10.6_p2-r0. Die Punktversionen 3.21.10, 3.22.8, 3.23.8 und 3.24.4 enthalten ihn bereits. Wer die Pakete aktualisiert, muss danach rc-service sshd restart ausführen, denn ein Upgrade startet einen laufenden sshd nicht neu. Wer nicht sofort updaten kann, setzt PasswordAuthentication no und prüft mit sshd -T, ob die Zeile passwordauthentication no erscheint. Vorher sollte ein Schlüssel-Login in einer zweiten Sitzung bestätigt sein.
Was wir bei uns gemessen haben
Gemessen haben wir am 5. November 2026 per ssh von der Arbeitsstation, nur lesend. Je Host lasen wir die Paketrevision, die wirksame Einstellung mit sshd -T und die Kontenliste mit den Merkmalen * und $5$ oder $6$, ohne einen Hash anzuzeigen. Alle Hosts liefen auf Alpine 3.23.7 mit openssh-server 10.2_p1-r0 ohne PAM-Paket.
| Gruppe | Hosts | Passwort-Login | Konto mit * und Hash-Konto | Ergebnis |
|---|---|---|---|---|
| Firmennetz | 20 | ja | ein Host, zwei Konten mit * | ein Host erfüllt alle Bedingungen |
| Homelab | 14 | nein | nicht geprüft | nicht ausnutzbar |
| Log-Server | 1 | nein | nicht geprüft | nicht ausnutzbar |
| Sonstiger Container | 1 | ja | root hat *, kein Konto mit Hash | nicht ausnutzbar, trotzdem gepatcht |
| Summe | 36 | 21 ja, 15 nein |
Eigene Messung vom 5. November 2026, Alpine 3.23.7, openssh-server 10.2_p1-r0.
Von den 20 Firmen-Hosts mit Passwort-Login hatten 19 kein Konto mit *. Der Host, bei dem es passte, ist ein interner Dienst-Host mit zwei Dienstkonten. Beide Konten haben * im Passwortfeld, eine Login-Shell, und root hat einen $6$-Hash. Alle vier Voraussetzungen waren dort erfüllt. Der Host ist von außen nicht erreichbar, im internen Netz hätte ihn jeder Rechner mit Zugriff auf Port 22 erreicht.
Unser erster Durchlauf hatte diesen Host noch als nicht betroffen eingestuft, mit der Begründung, die beiden Konten seien vermutlich reine Schlüsselkonten. Das ist der Angriffsfall, nicht sein Gegenteil. Erst sshd -T und ein Blick in /etc/passwd haben das korrigiert.
Warum der nächtliche Update-Lauf nicht gereicht hätte
Unsere Flotte läuft über einen nächtlichen Update-Lauf mit einem Befehl je Host. Von 39 Alpine-Einträgen führten 38 apk upgrade aus, der 39. ruft ein eigenes Skript auf, das dasselbe tut. Keiner startete danach sshd neu. Die Pakete wären in der Nacht aktualisiert worden, der Server mit dem Fehler wäre bis zum nächsten Neustart im Speicher geblieben. Seit dem 5. November steht hinter dem Upgrade bei allen 39 Einträgen sshd -t && rc-service sshd restart. Die Prüfung der Konfiguration kommt zuerst, damit ein Tippfehler keinen Server vom Netz nimmt. Den neuen Schritt haben wir auf einem Host ausgeführt und danach per frischem Login geprüft.
Das Muster kennt jeder, der Container und Hosts gemischt betreibt: Ein Paketupdate ist nicht dasselbe wie ein laufender Dienst mit dem neuen Code. Wie so ein Lauf bei Ausfällen weiterarbeitet, steht in Patch-Runde: Ein Host stoppt die Flotte, den Ablauf eines Flottenchecks nach einer Lücke zeigt curl 8.23.0: Flottencheck.
Was wir nicht geprüft haben
Mehrere Einträge unserer SSH-Konfiguration führen zu Hosts, die es nicht mehr gibt oder die nicht antworten. Die Alpine-Hosts haben wir über unsere SSH-Liste gefunden, nicht über eine Bestandsliste der Virtualisierung. Ein Host ohne Eintrag dort wäre uns entgangen. Für Fremdsysteme gilt der Text von Alpine: Wer openssh-server ohne PAM und PasswordAuthentication yes hat, braucht den Fix oder den Workaround.
Wie Sie im eigenen Bestand prüfen
Drei Befehle reichen für einen Host: apk info -v openssh-server zeigt die Revision, sshd -T | grep -i passwordauthentication die wirksame Einstellung, und awk -F: '$2=="*"{print $1}' /etc/shadow listet die Konten mit *. Der Befehl gibt nur Benutzernamen aus. Zeigt sshd -T den Wert no, ist der Angriffsweg zu. Steht dort yes und gibt es ein Konto mit *, hat der Host Vorrang beim Patchen. Zu unseren Leistungen in der IT-Betreuung gehört genau diese Art von Flottenprüfung, mehr dazu unter IT-Betrieb. Das Thema gehört zu Security und Datenschutz, die Grundlagen eines Patch-Ablaufs für kleine Firmen beschreibt Patch-Management im Mittelstand.
Weiterführende Quellen
Primärquelle
- Alpine Linux, OpenSSH password authentication bypass, 5.11.2026: alpinelinux.org
Unabhängiger Bericht
- The Hacker News, 5.11.2026, Bericht über den Fund unter dem Namen sshole. Die Seite weist Abfragen von Skripten ab, deshalb steht hier kein Link.
Bin ich betroffen, wenn ich Alpine nur in Containern nutze?+
Nur, wenn im Container ein sshd läuft. Die Lücke sitzt im SSH-Server mit der C-Bibliothek musl. Ein Container ohne eigenen sshd, wie die meisten Anwendungsbilder, hat diesen Angriffsweg nicht. Prüfen lässt sich das mit apk info -e openssh-server im Container.
Reicht es, PasswordAuthentication auf no zu setzen?+
Ja, als Zwischenlösung. Alpine nennt genau diese Einstellung als Workaround, danach gibt sshd -T die Zeile passwordauthentication no aus. Der Fix liegt trotzdem im Paket openssh ab der jeweils genannten Revision, und danach muss sshd neu starten.
Warum startet ein Update den SSH-Server nicht neu?+
Ein apk upgrade ersetzt die Dateien auf der Platte, ein laufender sshd behält aber das alte Programm im Speicher. Alpine schreibt deshalb ausdrücklich, nach dem Upgrade rc-service sshd restart auszuführen. Bei uns hat der nächtliche Update-Lauf diesen Schritt bis zum 5. November gefehlt.