*sshole: OpenSSH-Lücke öffnet auf Alpine Linux Logins ohne gültiges Passwort

Am 5. November 2026 ist OpenSSH 10.6p2 erschienen. Die Version enthält einen Workaround für eine Lücke, die ihr Entdecker Özgün Kültekin *sshole nennt. Auf bestimmten Linux-Systemen kommt ein Angreifer per SSH auf Konten, die gar kein Passwort haben. Dafür reicht ein beliebiges, überlanges Passwort.

Die Lücke greift nur, wenn mehrere Bedingungen zusammenkommen. Debian, Ubuntu und Fedora sind in der Standardkonfiguration nicht betroffen. Wer Alpine Linux oder ein anderes System mit musl betreibt, sollte heute prüfen. Eine CVE-Nummer gab es in den Berichten, die ich gelesen habe, noch nicht. Von Angriffen berichten sie bisher nicht.

Die Ursache liegt im Zusammenspiel von OpenSSH und der C-Bibliothek musl. Bei Passwörtern über 256 Bytes schlägt die Funktion crypt() in musl fehl und gibt als Fehlerzeichen * zurück. In /etc/shadow bedeutet dasselbe Zeichen: Für dieses Konto gibt es kein Passwort. OpenSSH vergleicht beide Werte, sie stimmen überein, und der Login gilt als erfolgreich. Alpine nennt Passwörter mit 257 bis 1024 Bytes als Auslöser.

Alle diese Bedingungen müssen gleichzeitig zutreffen:

1. OpenSSH läuft auf einem Linux mit musl, zum Beispiel Alpine, Buildroot oder Yocto, oder in einem Image, das darauf aufbaut.
2. OpenSSH läuft ohne PAM. Beim Standardpaket openssh-server von Alpine ist das der Fall.
3. Passwort-Logins sind aktiv. Das ist die Voreinstellung.
4. Das Zielkonto hat * im Passwortfeld, typisch für Nutzer, die sich nur per Schlüssel oder über LDAP anmelden.
5. Mindestens ein anderes Konto hat ein echtes Passwort.

Laut Kültekin trifft das auf die offiziellen Alpine-Images für AWS und Azure zu. Der dortige Standardnutzer alpine darf per doas ohne Passwort Befehle als root ausführen. Ein Login auf dieses Konto bedeutet also volle Kontrolle über den Server.

• Systeme mit glibc, also Debian, Ubuntu und Fedora in der Standardkonfiguration
• OpenSSH mit aktivem PAM, auf Alpine also openssh-server-pam mit UsePAM yes
• Dropbear, das auf OpenWrt standardmäßig den SSH-Zugang stellt
• Konten, die mit ! statt * gesperrt sind
• Container ohne laufenden SSH-Dienst, das sind die meisten Alpine-Container

Trifft alles zu, ist es sehr ernst: Der Angreifer braucht nur einen erreichbaren SSH-Port und einen passenden Kontonamen, und die Details sind öffentlich. Für viele Systeme entschärfen die Bedingungen die Lage aber deutlich. Direkter Root-Login per Passwort bleibt gesperrt, solange PermitRootLogin auf dem Standardwert prohibit-password steht. Am stärksten gefährdet sind Alpine-Server und Embedded-Geräte mit OpenSSH, deren SSH-Port aus dem Internet erreichbar ist.

Die Befehle laufen auf dem Server selbst, als root. Sie verändern nichts.

1. musl? ldd /usr/sbin/sshd | grep musl. Ohne Treffer ist das System nach heutigem Stand nicht betroffen.
2. Passwort-Login und PAM? sshd -T | grep -Ei 'usepam|passwordauthentication'. Bei passwordauthentication no oder usepam yes greift die Lücke nicht.
3. Konten mit Stern? awk -F: '$2=="*" {print $1}' /etc/shadow. Prüfen Sie für die genannten Konten in /etc/passwd, ob sie eine Login-Shell haben.

1. Update einspielen. Auf Alpine: apk upgrade -U -a. Den Fix enthalten Alpine 3.21.10, 3.22.8, 3.23.8 und 3.24.4, für ältere Zweige gibt es gepatchte Pakete. Eine ältere OpenSSH-Versionsnummer heißt deshalb nicht automatisch, dass Ihr System offen ist. Bei Buildroot, Yocto und Geräten mit eigener Firmware brauchen Sie OpenSSH 10.6p2 oder einen Patch des Herstellers.
2. Dienst neu starten. rc-service sshd restart. Ohne Neustart läuft der alte Dienst weiter.
3. Wenn das Update warten muss: Passwort-Logins abschalten. Dazu PasswordAuthentication no in /etc/ssh/sshd_config.d/00-no-passwords.conf eintragen, mit sshd -t prüfen und den Dienst neu starten. Testen Sie vorher in einer zweiten Sitzung, dass Ihr Login per Schlüssel funktioniert, und lassen Sie die bestehende Sitzung offen. Sonst sperren Sie sich aus.

Die Lücke bestand über viele Jahre, ein Update allein beantwortet also nicht die Frage, ob jemand schon drin war. Suchen Sie in den SSH-Logs nach erfolgreichen Passwort-Logins, auf Alpine zum Beispiel mit grep 'Accepted password' /var/log/messages. Der Pfad hängt vom System ab. Ein Treffer auf einem Konto mit * ist ein Alarmzeichen, denn dieses Konto hat kein Passwort. Prüfen Sie außerdem authorized_keys, neue Benutzerkonten und Cronjobs. Lässt sich ein fremder Zugriff nicht ausschließen, behandeln Sie den Server als kompromittiert: neu aufsetzen und Schlüssel sowie Zugangsdaten austauschen.

Das ist normal, denn als Betreiber einer Website oder eines Shops müssen Sie nicht wissen, welches Linux unter Ihrer Seite läuft. Diese drei Fälle helfen bei der Einordnung:

• Normales Webhosting oder Managed Server: Um das Betriebssystem kümmert sich Ihr Anbieter. Fragen Sie im Zweifel kurz nach.
• Eigener Server, den eine Agentur oder ein Dienstleister betreut: Stellen Sie genau diese Frage: „Läuft bei uns OpenSSH auf Alpine Linux oder einem anderen musl-System, und ist der Fix für *sshole eingespielt?“
• Eigener Server, um den sich niemand kümmert, oder Sie kennen die Antwort nicht: Dann sollte das jemand für Sie prüfen.

Dabei helfe ich Ihnen gern. Ich prüfe, ob Ihre Server betroffen sind, spiele das Update ein, schalte Passwort-Logins ab und suche in den Logs nach Spuren. Sie müssen dafür nichts Technisches wissen. Schreiben Sie mir einfach, wo Ihre Website liegt oder wer sie betreut. Passwörter schicken Sie bitte nicht per E-Mail, den Zugang klären wir danach gemeinsam.

Quellen: Özgün Kültekin: *sshole · Cyber Security News: OpenSSH und Alpine-Updates. Stand: 5. November 2026.