*sshole-Sicherheitslücke: Ein langes Passwort mit mehr als 256 Byte öffnet Alpine-Server

[HWL News Bot]

Wer einen SSH-Server auf Basis von Alpine Linux betreibt, sollte heute noch patchen. Eine zehn Jahre alte Lücke erlaubt die Anmeldung an Konten, die eigentlich gar kein Passwort haben. Als Schlüssel genügt eine Zeichenkette mit mehr als 256 Byte. Diese Sicherheitslücke wird als CVE-2026-123158 geführt und hat einen CVSS-Wert 8,1 von 10 erhalten.
... weiterlesen

 

[Lachgasschaufler]

Danke. Vor allem die tabellen helfen massiv weiter!

 

[petitbug]

Betrifft das eigentlich auch Setups, wo in der sshd_config sowieso PasswordAuthentication no steht? Meine Alpine-Kisten laufen nur mit Keys, aber mal nachschauen, ob irgendwo ein Konto ohne Passwort rumliegt, schadet trotzdem nicht.

 

[FM4E]

Betrifft das eigentlich auch Setups, wo in der sshd_config sowieso PasswordAuthentication no steht? Meine Alpine-Kisten laufen nur mit Keys, aber mal nachschauen, ob irgendwo ein Konto ohne Passwort rumliegt, schadet trotzdem nicht.

Nein, dann eher nicht. Wenn du mit dem Befehl "ssh username@IP-Adresse" versuchst eine Verbindung aufzubauen und du als Antwort "Permission denied (publickey)" erhälst, ist es safe. Problematisch wäre es bei der Antwort "Permission denied (publickey,keyboard-interactive)" oder "Permission denied (publickey,password)"

 

[petitbug]

Nein, dann eher nicht. Wenn du mit dem Befehl "ssh username@IP-Adresse" versuchst eine Verbindung aufzubauen und du als Antwort "Permission denied (publickey)" erhälst, ist es safe. Problematisch wäre es bei der Antwort "Permission denied (publickey,keyboard-interactive)" oder "Permission denied (publickey,password)"

Danke, guter Test. Noch eindeutiger wird's mit ssh -o PubkeyAuthentication=no user@host, dann probiert der Client den Key gar nicht erst. Kommt da direkt "Permission denied (publickey)" ohne Passwortabfrage, bietet der Server gar keinen anderen Weg an.