OpenSSH Sicherheitslücke: Alpine-Login ohne Passwort

Auf Linux-Systemen mit der C-Bibliothek musl und ohne PAM — allen voran Alpine Linux — liess sich OpenSSH bis letzte Woche mit einem überlangen Passwort in Konten einloggen, die gar kein Passwort haben. Wer einen Alpine-Server mit eingeschaltetem Passwort-Login betreibt, sollte heute nachsehen, nicht morgen.

Wir haben hier schon beschrieben, wie ihr euch sicher per SSH-Schlüssel einloggt und wie ihr mit SSH-Zertifikaten eine eigene CA aufbaut. Dieser Fall zeigt, warum der Passwort-Login in beiden Anleitungen am Ende abgeschaltet wird.

OpenSSH Sicherheitslücke: was am 5. November passiert ist

Am 5. November 2026 erschien Portable OpenSSH 10.6p2. Die Release Notes nennen den Grund im ersten Satz: Die Fassung enthalte "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." Im Sicherheitsabschnitt heisst es, sshd vermeide nun eine Umgehung der Passwortprüfung, die "affects some Linux systems when built and run with PAM support disabled." Gemeldet hat das Problem Özgün Kültekin von Wakefield.

Wie ernst die Entwickler die Sache nehmen, zeigt eine zweite Mail von Damien Miller, zehn Minuten nach der Ankündigung, mit dem Betreff "urgent security release: 10.6p2". Wer ein Linux mit musl ohne PAM betreibe, solle "stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY." Laut derselben Mail hat das Projekt erst am Vortag davon erfahren. Zwischen Meldung und Release lag also rund ein Tag, Alpine lieferte am selben 5. November korrigierte Pakete aus.

Eine CVE-Nummer gab es bis zum Redaktionsschluss nicht. Alpine schreibt in seinem Sicherheitshinweis ausdrücklich, dass zum Zeitpunkt der Veröffentlichung keine vergeben war. Wer in seinem Schwachstellen-Scanner nach einer Nummer sucht, findet also nichts — und sollte daraus keine Entwarnung ableiten.

Wer betroffen ist: musl, kein PAM, Passwort-Login an

Drei Bedingungen müssen zusammenkommen, und genau das macht die Lücke so ungleich verteilt. Erstens ein Linux-System, das musl statt glibc als C-Bibliothek verwendet. Zweitens ein sshd, der Passwörter selbst prüft statt über PAM. Drittens eingeschaltete Passwort-Anmeldung, also PasswordAuthentication yes — was bei OpenSSH die Vorgabe ist.

Miller grenzt das in seiner Mail klar ab: Die Schwachstelle existiere nicht auf Systemen ausserhalb von Linux, nicht auf Linux mit glibc und nicht auf Linux-Systemen, die PAM für die Passwortprüfung verwenden. Debian, Ubuntu, Fedora, Mint und Arch sind damit nicht betroffen, weil sie glibc verwenden.

Bei Alpine dagegen trifft es den Normalfall. Laut dem Alpine-Hinweis ist das Standardpaket openssh-server ohne PAM gebaut; es gibt daneben ein Paket openssh-server-pam, das nur dann betroffen ist, wenn darin UsePAM no gesetzt ist. Alpine ist beliebt für kleine Server, Router-Eigenbauten, virtuelle Maschinen und als Basis von Container-Images. Ein Container ohne sshd ist nicht betroffen; wer aber in ein Alpine-Image einen SSH-Server eingebaut hat, etwa für einen Deploy- oder Backup-Zugang, muss das Image neu bauen. Wie Images und Container zusammenhängen, steht in unseren Docker-Grundlagen.

Die Nachricht für alle anderen ist auch eine: Die übliche Faustregel "kleine Distribution, kleine Angriffsfläche" stimmt meistens. Diesmal war die kleine Distribution genau die Angriffsfläche.

Wie ein Stern zum Generalschlüssel wird

Der Mechanismus ist banal, und das ist das Unangenehme daran. Ohne PAM prüft sshd ein Passwort, indem es den Eingabewert mit der Funktion crypt() hasht und das Ergebnis mit dem gespeicherten Eintrag aus /etc/shadow vergleicht. Stimmen beide überein, ist die Tür offen.

Konten ohne Passwort tragen in /etc/shadow an dieser Stelle einen einzelnen Stern *. Weil daraus kein Salt zu gewinnen ist, leiht sich sshd laut der Analyse von musl-Entwickler Rich Felker den gespeicherten Hash eines anderen Kontos als Salt. Ist dieses andere Konto mit SHA-256 oder SHA-512 gehasht (erkennbar an $5$ oder $6$), verlangen diese Verfahren, dass überlange Passwörter als Fehler behandelt werden.

