OpenSSH 10.6p2 behebt Passwort-Umgehung unter Alpine Linux

Alpine Linux und das OpenSSH-Projekt haben am 5. November 2026 Fixes für einen Fehler veröffentlicht. Er erlaubt Angreifern, sich auf manchen Alpine-Servern ganz ohne Passwort per SSH anzumelden. Wer Alpines Standard-SSH-Server mit eingeschalteten Passwort-Logins betreibt, sollte ihn heute aktualisieren und neu starten.

Die Lücke "braucht eine Verbindung, funktioniert jedes Mal und braucht keine Wiederholungen", heißt es in der Sicherheitsmeldung von Alpine. Gemeldet hat sie Özgün Kültekin von Wakefield. Als Alpine die Meldung veröffentlichte, gab es noch keine CVE-Nummer, und keines der beiden Projekte meldet Angriffe.

So funktioniert die Passwort-Umgehung

Der Fehler sitzt dort, wo OpenSSH auf musl trifft. musl ist die kleine C-Bibliothek, die Alpine statt glibc nutzt. Er tritt nur auf, wenn sshd, der SSH-Server, ohne PAM läuft. PAM ist das gemeinsame Anmeldesystem, das die meisten Linux-Distributionen verwenden.

Ohne PAM bildet sshd mit crypt() einen Hash aus dem Passwortversuch. Das Ergebnis vergleicht es mit dem Eintrag des Kontos in /etc/shadow. Alpine erklärt, dass musls crypt() bei Schlüsseln über 256 Bytes als Fehler * zurückgibt. Ein Konto ohne Passwort speichert genau dieses *. Deshalb "passt" ein Passwort mit 257 bis 1.024 Bytes. Ein Konto ohne brauchbares Salt leiht sich das Salt eines anderen Kontos. Das Salt ist der zufällige Text, der jeden Hash einzigartig macht. Deshalb braucht ein lokales Konto einen echten $5$- oder $6$-Hash.

Die Release Notes zu OpenSSH 10.6p2 nennen das Update "einen kritischen Sicherheits-Workaround" und sehen die Ursache "außerhalb von sshd". Es folgt auf OpenSSH 10.6, das im Oktober mit Post-Quanten-Signaturen erschien.

Kültekins Analyse nennt den Fehler "sshhole" und führt ihn auf zwei musl-Commits vom August 2012 zurück. Von etwa 17.600 Test-Logins verhielt sich nur musl ohne PAM anders. Die Analyse nennt auch OpenWrt, Buildroot und Yocto. Alpine und OpenSSH erwähnen sie nicht.

Wer betroffen ist, laut Alpines Meldung

Ein Rechner ist nur angreifbar, wenn alle vier Bedingungen erfüllt sind:

• sshd stammt aus dem Paket openssh-server, das ohne PAM gebaut ist, oder aus openssh-server-pam mit UsePAM no.
• PasswordAuthentication steht auf yes, dem Standard.
• Ein Konto hat * als Passwortfeld, etwa root, ein reiner Schlüssel-Benutzer oder ein Verzeichnis-Benutzer aus sssd.
• Mindestens ein lokales Konto hat einen $5$- oder $6$-Hash.

Container, in denen kein sshd läuft, sind sicher, ebenso gesperrte Konten mit !. Die Standardeinstellung PermitRootLogin prohibit-password blockiert Passwort-Logins für root. Sie schützt aber kein Konto, das über doas root werden kann. Alpines tiny-cloud-Images von 3.18.11 bis 3.24.3 liefern genau so einen Benutzer alpine aus, mit * und doas ohne Passwort.

Getestet: fünf Alpine-Images und ihre Standards

In einem Test von Tech AI Wire am 5. November unter macOS 26.6.2 mit Docker 28.4.0 installierten die offiziellen alpine-Images openssh-server von Alpines aktuellen Mirrors.

