Ing. Calogero Bono
Am 5. November 2026 erschien OpenSSH 10.6p2, das einen Fehler namens «*sshole» behebt. Er betrifft SSH-Server unter Linux, die die musl-Bibliothek verwenden, etwa Alpine Linux, und bei denen PAM deaktiviert ist. Wer den SSH-Port erreicht, kann sich ohne Passwort in ein Konto einloggen, indem er ein sehr langes Passwort sendet. Das ist wichtig, weil schon eine einzige Verbindung genügt und weil die offiziellen Alpine-Cloud-Images Root-Zugang gewähren können.
Ein paar Begriffe, bevor wir zu den Fakten kommen. musl ist eine alternative C-Bibliothek zu glibc, verwendet von Alpine, OpenWrt, Buildroot und Yocto. crypt() ist die Funktion, die ein Passwort in seinen Hash umwandelt. PAM ist das modulare Authentifizierungssystem von Linux. /etc/shadow ist die Datei, in der die Passwort-Hashes gespeichert sind. doas ist ein Werkzeug, ähnlich wie sudo, um Root-Rechte zu erlangen.
Wie funktioniert der *sshole-Fehler?
Ein Linux-Konto ohne Passwort hat im Feld /etc/shadow einen Stern anstelle des Hashes. Kein Passwort sollte es öffnen. Laut BleepingComputer hat eine Änderung an OpenSSH aus dem Jahr 2016, die die CVE-2016-6210 zur Benutzeraufzählung beheben sollte, dazu geführt, dass auch für diese Konten ein Hash berechnet wird.
Hier kommt musl ins Spiel. Wie der Hinweis von Alpine erklärt, gibt die crypt()-Funktion von musl einen Stern als Fehlersignal zurück, wenn der Schlüssel mehr als 256 Byte lang ist. Dieser Stern stimmt mit dem im Konto gespeicherten überein, und der Vergleich gelingt. Der Forscher Özgün Kültekin sagt, dass der Fehler seit 2016 besteht.
Wer ist wirklich gefährdet?
Mehrere Bedingungen müssen zusammentreffen. Laut Alpine ist das Paket openssh-server ohne PAM kompiliert, oder es wird openssh-server-pam mit UsePAM no verwendet. PasswordAuthentication muss aktiv sein, wie es der Standard vorsieht. Nötig ist ein Konto mit * und mindestens ein weiteres mit einem Hash $5$ oder $6$. Schon ein einziger Benutzer mit Passwort macht alle anderen Konten erreichbar.
Alpine hat die Versionen von 3.21 bis 3.24 sowie edge und die älteren 3.16 bis 3.20 geprüft. Nicht betroffen sind Container ohne sshd, Systeme mit PasswordAuthentication no und Systeme mit aktivem PAM. Debian, Ubuntu und Fedora, die glibc verwenden, sind laut BleepingComputer nicht verwundbar.
Warum sind die Cloud-Images von Alpine ein Problem?
Die offiziellen tiny-cloud-Images von der Version 3.18.11 bis 3.24.3 enthalten einen Benutzer alpine mit dem Passwort * und doas ohne Passwortabfrage. Laut Alpine sind sie beim ersten Start sicher. Ausnutzbar werden sie, sobald ein Hash $6$ auftaucht, etwa wenn ein Administrator ein Konsolenpasswort setzt oder user-data einen Benutzer mit hashed_passwd anlegt.
Dann erhält der Angreifer eine Shell als alpine und wird mit doas zu root. Images, die mit cloud-init konfiguriert sind und PasswordAuthentication no setzen, sind nicht betroffen. Für root schützt der Standardwert PermitRootLogin prohibit-password nur den direkten Zugang.
Wie behebst du den Fehler und prüfst auf einen Angriff?
Die Korrektur steckt in OpenSSH 10.6p2. Auf Alpine verwendest du apk upgrade -U -a und startest danach sshd neu, weil das Update den laufenden Dienst nicht ersetzt. Alpine hat korrigierte Pakete bis zur Version 3.16 veröffentlicht, auch für nicht mehr unterstützte Releases.
Wenn du nicht sofort aktualisieren kannst, setze PasswordAuthentication no und starte sshd neu, nachdem du sichergestellt hast, dass der Login mit Schlüssel funktioniert. Um Spuren zu finden, suche in /var/log/messages nach Einträgen «Accepted password» für Konten ohne Passwort. Alpine ergänzt, dass die Maschine als kompromittiert gelten sollte, wenn ein Zugriff nicht ausgeschlossen werden kann. Zu den Rechten der Konten passt auch der Leitfaden zu Linux-Berechtigungen.
Grenzen, die du kennen solltest
Alpine meldet, dass zum Zeitpunkt der Veröffentlichung noch keine CVE vergeben war. OpenSSH schreibt, dass die Ursache außerhalb von sshd liegt, der Fehler aber über sshd ausnutzbar ist und dort abgefangen wird. Es gibt keine Daten zu laufenden realen Angriffen. Die Angaben zu den 17.600 Tests mit KI-Agenten stammen vom Forscher, berichtet von BleepingComputer, und sind nicht unabhängig überprüft.
Was sich für alle ändert, die digital arbeiten
Wenn du Alpine-Server, OpenWrt-Router oder eingebettete Systeme mit Yocto und Buildroot betreibst, prüfe, ob sshd Passwörter erlaubt und ob es Konten mit * gibt. Viele setzen Alpine in Containern ohne sshd ein, dort ist nichts betroffen. Wer Cloud-Maschinen mit den tiny-cloud-Images betreibt, muss jede bereits laufende Instanz prüfen. Ein verwalteter Server mit regelmäßigen Updates verringert diese Art von Risiko, dazu gibt es die Seite zu Hosting und verwalteten Servern. Lohnend ist auch der verwandte Fall der KI-generierten Exploits, über den wir in diesem Artikel berichtet haben.
Unsere Einschätzung
Der Fall zeigt, wie zerbrechlich die Grenze zwischen Komponenten ist, die einander vertrauen. OpenSSH hat 2016 eine berechtigte Abwehrmaßnahme ergänzt, musl hat einen üblichen Fehlerwert gewählt, und zusammen haben sie zehn Jahre lang eine Tür offen gelassen. Auffällig ist auch, dass der Fehler mit KI-Agenten gefunden wurde. OpenSSH selbst warnt, dass mit KI gefundene Fehler oft auch von anderen wiederentdeckt werden, Abwarten ist also riskant. Die stabilste Lösung bleibt dieselbe wie immer – Schlüssel statt Passwörter.
Häufige Fragen
Sind Debian und Ubuntu von *sshole betroffen?
Nein. Sie verwenden glibc und nicht die musl-Bibliothek. BleepingComputer bestätigt, dass Systeme mit PAM-Authentifizierung nicht verwundbar sind, Alpine weist aber darauf hin, dass openssh-server-pam mit UsePAM no nicht betroffen ist, mit UsePAM yes dagegen schon nicht.
Reicht es, das openssh-Paket zu aktualisieren?
Nein, du musst außerdem sshd neu starten. Alpine weist darauf hin, dass das Update den bereits laufenden Dienst nicht ersetzt, die verwundbare Version bliebe also aktiv.
Kann ich mich ohne Update schützen?
Ja, vorübergehend. Setze PasswordAuthentication no in der sshd-Konfiguration und starte den Dienst neu. Prüfe vorher, ob der Login mit Schlüssel funktioniert.
Ist auch root gefährdet?
Nur in bestimmten Fällen. Mit PermitRootLogin prohibit-password, dem Standardwert, ist root nicht direkt erreichbar. Das ändert sich, wenn PermitRootLogin yes aktiv ist oder ein anderer Benutzer zu root werden kann, etwa über doas.
Gibt es eine CVE für diesen Fehler?
Laut Alpine noch nicht. Die Mitteilung besagt, dass zum Zeitpunkt des Schreibens keine Kennung vergeben war. Maßgeblich sind die Hinweise zu OpenSSH 10.6p2.
Was du nach OpenSSH 10.6p2 im Auge behalten solltest
OpenSSH hat häufigere Veröffentlichungen angekündigt, damit Korrekturen die Nutzer schneller erreichen. Der Fehler wirft einige Fragen auf, die du weiter verfolgen solltest.
- Prüfe, ob eine CVE vergeben wird und ob deine Scan-Werkzeuge sie erkennen.
- Achte darauf, wann die Hersteller von Firmware auf Basis von OpenWrt, Buildroot und Yocto Updates veröffentlichen.
- Richte eine Routine ein, mit der du kleinere OpenSSH-Releases installierst, ohne auf die geplanten Versionen zu warten.