Und hier kommt musl ins Spiel. Der Alpine-Hinweis beschreibt es so: "musl's crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password." Die Fehlermeldung der Funktion ist also identisch mit dem Eintrag, gegen den verglichen wird. sshd vergleicht Stern mit Stern und meldet: passt.

Felker fasst die Voraussetzungen genauer als Alpine: Das Zielkonto muss * als Passwortfeld haben, es muss mindestens ein anderes Konto mit gesetztem Passwort geben, und das erste solche Konto in der Reihenfolge von /etc/passwd muss SHA-256 oder SHA-512 verwenden. Alpine nennt als Passwortlänge 257 bis 1024 Bytes. Mehr als ein langes Passwort braucht der Angreifer nicht — kein Exploit-Code, keine Speicherkorruption, nur Geduld beim Tippen oder ein Skript.

Welche Konten tatsächlich offenstehen

Gesperrte Konten mit ! im Passwortfeld sind laut Alpine nicht betroffen, nur solche mit *. Alpine zählt dazu vier Gruppen auf:

• root, der bei Alpine seit etwa Version 3.16 mit * ausgeliefert wird. Erreichbar ist er über diese Lücke nur, wenn PermitRootLogin yes gesetzt ist; die Vorgabe prohibit-password verhindert das.
• Benutzer, die ohne Passwort angelegt wurden, weil sie sich ohnehin nur per Schlüssel anmelden sollten — ausgerechnet die vorbildlich eingerichteten.
• Benutzer aus einem Verzeichnisdienst, die über musl-nscd kommen und keinen Eintrag in /etc/shadow haben.
• Der Benutzer alpine in den tiny-cloud-Images für Cloud-Instanzen.

Root bleibt trotzdem nicht sicher, nur weil er direkt nicht erreichbar ist. Alpine weist darauf hin, dass jedes Konto zählt, das sich anmelden und danach etwa über doas root werden kann. Die bittere Pointe für alle, die alles richtig machen wollten: Wer einen Dienstbenutzer bewusst ohne Passwort anlegt und nur einen Schlüssel hinterlegt, hat genau das Konto gebaut, das hier aufgeht — solange die Passwort-Anmeldung daneben eingeschaltet bleibt.

Wessen Fehler? Beide zeigen aufeinander

Die Release Notes von OpenSSH sind in einem Punkt bemerkenswert deutlich: "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." Die Ursache liege also ausserhalb, behoben wird trotzdem im eigenen Code. Der Fix in openssh-portable lässt eine Anmeldung jetzt scheitern, wenn der gespeicherte Hash des Zielkontos kürzer als vier Zeichen ist. Ein einzelner Stern kommt damit nicht mehr bis zum Vergleich.

musl sieht es spiegelbildlich. Rich Felker schrieb in seinem Hinweis an die musl-Liste, es handle sich "not a bug in musl just an erroneous use by the caller", kündigte aber an, das Verhalten werde sich voraussichtlich ändern. Einen Tag später folgte ein Patch zur Diskussion: crypt() soll im Fehlerfall *0 statt * zurückgeben, damit der Rückgabewert nicht mehr mit dem üblichen Eintrag in /etc/shadow übereinstimmen kann. Ob und wann der Patch in eine musl-Version kommt, ist offen.

Technisch haben beide recht, und genau darin liegt das Problem. Zwei für sich korrekte Komponenten ergeben zusammen ein offenes Scheunentor, weil die eine einen Fehlerwert gewählt hat, der zufällig wie ein gültiger Wert aussieht, und die andere nicht damit gerechnet hat. Der Entdecker formuliert es auf seiner eigenen Projektseite zum Fehler zugespitzt: OpenSSH werde auf OpenBSD und glibc getestet, sshd auf musl dagegen nicht. Das ist seine Darstellung, keine der beiden Projekte — aber sie beschreibt den toten Winkel ziemlich genau.

Nebenbei kündigt OpenSSH in den Release Notes an, künftig häufiger Releases zu veröffentlichen, statt Korrekturen zu sammeln, weil Fehlerberichte schneller eintreffen und schneller wiederentdeckt werden. Das klingt nach einer Fussnote, ist für Admins aber die eigentlich wichtige Nachricht: Wer SSH-Updates bisher nach Gefühl einspielt, wird öfter danebenliegen.

Was ihr jetzt tun solltet

Die folgenden Befehle gelten für Alpine Linux mit OpenRC. Führt sie als root aus. Prüft zuerst, ob euer sshd ohne PAM läuft und Passwörter annimmt:

sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin)'

Steht dort passwordauthentication yes und usepam no (oder fehlt die PAM-Zeile, weil das Paket ohne PAM gebaut ist), ist das System angreifbar, bis das Update läuft. Als Erstes schaltet ihr die Passwort-Anmeldung ab. Das ist der von OpenSSH, musl und Alpine gleichermassen genannte Notbehelf:

echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/10-no-password.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Die letzte Zeile muss passwordauthentication no ausgeben. Lasst vorher eine zweite SSH-Sitzung offen und prüft, dass euer Schlüssel-Login funktioniert, sonst sperrt ihr euch selbst aus. Wird das Verzeichnis sshd_config.d bei euch nicht eingebunden, gehört die Zeile direkt in /etc/ssh/sshd_config.

Danach das Update einspielen und den Dienst neu starten. Alpine betont, dass das Aktualisieren des Pakets allein den laufenden Daemon nicht ersetzt:

apk upgrade -U -a
rc-service sshd restart
apk info -v openssh-server

Korrigiert sind laut Alpine unter anderem 10.6_p2-r0 in edge, 10.3_p1-r2 in 3.24, 10.2_p1-r1 in 3.23 und 10.0_p1-r11 in 3.22. Die stabilen Zweige tragen einen eigenen Patch für dasselbe Problem, nicht die Version 10.6p2. Für 3.21, dessen Support am 1. November 2026 endete, gibt es mit 9.9_p2-r1 noch eine Korrektur; das ist ein guter Anlass, auf einen unterstützten Zweig zu wechseln.

Schliesslich lohnt der Blick, welche Konten einen Stern tragen und ob sich jemand damit angemeldet hat. Alpine nennt als Spur Zeilen mit Accepted password for zu einem Konto ohne Passwort:

awk -F: '$2=="*" {print $1}' /etc/shadow
grep 'Accepted password for' /var/log/messages

Findet ihr eine solche Anmeldung bei einem Konto aus der ersten Liste, behandelt den Rechner als kompromittiert: nicht weiterbetreiben, Daten sichern, neu aufsetzen. Wer Server mit vielen Anmeldeversuchen aus dem Netz betreibt, sollte zusätzlich über eine Absicherung wie CrowdSec nachdenken. Sie hätte diese Lücke nicht geschlossen, macht ausdauerndes Probieren aber teurer. Und wer bei Updates grundsätzlich unsicher ist, findet in Wie update ich mein Linux-System richtig die Grundlagen.

Langfristig ist die Lehre dieselbe wie immer: Passwort-Login auf einem Server aus, Schlüssel an — am besten mit Hardware-Schlüssel, wie in Server SSH Zugang mit YubiKey absichern beschrieben. Ein Server, der keine Passwörter annimmt, kann auch keine falsch prüfen.

Fazit: Der Passwort-Login war die Lücke, musl nur der Auslöser

Ihr könntet diesen Fall als Kuriosität abheften: ein Stern, der zweierlei bedeutet, und ein Passwort, das zu lang ist, um falsch zu sein. Das wäre zu bequem. Die Lücke traf ausgerechnet Konten, die nie ein Passwort haben sollten, auf einer Distribution, die gerade für ihre Schlankheit gewählt wird — und sie war mit einem einzigen Konfigurationseintrag vollständig abzuwenden, der in jeder ordentlichen SSH-Anleitung ohnehin steht.

Wer PasswordAuthentication no gesetzt hatte, war nie betroffen. Wer es nicht hatte, hat sich bisher auf zwei Komponenten verlassen, die sich gegenseitig nicht kannten. OpenSSH und Alpine haben innerhalb eines Tages geliefert, das ist vorbildlich. Die Konsequenz für den eigenen Server ist trotzdem nicht "Update einspielen und vergessen", sondern: Passwörter haben an der SSH-Tür nichts verloren. Sie sind dort nur eine weitere Stelle, an der zwei Programme sich missverstehen können.

Quellen und weiterführende Links

• OpenSSH 10.6p2 Release Notes vom 05.11.2026 — Sicherheitsabschnitt, Reporter, weitere Änderungen.
• Damien Miller: Announce: Portable OpenSSH 10.6p2 released — Ankündigung auf openssh-unix-dev.
• Damien Miller: urgent security release: 10.6p2 — Abgrenzung der betroffenen Systeme und Sofortmassnahme.
• openssh-portable, Commit 4353fdc — der Fix in sshd.
• Alpine Linux: Security advisory: openssh-server password authentication bypass — Mechanismus, betroffene Konten, korrigierte Paketversionen je Zweig.
• Rich Felker: Advisory for OpenSSH+musl users — Stellungnahme von musl.
• Rich Felker: OpenSSH password auth bypass analysis — die genaueste Beschreibung der Voraussetzungen.
• Rich Felker: [PATCH] [RFC] Harden against misuse of crypt — vorgeschlagene Änderung in musl.
• oss-security: sshole — Zusammenfassung von Jan Schaumann.
• sshhole.com — Darstellung des Entdeckers.
• Auf yourdevice.ch: Sicher per SSH einloggen, SSH-Zertifikate: eine eigene SSH-CA einrichten, Server SSH Zugang mit YubiKey absichern und Mit CrowdSec Server absichern.