OpenSSH-Lücke: Ein Sternchen öffnet Alpine-Server

Von /

Seit heute kursiert eine OpenSSH-Lücke, die so absurd klingt, dass man sie zweimal lesen muss: Auf bestimmten Linux-Systemen nimmt der SSH-Server für Konten, die überhaupt kein Passwort haben, jedes Passwort an, sofern es nur lang genug ist. Zwischen 257 und 1024 Zeichen, egal welche. Der Entdecker nennt sie *sshole, nach dem Sternchen, um das sich alles dreht. Das OpenSSH-Projekt hat am 5. November 2026 mit OpenSSH 10.6p2 reagiert, Alpine Linux zeitgleich ein Sicherheitshinweis mit Paketupdates veröffentlicht.

Die Meldung, die gerade die Runde macht, lautet sinngemäß: falsches Kennwort, trotzdem root. Das stimmt, aber nur unter Bedingungen. Wer Debian, Ubuntu, RHEL oder Windows-Server mit OpenSSH betreibt, ist nicht betroffen. Wer Alpine Linux, Embedded-Systeme auf Buildroot- oder Yocto-Basis oder OpenWrt mit nachinstalliertem OpenSSH im Netz hat, sollte heute noch nachsehen. Dieser Artikel erklärt, wie der Fehler entsteht, wer betroffen ist, wie Sie Ihre Systeme prüfen und was Sie tun sollten, falls ein Update nicht sofort möglich ist.

Was hinter der OpenSSH-Sicherheitslücke steckt

Gemeldet hat den Fehler Özgün Kültekin von der Firma Wakefield; so steht es in den Release Notes zu 10.6p2. Seine ausführliche Analyse liegt auf sshhole.com. Bemerkenswert ist die Einordnung durch das OpenSSH-Team: Die Ursache liege außerhalb von sshd, ausnutzbar sei der Fehler aber über sshd, und dort lasse er sich auch abfangen. Genau das tut 10.6p2.

Das klingt nach Schuldzuweisung, ist aber technisch korrekt. *sshole ist kein klassischer Programmierfehler, sondern das Zusammentreffen von drei Entscheidungen, die jede für sich vernünftig waren. Keine davon ist neu. Neu ist nur, dass jemand sie zusammen betrachtet hat.

Zeitleiste zur OpenSSH-Lücke *sshole: August 2012 ändert musl das Fehlerverhalten von crypt() und führt ein 256-Byte-Limit ein, 2016 folgt der OpenSSH-Timing-Fix zu CVE-2016-6210, 2022 setzt Alpine 3.16 das root-Passwortfeld auf „*“, am 5. November 2026 erscheint der Fix

Wie der Passwort-Bypass auf musl-Systemen funktioniert

Unter Unix steht ein * im Passwortfeld von /etc/shadow seit Jahrzehnten für „mit diesem Konto ist keine Passwortanmeldung möglich“. Ein Sternchen ist kein gültiger Hash, also kann kein Passwort darauf passen. So jedenfalls die Annahme. Alpine nutzt diese Markierung für root (in Basis-Images seit Version 3.16), für Konten, die sich nur per Schlüssel anmelden sollen, für Benutzer aus Verzeichnisdiensten und für den Standardbenutzer alpine der offiziellen Cloud-Images.

Der erste Baustein liegt in musl, der schlanken C-Bibliothek, auf der Alpine und viele Embedded-Systeme aufbauen. Laut der Zeitleiste auf sshhole.com gibt die Funktion crypt() dort seit August 2012 bei einem Fehler nicht NULL zurück, sondern eine Zeichenkette wie *. Im selben Monat kamen SHA-256- und SHA-512-crypt hinzu, das musl-Git-Log datiert den Commit auf den 29. August 2012. Als Schutz gegen Überlastung lehnt diese Implementierung Passwörter über 256 Byte ab. Ergebnis eines zu langen Passworts also: *.

