OpenSSH *sshole: 257 Zeichen umgehen Passwortschutz – erste Angriffe gemeldet
Ein falsches Passwort, dafür absurd lang – und schon ist man als Administrator angemeldet? Was wie ein schlechter IT-Witz klingt, ist seit dem 5. November 2026 eine dokumentierte Sicherheitslücke. Sie trägt den Spitznamen *sshole und die Kennung CVE-2026-123158. Besonders bei Alpine Linux kann ein Fehler in der Passwortprüfung dazu führen, dass eigentlich passwortlose Benutzerkonten plötzlich per SSH erreichbar sind. Inzwischen gibt es sogar erste Meldungen über tatsächlich beobachtete Angriffe.
Das klingt dramatisch, betrifft aber nicht jeden Linux-Server und nicht jede SSH-Installation. Ich erkläre dir, wie ausgerechnet 257 Zeichen zum Problem werden, welche Voraussetzungen erfüllt sein müssen und was Administratoren jetzt tun sollten.
Was ist passiert – und warum macht sich das Internet darüber lustig?
Auf Social Media kursiert ein Screenshot eines Terminals: Zuerst scheitert eine SSH-Anmeldung mit dem Passwort „wrong“. Dann folgt eine endlose Kette aus Buchstaben – und plötzlich begrüßt der Server seinen neuen Benutzer. Der anschließende Befehl id zeigt sogar Administratorrechte (uid=0). Der Witz: Ein besonders langes falsches Passwort funktioniert angeblich besser als das richtige.
Der technische Kern ist echt. Unter bestimmten Bedingungen akzeptiert der betroffene SSH-Server für ausgewählte Benutzerkonten beliebige Passwörter mit 257 bis 1.024 Byte. Bei reinem ASCII-Text entspricht das 257 bis 1.024 Zeichen. Bei Umlauten oder Emojis können Zeichen- und Bytezahl auseinanderfallen. Der Screenshot ist daher eine zugespitzte Illustration, kein Beweis dafür, dass jeder beliebige Alpine-Rechner mit diesem Trick sofort Root-Zugriff erlaubt.
Die eigentliche Ursache: Ein Sternchen wird zum Sicherheitsproblem
Linux speichert Passwortinformationen und Kennzeichnungen für Benutzerkonten unter anderem in /etc/shadow. Ein einzelnes Sternchen (*) als Passworteintrag steht dort häufig für ein Konto, das kein reguläres Passwort besitzt. Zum Beispiel, weil es nur über SSH-Schlüssel genutzt werden soll. Dieses Sternchen ist kein Platzhalter für „jedes Passwort“, sondern soll Passwortanmeldungen gerade verhindern.
Auf betroffenen Systemen verwendet OpenSSH ohne PAM zur Prüfung eine Funktion namens crypt() aus der C-Bibliothek musl. Diese Funktion akzeptiert bei bestimmten Passwort-Hash-Verfahren keine Eingaben über 256 Byte und liefert dann als Fehlermarker ebenfalls * zurück. Eine ältere Logik von OpenSSH kann diesen Fehlerwert unter besonderen Voraussetzungen mit dem im Konto gespeicherten Sternchen vergleichen. Aus einem Fehler wird so scheinbar ein Treffer: * stimmt mit * überein.
Eine wichtige zusätzliche Voraussetzung: Auf dem System muss wenigstens ein anderes lokales Konto mit einem SHA-256- oder SHA-512-Passwort-Hash (Präfix $5$ oder $6$) existieren. Dessen Hash-Einstellungen werden im betreffenden Prüfpfad verwendet. Ohne diese Bedingung lässt sich der beschriebene Umweg nicht auf dieselbe Weise auslösen.
Der Sicherheitsforscher Özgün Kültekin von Wakefield hat das Problem entdeckt. Laut seiner Veröffentlichung reicht die zugrunde liegende Fehlkonstellation bis zur OpenSSH-Version 7.3p1 aus dem Jahr 2016 zurück. Es handelt sich also nicht um eine erst jetzt neu eingeschleppte Programmierpanne, sondern um eine über Jahre unbemerkte Wechselwirkung verschiedener Komponenten.
Welche Linux-Systeme sind betroffen?
Entscheidend ist die Kombination aus Betriebssystem, Bibliothek, SSH-Konfiguration und Benutzerkonten. Besonders relevant ist Alpine Linux, das wegen seines geringen Ressourcenverbrauchs häufig auf Servern, in Cloud-Umgebungen und in Containern eingesetzt wird. Auch andere Systeme oder Spezial-Builds mit musl – etwa bestimmte OpenWrt-, Buildroot- oder Yocto-Installationen – sollten geprüft werden, sofern sie tatsächlich OpenSSH in der betroffenen Konfiguration verwenden.
- Der SSH-Server nutzt eine verwundbare OpenSSH-Version ohne eingespielten Fix.
- Das System verwendet musl libc und prüft SSH-Passwörter ohne PAM.
- Passwortanmeldung ist für das betreffende Konto erlaubt (
PasswordAuthentication yes). - Mindestens ein erreichbares Konto besitzt als Passwortfeld exakt
*. - Ein anderes lokales Konto hat einen passenden SHA-256- oder SHA-512-Passwort-Hash.
Wichtig: Ein normaler Debian-, Ubuntu- oder Fedora-Server mit glibc ist von diesem konkreten Fehler nicht betroffen. Ebenso wenig der alternative SSH-Server Dropbear oder eine Installation, die ihre Passwortprüfung über PAM abwickelt. Auch ein Alpine-Docker-Container ohne laufenden SSH-Server ist allein wegen seines Basis-Images nicht aus der Ferne über SSH angreifbar.
Kann man sich damit wirklich als Root anmelden?
Nicht automatisch. OpenSSH verbietet bei den üblichen Standardeinstellungen direkte Passwortanmeldungen für root (PermitRootLogin prohibit-password). Eine direkte Root-Anmeldung wäre unter anderem dann möglich, wenn der Administrator die Einstellung ausdrücklich auf yes geändert hat und die anderen Voraussetzungen erfüllt sind.
Gefährlich sind aber auch andere Konten ohne Passwort. In bestimmten offiziellen Alpine-Cloud-Images gibt es zum Beispiel den Benutzer alpine, der bei entsprechender Konfiguration mit doas ohne erneute Passworteingabe Administratorrechte erhält. Ein zunächst „normaler“ Login kann dadurch auf diesem Weg zu Root-Rechten führen. Es wäre deshalb falsch, sich allein auf die Sperre der direkten Root-Anmeldung zu verlassen.
Update vom 6. November: Erste Angriffsversuche und Root-Zugriff auf Testsystem
Aus der theoretischen Schwachstelle ist sehr schnell ein praktisches Problem geworden. Das Sicherheitsunternehmen Previdian meldet, bereits weniger als neun Stunden nach Veröffentlichung erste Ausnutzungsversuche registriert zu haben. Nach Angaben von Firmenchef Ryan Dewhurst gelang auf einem von Previdian betriebenen Honeypot mit echtem Alpine Linux und OpenSSH sogar der Zugriff mit Root-Rechten. Anschließend wurden einfache Erkundungsbefehle ausgeführt.
In der öffentlich beschriebenen Stichprobe ist von acht Versuchen aus einer einzelnen Quelladresse auf einem Sensor die Rede. Das belegt zielgerichtete Aktivität gegen die Schwachstelle, aber noch keine flächendeckende Angriffswelle. Die Beobachtungen stammen von Previdian und wurden am 6. November unter anderem von Help Net Security veröffentlicht. Wer einen betroffenen, erreichbaren SSH-Dienst betreibt, sollte trotzdem nicht auf weitere Meldungen warten.
So schützt du deinen Server jetzt
1. Sicherheitsupdate installieren – und SSH neu starten
Der OpenSSH-Projektverantwortliche hat am 5. November 2026 OpenSSH 10.6p2 mit einer Schutzmaßnahme veröffentlicht. Alpine stellt außerdem korrigierte Pakete auch für ältere Versionszweige bereit. Deshalb bedeutet eine Versionsnummer unter 10.6p2 nicht zwingend, dass ein Alpine-System noch verwundbar ist: Entscheidend ist, ob der jeweilige Distributions-Fix bereits enthalten ist.
Für Alpine empfiehlt die offizielle Sicherheitsmeldung die Aktualisierung der Pakete und danach ausdrücklich einen Neustart des laufenden SSH-Dienstes:
apk upgrade -U -a
rc-service sshd restartDas Update allein genügt nicht, wenn der alte SSH-Prozess weiterläuft. Prüfe die zu deiner Alpine-Version passende Paketversion in der offiziellen Alpine-Sicherheitsmeldung. Bei produktiven Systemen gehören vorher ein Wartungsfenster und ein funktionierender alternativer Zugang dazu.
2. Passwortanmeldungen vorübergehend abschalten
Wenn das Update noch nicht möglich ist, schützt laut Alpine und Wakefield die vollständige Deaktivierung der SSH-Passwortanmeldung: PasswordAuthentication no. Das klappt allerdings nur sinnvoll, wenn du funktionierende SSH-Schlüssel hinterlegt hast. Halte deine bestehende Sitzung offen und teste den Schlüsselzugang in einer zweiten Verbindung, bevor du den Dienst neu startest. Sonst sperrst du dich schlimmstenfalls selbst aus.
Administratoren können zunächst die wirksame Einstellung auf dem betroffenen System prüfen:
sshd -T | grep -i passwordauthenticationBeachte dabei zusätzliche Konfigurationsdateien und mögliche Match-Abschnitte, die je nach Benutzer oder Quelladresse andere Regeln setzen können. Diese Prüfung zeigt die Einstellung des SSH-Servers – sie ist kein vollständiger Nachweis, dass alle anderen Voraussetzungen der Schwachstelle vorliegen.
3. Anmeldeprotokolle kontrollieren
Suche in SSH-Logs nach erfolgreichen Passwortanmeldungen von Konten, die eigentlich kein Passwort besitzen dürften – insbesondere alpine, rein schlüsselbasierten Dienstkonten oder gegebenenfalls root. Auf Alpine nennt die Sicherheitsmeldung beispielsweise Einträge mit Accepted password in /var/log/messages als Warnsignal. Auch nachträgliche Änderungen an Benutzerkonten, SSH-Schlüsseln und Berechtigungen verdienen Aufmerksamkeit.
Findest du entsprechende Spuren oder lässt sich ein unberechtigter Zugang nicht ausschließen, reicht ein Patch allein nicht aus. Dann solltest du den Server als möglicherweise kompromittiert behandeln, Zugänge und Zugangsdaten überprüfen und im Zweifel aus einer vertrauenswürdigen Grundlage wiederherstellen.
Müssen normale PC-Nutzer etwas unternehmen?
Wenn du Windows nutzt oder einen gewöhnlichen Linux-Desktop mit Debian, Ubuntu oder Fedora betreibst, musst du wegen dieser speziellen musl-/OpenSSH-Kombination nicht panisch werden. Besonders aufmerksam sollten dagegen Administratoren von öffentlich erreichbaren Alpine-Servern, Cloud-Instanzen, Routern, eingebetteten Linux-Geräten und ungewöhnlichen Container-Setups sein, in denen tatsächlich sshd läuft.
Der Fall erinnert außerdem daran, dass Sicherheitsupdates selbst auf unscheinbaren Diensten wichtig sind. Ein ähnliches Prinzip gilt bei NAS-Geräten: Veraltete Software wird schnell zum Einfallstor. Dazu passt mein Beitrag über Ransomware-Angriffe auf Synology-NAS und notwendige DSM-Updates.
Mein Fazit: Ein Sternchen, zehn Jahre Vorgeschichte – und eine ernste Lücke
Der Name *sshole ist witzig, die Sicherheitslücke ist es nicht. Hier hat kein besonders schlaues Passwort geholfen, sondern ein unscheinbarer Rückgabewert der Software. Ausgerechnet der Marker, der Anmeldungen verhindern sollte, konnte unter bestimmten Umständen die Anmeldung ermöglichen.
Die gute Nachricht: Der Fix ist seit dem 5. November verfügbar. Wer eine potenziell betroffene Installation betreibt, sollte jetzt die Konfiguration prüfen, das korrigierte Paket installieren und den SSH-Dienst tatsächlich neu starten. Und wer den kuriosen Screenshot weiterleitet, kann gleich die entscheidende Einschränkung dazusagen: 257 Zeichen sind kein Generalschlüssel für jedes Linux-System.
Quellen und weiterführende Informationen
- OpenSSH: Offizielle Versionshinweise zu 10.6p2 (5. November 2026)
- Alpine Linux: Sicherheitswarnung mit betroffenen Versionen und Gegenmaßnahmen
- Wakefield/Özgün Kültekin: Originalanalyse der Schwachstelle
- CVE-2026-123158: Öffentlicher Schwachstelleneintrag
- Help Net Security: Bericht über die von Previdian gemeldeten Ausnutzungsversuche (6. November 2026)
