Sshole zeigt: SSH nach der Einrichtung zu vergessen, ist keine gute Idee

Wann haben Sie zuletzt wirklich über Ihren SSH-Daemon nachgedacht? Lautet die ehrliche Antwort „bei der Installation des Servers“, sitzen Sie im selben Boot wie der Großteil des Internets – und eine schnörkellose kleine Website stupst genau an dieser Stelle.

Die Seite heißt sshhole.com, auch sshole genannt, und ihre Botschaft passt in eine Zeile: OpenSSH unter musl-Linux lasse seit 2016 Zugriffe auf Konten ohne Passwort zu. Mehr liegt uns nicht vor. Die Seite, die wir gesehen haben, trägt kein Datum und enthält keine technische Beschreibung. Deshalb können wir weder den genauen Mechanismus erklären noch die Behauptung bestätigen oder eine Einschätzung zur Ausnutzbarkeit geben. Sie ist als Vorwurf zu betrachten, den man ernst nehmen sollte, nicht als gesicherte Tatsache.

Beunruhigend ist nicht der Fehler, sondern das „seit 2016“

Jede Software hat Fehler. Was diese Behauptung so unangenehm macht, ist der Zeitraum. OpenSSH genießt einen der besten Rufe in der Open-Source-Welt, und die eigene Sicherheitsseite des Projekts verweist auf ältere Angriffsklassen, für die es nie anfällig war. Dieser Ruf ist verdient. Er ist aber auch genau der Grund, warum niemand mehr genau hinsieht.

Vertrauen ist eine Form technischer Schulden. Wenn eine Komponente jahrelang unauffällig läuft, prüft niemand ihre Konfiguration, niemand fragt, was auf einer ungewöhnlichen libc passiert, und niemand nimmt sie in den Patch-Kalender auf. Diese Selbstzufriedenheit ist unserer Ansicht nach die eigentliche Geschichte, mehr als jeder einzelne Fehler. Ein Konto ohne Passwort ist auf vielen Rechnern eine kleine Merkwürdigkeit, über die man die Schultern zuckt. Kombiniert mit einem Daemon, der trotzdem den Zugang gewährt (sollte die Behauptung stimmen), ist es keine Kleinigkeit mehr.

SSH ist ein Single Point of Failure – und wir haben es so gebaut

SSH ist die Eingangstür zu Servern, Containern, Routern, Build-Rechnern und dem einen oder anderen vergessenen Raspberry Pi. Wenn es versagt, fällt nicht eine einzelne Anwendung aus, sondern das, was alles andere schützt. Wir haben diese Risikokonzentration normalisiert, weil das Werkzeug gut ist – aber gut ist nicht dasselbe wie unfehlbar.

Es wäre auch nicht das erste Mal. Der Tracker IsItPatched listet 50 bekannte CVEs für OpenSSH auf, zwei davon kritisch (die Seite ist undatiert, die Zahl ist also eine Momentaufnahme). BleepingComputer hat über OpenSSH-Sicherheitsupdates berichtet, die eine Man-in-the-Middle-Schwachstelle und eine Denial-of-Service-Lücke schlossen; eine davon wurde vor mehr als einem Jahrzehnt eingeführt. Unser Fazit: Alter Code verbirgt alte Probleme, und sie kommen zu ihrer eigenen Zeit ans Licht.

Was Administratoren tun sollten

Erstens: Beobachten Sie die Sicherheitshinweise Ihrer Distribution und spielen Sie OpenSSH-Updates ein, sobald sie erscheinen, besonders wenn Sie irgendwo musl einsetzen. Welche Version die von sshole behauptete Lücke schließt, können wir nicht sagen, denn die von uns geprüfte Dokumentation nennt sie nicht. Lesen Sie den Hinweis Ihrer Distribution, statt anzunehmen, ein einziger Befehl erledige die Sache.

Zweitens: Prüfen Sie, ob Konten mit leeren oder gesperrten Passwörtern existieren. Verlassen Sie sich nicht darauf, dass der Daemon sie abweist. Wenn die Behauptung von sshole stimmt, ist genau dieses Sicherheitsnetz gerissen.

Drittens: Verringern Sie die Angriffsfläche. Legen Sie SSH hinter ein VPN oder eine Allowlist, lassen Sie Port 22 nicht für die ganze Welt offen und bevorzugen Sie schlüsselbasierte Anmeldungen. Nichts davon behebt einen Fehler im Daemon, aber aus „jedem im Internet“ wird „jemand, der bereits in Ihrem Netzwerk ist“ – ein deutlich besseres Problem.

Zuletzt der kulturelle Wandel: Behandeln Sie OpenSSH beim Patchen wie Ihren Browser. Wir machen den Maintainern keinen Vorwurf. Ein so zentrales Projekt verdient gleichermaßen unseren Dank und unsere Aufmerksamkeit.

Unser Fazit

Keine Panik, aber auch kein Achselzucken. Prüfen Sie Ihre Konten ohne Passwort, halten Sie OpenSSH aktuell und schließen Sie SSH gegenüber dem restlichen Internet, wo immer es geht. Die Lehre aus sshole lautet nicht, dass OpenSSH schlecht wäre. Sie lautet: Den Werkzeugen, denen wir am meisten vertrauen, schenken wir am wenigsten Aufmerksamkeit.