Zweig	Image-Version (gebaut)	Installiertes Paket	Alpines reparierte Version	sshd -V
3.21	3.21.9 (21. Okt.)	9.9_p2-r1	9.9_p2-r1	OpenSSH_9.9p2
3.22	3.22.7 (21. Okt.)	10.0_p1-r11	10.0_p1-r11	OpenSSH_10.0p2
3.23	3.23.7 (21. Okt.)	10.2_p1-r1	10.2_p1-r1	OpenSSH_10.2p1
3.24	3.24.3 (21. Okt.)	10.3_p1-r2	10.3_p1-r2	OpenSSH_10.3p1
edge	3.25.0_alpha20260805 (6. Aug.)	10.6_p2-r0	10.6_p2-r0	OpenSSH_10.6p2

Vier Ergebnisse zählen:

• Neue Installationen bekommen den Fix, aber die Images sind älter. Jedes meldet eine Version unter den reparierten 3.21.10, 3.22.8, 3.23.8 und 3.24.4. Die stabilen Zweige enthalten den Fix in älteren OpenSSH-Versionen. Prüfen Sie also die Paket-Revision, nicht sshd -V.
• Die Standards erfüllen drei Bedingungen. Alle fünf laufen mit PasswordAuthentication yes und haben root:*. Unter 3.24 lehnte der Standard-sshd UsePAM yes als "Unsupported option" ab. Das separate Programm sshd.pam aus dem Paket openssh-server-pam meldete unter 3.21 und 3.24 weiterhin usepam no.
• Ein frisches Image verfehlt die vierte. Kein Konto hat einen $5$- oder $6$-Hash, bis jemand ein Passwort setzt. Ein einziger chpasswd-Aufruf schrieb einen $6$-Hash.
• Wer einen reinen Schlüssel-Benutzer zum Laufen bringt, erzeugt ein *-Konto. Unter 3.24 schrieb adduser -D appuser ein !, und sshd lehnte seinen Schlüssel ab: "User appuser not allowed because account is locked." BusyBox passwd -u ließ das ! stehen. Nach usermod -p '*' klappte der Login mit Schlüssel.

So prüfen und reparieren Sie einen Alpine-Server

Drei Befehle zeigen, wo ein Server steht. Unter 3.24 gab der Test Folgendes aus:

$ apk list -I "openssh-server*"
openssh-server-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
openssh-server-common-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
$ sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ awk -F: '$2=="*" {print $1}' /etc/shadow
root

Ist das Paket älter als die reparierte Version in der Tabelle, braucht es das Update. Alpine hat auch die nicht mehr unterstützten Zweige 3.16 bis 3.20 repariert. Führen Sie apk upgrade -U -a aus, dann rc-service sshd restart. "Das Paket zu aktualisieren ersetzt allein nicht den laufenden Daemon", warnt die Meldung.

Wenn das Update warten muss, ist Alpines Workaround eine Datei /etc/ssh/sshd_config.d/00-no-passwords.conf mit dem Inhalt PasswordAuthentication no. Prüfen Sie vorher, dass der Login per Schlüssel klappt, und lassen Sie die aktuelle Sitzung offen. Im Test stellte diese Datei sshd -T unter 3.21 und 3.24 von yes auf no um. Suchen Sie danach in /var/log/messages nach "Accepted password for" bei einem Konto ohne Passwort.

Was das für Entwickler bedeutet

Durchsuchen Sie Dockerfiles nach openssh-server. Betroffen sind Images, die sshd für CI-Runner oder Remote-Entwicklung starten. Bauen Sie sie mit docker build --pull --no-cache neu, damit kein vor dem 5. November gecachter Layer das alte Paket zurückbringt.

Machen Sie PasswordAuthentication no zum Standard auf jedem Alpine-Rechner, der nur Schlüssel braucht. Laut Alpine "schließt" ein Update oder das Abschalten der Passwort-Logins "die Lücke". Der Test zeigt, warum die Einstellung zählt: Der übliche Weg, einem reinen Schlüssel-Benutzer einen funktionierenden Login zu geben, erzeugt genau das *-Konto, das dieser Fehler braucht.

Achten Sie auf eine CVE-Nummer und auf Aussagen von OpenWrt, Buildroot und Yocto, welche ihrer Builds betroffen sind. Das OpenSSH-Team kündigt außerdem an, vorerst häufiger Releases zu veröffentlichen.