Der zweite Baustein stammt aus OpenSSH selbst. 2016 wurde mit CVE-2016-6210 bekannt, dass sich gültige Benutzernamen über Antwortzeiten erraten ließen. Die Gegenmaßnahme: Hat ein Konto keinen brauchbaren Hash, hasht sshd das eingegebene Passwort trotzdem, mit dem Salt eines anderen, echten Kontos. So dauert jede Prüfung ungefähr gleich lang. Das betrifft nur Systeme, auf denen sshd Passwörter selbst prüft, also ohne PAM.

Zusammengesetzt sieht das so aus:

Ablauf des Angriffs in vier Schritten: Login-Versuch auf ein Konto mit „*“ und einem Passwort von 257 bis 1024 Zeichen, sshd ohne PAM leiht sich den Salt eines anderen Kontos und ruft crypt() auf, musl liefert wegen Überlänge „*“ zurück, der Vergleich „*“ gegen „*“ gelingt

Der Angreifer schickt ein Passwort mit mehr als 256 Byte. sshd sieht beim Zielkonto nur *, leiht sich einen Salt, ruft crypt() auf. musl scheitert an der Länge und liefert *. sshd vergleicht * mit *, findet Gleichheit und lässt den Angreifer herein. Laut Alpine reicht dafür eine einzige Verbindung, ohne Raten und ohne Wiederholungen. Im Log erscheint ein ganz normales „Accepted password“.

Der dritte Baustein ist die Alpine-Entscheidung von 2022, root nicht mehr mit !, sondern mit * zu sperren. Der Hintergrund laut sshhole.com: Nach CVE-2019-5021, als Alpine-Docker-Images ein leeres root-Passwort hatten, sperrte Alpine root mit !. Das blockierte ohne PAM aber auch Schlüssel-Logins. Also wechselte man auf *. Ein mit ! gesperrtes Konto ist laut Alpine übrigens nicht betroffen.

Ist root wirklich direkt angreifbar?

Hier lohnt sich ein genauer Blick, denn die Schlagzeile „falsches Passwort, trotzdem root“ greift zu kurz. OpenSSH erlaubt root standardmäßig gar keine Passwortanmeldung. Der Standardwert von PermitRootLogin ist laut Handbuchseite sshd_config prohibit-password: root darf sich nur per Schlüssel anmelden. Wer diesen Wert nie angefasst hat, ist beim root-Konto selbst geschützt.

Der realistischere Weg führt über einen Umweg. Auf den offiziellen Alpine-Cloud-Images (tiny-cloud, als qcow2, VHD und AMI) hat der Benutzer alpine ein * als Passwort und darf per doas ohne Passwort root werden. Wer als alpine hereinkommt, ist eine Befehlszeile später root. Alpine nennt als betroffen die Images von 3.18.11 bis 3.24.3. Angreifbar werden sie aber erst, wenn auf dem System irgendein Konto einen echten $5$– oder $6$-Hash hat, etwa weil jemand ein Konsolenpasswort gesetzt oder hashed_passwd in den User-Data hinterlegt hat. Images mit cloud-init schalten Passwort-Logins ab und sind deshalb nicht betroffen.

Und natürlich jedes Konto, das jemand als „nur mit Schlüssel“ angelegt hat und das Sudo- oder doas-Rechte besitzt. Das ist auf vielen Servern der eigentliche Admin-Zugang.

Welche Systeme betroffen sind

Alpine fasst die Voraussetzungen in seinem Hinweis klar zusammen. Betroffen ist ein System nur, wenn alles davon zutrifft:

  • sshd läuft auf musl libc und prüft Passwörter ohne PAM (bei Alpine das Paket openssh-server, oder openssh-server-pam mit UsePAM no)
  • PasswordAuthentication yes ist aktiv, was der Standard von OpenSSH ist
  • mindestens ein Konto hat genau * im Passwortfeld
  • mindestens ein anderes lokales Konto hat einen $5$– oder $6$-Hash, dessen Salt sshd sich borgen kann

Alpine nennt die Releases 3.16 bis 3.24 sowie edge. Für 3.16 bis 3.20, die eigentlich nicht mehr regulär gepflegt werden, gibt es trotzdem Fixes. Nach sshhole.com gehören außerdem Systeme auf Basis von Buildroot und Yocto dazu, OpenWrt-Geräte mit installiertem OpenSSH und viele Docker-Images auf Alpine-Basis. Bei Containern gilt: Ohne laufenden sshd im Container gibt es auch keine Angriffsfläche.

Nicht betroffen sind nach übereinstimmender Darstellung von Alpine, sshhole.com und Privacy Affairs glibc-Systeme wie Debian, Ubuntu und Fedora, Systeme mit UsePAM yes, OpenBSD sowie Dropbear, der kleine SSH-Server, den viele Router und Embedded-Geräte stattdessen verwenden.

Eine CVE-Nummer gibt es bisher nicht. Berichte über Ausnutzung in freier Wildbahn haben weder Alpine noch OpenSSH veröffentlicht. Bei einem Fehler, den man mit einer einzigen Verbindung und ohne jede Kryptografie auslöst, würde ich darauf allerdings nicht lange vertrauen.

Nicht zu verwechseln: SplitSSHell aus dem April

Wer sich an eine andere OpenSSH-Lücke mit root-Zugriff aus diesem Jahr erinnert, liegt nicht falsch, meint aber etwas anderes. Im April hat Cyera SplitSSHell (CVE-2026-35414) beschrieben: Ein Komma im Principal eines SSH-Zertifikats, etwa deploy,root, konnte bei bestimmten authorized_keys-Konfigurationen zu einer root-Anmeldung führen. Voraussetzung war ein gültiges Zertifikat einer vertrauenswürdigen CA. Behoben wurde das in OpenSSH 10.3 vom 2. April 2026. Mit *sshole hat das nichts zu tun, es betraf auch glibc-Systeme und keine Passwortprüfung.

OpenSSH 10.6p2 und die Alpine-Updates

Das OpenSSH-Projekt hat 10.6p2 am 5. November 2026 veröffentlicht. Die Release Notes enthalten außerdem einen Satz, der über diesen Fall hinausweist: Das Team bekomme viele Sicherheitsmeldungen, teils von KI-Werkzeugen, und weil KI-gefundene Fehler manchmal unabhängig von mehreren Leuten entdeckt würden, erscheinen Releases vorerst häufiger statt gesammelt. Nach Berichten von Tech Insider hat OpenSSH-Entwickler Damien Miller Betreiber betroffener Systeme zudem aufgefordert, Passwort-Logins „IMMEDIATELY“ abzuschalten. Seinen Originalbeitrag konnte ich nicht abrufen.

Alpine liefert gepatchte Pakete für alle genannten Zweige. Die Stable-Pakete tragen einen eigenen Patch, nicht zwingend die Version 10.6p2. Mindestens diese Versionen sollten installiert sein:

Alpine-Zweigopenssh (gepatcht ab)
edge10.6_p2-r0
3.2410.3_p1-r2
3.2310.2_p1-r1
3.2210.0_p1-r11
3.219.9_p2-r1
3.209.7_p1-r6
3.199.6_p1-r3
3.189.3_p2-r4
3.179.1_p1-r7
3.169.0_p1-r6

Die Point-Releases 3.21.10, 3.22.8, 3.23.8 und 3.24.4 enthalten den Fix bereits, ebenso die Cloud-Images ab diesen Versionen.

So prüfen und schließen Sie die Lücke

Zuerst die installierte Version:

apk info -v | grep openssh

Liegt sie unter dem Wert aus der Tabelle, aktualisieren. Wichtig, und Alpine betont das ausdrücklich: Das Paket-Update allein reicht nicht, der laufende sshd muss neu gestartet werden.

apk upgrade -U -a
rc-service sshd restart

Ob Ihr System überhaupt die Voraussetzungen erfüllt, sehen Sie in /etc/shadow. Diese beiden Befehle zeigen Konten mit genau * und Konten mit $5$– oder $6$-Hash:

awk -F: '$2=="*" {print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

Liefern beide etwas, und ist Passwort-Login aktiv, war das System angreifbar.

Wenn das Update nicht sofort geht

Dann Passwort-Logins abschalten. Alpine empfiehlt eine Drop-in-Datei unter /etc/ssh/sshd_config.d/ mit PasswordAuthentication no, danach Syntax prüfen und neu starten. Bevor Sie das tun: Schlüssel-Login testen und die bestehende Sitzung offen lassen. Sonst sperren Sie sich selbst aus, und das ist bei einer VM ohne Konsolenzugang ein langer Nachmittag.

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

Die letzte Zeile muss passwordauthentication no ausgeben. Steht dort etwas anderes, überschreibt ein Match-Block oder eine andere Datei die Einstellung. Als Notlösung bleibt, sshd zu stoppen oder Port 22 per Firewall oder Security Group auf bekannte Adressen zu beschränken.

Wurde das System schon angegriffen?

Alpine rät, in /var/log/messages nach Zeilen mit „Accepted password for“ zu suchen und jeden gefundenen Kontonamen gegen /etc/shadow zu halten:

grep "Accepted password for" /var/log/messages

Taucht dort ein Konto auf, das nur * im Passwortfeld hat, gibt es keine harmlose Erklärung. Dieses Konto konnte sich nie per Passwort anmelden. Zusätzlich empfiehlt Alpine, doas-Aufrufe, neu angelegte Benutzer, veränderte Dateien und authorized_keys zu prüfen. Lässt sich ein Login nicht ausschließen, ist das System als kompromittiert zu behandeln: neu aufsetzen, Schlüssel und Zugangsdaten tauschen, nicht „aufräumen“.

Was das für Kommunen und kleine IT-Abteilungen heißt

Die meisten Server in Verwaltungen laufen auf Windows oder auf glibc-Distributionen. Das ist die gute Nachricht. Die schlechte: musl steckt oft dort, wo man nicht hinschaut. In Appliances, Netzwerkgeräten, Kamera- und Gebäudetechnik, in Containern, die ein Dienstleister mitgebracht hat. Ob darin OpenSSH oder Dropbear läuft und ob PAM aktiv ist, steht selten auf dem Datenblatt.

Ich würde deshalb heute drei Dinge tun. Erstens im Inventar nach Alpine-, Buildroot- und Yocto-Systemen suchen, ein schneller Blick per Portscan auf offene SSH-Ports mit OpenSSH-Banner hilft. Zweitens bei Dienstleistern und Herstellern schriftlich nachfragen, ob ihre Geräte musl mit OpenSSH ohne PAM verwenden, und um eine Antwort mit Datum bitten. Drittens grundsätzlich prüfen, warum auf einem nur per Schlüssel administrierten System überhaupt PasswordAuthentication yes steht. Diese eine Zeile hätte *sshole auf jedem betroffenen System entschärft, schon vor zehn Jahren.

Fazit

*sshole ist kein Fehler, den jemand fahrlässig eingebaut hat. Eine C-Bibliothek meldet Fehler mit *, ein SSH-Server hasht aus Timing-Gründen auch dort, wo es nichts zu prüfen gibt, eine Distribution sperrt Konten mit *. Jede Entscheidung war begründet. Zusammen öffnen sie die Tür für jedes Passwort mit mehr als 256 Zeichen. Root ist dabei meist nicht das Ziel, sondern der Schritt danach, über doas oder sudo.

Was mich daran am meisten beschäftigt: Diese Lücke war rund zehn Jahre lang für jeden sichtbar, der den Code von musl und OpenSSH nebeneinander gelesen hätte. Wenn KI-Werkzeuge solche Kombinationen jetzt systematisch finden, kommen in den nächsten Monaten mehr davon.

Spielen Sie heute die Alpine-Updates ein und starten Sie sshd neu. Wo das nicht geht, schalten Sie PasswordAuthentication ab. Und wo Sie nicht wissen, ob ein Gerät betroffen ist: fragen Sie den Hersteller, bevor es jemand anderes herausfindet.

Quellen:

Nach oben scrollen