OpenSSH: neuere ssh Versionen verweigern Verbindung

In der Fedora Welt kommt seit Wechsel auf Fedora 33 zu einem Problem mit OpenSSH-Servern, wenn die noch alte Hostskeys verwenden oder man selbst zum Authentifizieren einen Key benutzen möchte, der noch SHA1 als Hashalgorithmus benutzt.

OpenSSH: neuere ssh Versionen verweigern Verbindung

Das sollte eigentlich nicht passieren, daß man mit einem Clienten nicht mehr in seinen Server kommt, aber zur Zeit häufen sich die Meldungen, daß man mit dem OpenSSH Shellclienten von Fedora 33 nicht mehr auf Server einloggen kann, wenn entweder der Server einen alten SHA1 Keys verwendet, oder der Client einen Authkey benutzt der noch SHA1 ist.

Die temporäre Abhilfe ist, dem Clienten mitzuteilen, daß er gefälligst den alten SHA1 weiter benutzen soll. Dazu ruft man ssh mit dem Argument „-oPubkeyAcceptedKeyTypes=+ssh-rsa“ auf:

ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa root@servername

Auf lange Sicht muß man natürlich einen neuen Schlüssel auf den Servern und für seinen Zugang ausrollen. Dazu muß man wissen, ob man davon überhaupt betroffen ist und da sagt einem der SSH-Keygenerator:

ssh-keygen -l -f .ssh/Krypto.id_rsa
4096 SHA256:ehMkPi1CRDPCoOYMxdTI8BB2+TkCa13CyMQXX5EXesg id@braunschweig.de (RSA)

Zuerst die Schlüssellänge 4096 Bits, dann der gesuchte Hashalgorithmus „SHA256“ und am Ende der Type „RSA“.  Wenn Ihr betroffen seid, weil Eurer Key unter 2048 und/oder SHA1 ist, dann braucht Ihr einen neuen Key:

ssh-keygen -b 4096 -t rsa-sha2-512 -N „PASSWORD“ -f „FILENAME“ -C „Kommentar“

wobei -N -f und -C alle optional sind, aber falls Ihr größere Mengen an Schlüsseln erzeugen müßte, ist das ganz hilfreich 🙂

Am Ende stellt sich nun aber heraus, daß es gar kein Fedora33 „Feature“ war, daß zu dem Problem geführt hat, sondern ein OpenSSH Bug. Hier der Patch, falls Ihr das adaptieren müßt:

— sshconnect2.c.orig 2020-09-26 07:26:37.618010545 -0700
+++ sshconnect2.c 2020-09-26 07:25:35.665009029 -0700
@@ -1281,10 +1284,9 @@
*/
if (ssh == NULL || ssh->kex->server_sig_algs == NULL ||
(key->type != KEY_RSA && key->type != KEY_RSA_CERT) ||
– (key->type == KEY_RSA_CERT && (datafellows & SSH_BUG_SIGTYPE))) {
– /* Filter base key signature alg against our configuration */
– return match_list(sshkey_ssh_name(key),
– options.pubkey_key_types, NULL);
+ ((key->type == KEY_RSA || key->type == KEY_RSA_CERT)
+ && (datafellows & SSH_BUG_SIGTYPE))) {
+ return xstrdup(sshkey_ssh_name(key));
}

/*

Der Patch ist nicht von mir, sondern von Gordon Messmer und wurde erst vor einigen Stunden bei OpenSSH eingereicht. Mal sehen was daraus wird 😉

Über den Sinn und Unsinn von MD5 Checksummen auf Webseiten

Es war einmal vor einigen Tagen, … okok, es war heute, ich poste den Beitrag nur später… ähähämm .. nochmal… es war einmal ein junger Stern am Kryptohimmel. Sein Name war MD5 und er war von der Rasse der Hashe, die aus dem Land der Algorithmen stammten. Unser junger Stern wuchs schnell zu einem ganz großen Hash heran, der für viele Dinge der Menschen seinen Schutzzauber sprach und so für Ihre Sicherheit sorgte.

Eines Tages kam ein Sprößling der Gattung Mensch, aus der Rasse der Distributoren, auf die Idee, doch seine digitalen Datenrohlinge von unserem jungen Stern vor Veränderungen schützen zulassen,  so daß jeder erkennen mag, daß er eine Fälschung den digitalen Fluß hinabschifft.

Am Beispiele der Slacks soll hier gezeigt werden, wie er es anstellte :

Parent Directory
slackware64-14.2-install-dvd.iso30-Jun-2016 23:222.6G
slackware64-14.2-install-dvd.iso.asc30-Jun-2016 23:22181
slackware64-14.2-install-dvd.iso.md530-Jun-2016 23:2267
slackware64-14.2-install-dvd.iso.txt30-Jun-2016 23:21198K

Unser mächtiger Stern sprach einen Schutzzauber über den jungen Datenrohling aus und dieser wurde zusammen mit dem jungen Datenrohling in sein Netz gelegt. Nun konnte jedermann, der den Datenrohling inne hatte prüfen, ob es der echte Datenrohling war, oder nur eine böse Fälschung ins Nest gelegt worden war.

Die Jahre gingen ins Land und unserer mächtiger Stern wurde alt und gebrechlich. Seine Schutzkräfte liessen nach und dennoch wandten sich die Menschen an ihren einst so mächtigen Stern und erbaten seinen Schutzzauber. Ein junger, mächtigerer Stern aus der Rasse der Hashe, stiess unseren altern Stern von seinem Throne und erfüllte den Menschen füderan ihre Schutzwünsche; sein Name: SHA256.

Es war eine Zeit in Aufruhr, denn böse Mächte unter den Menschen brachen in die Datenhorte derer ein, welche die Datenrohlinge für das Gute schufen und tauschten diese gegen billige Fälschungen aus Fernost aus. Ein Hort nach dem anderen wurde heimlich aufgebrochen und infiltriert, und dennoch legten die Menschen weiterhin Ihren Schutzzauber einfach in den Datenhort Ihres Datenrohlings, denn sie vertrauten darauf, daß sie klüger waren, als die Bösen unter ihnen.

Eines Tages geschah das Unfassbare: Ein Mensch forderte den alten Stern auf, einen Schutzzauber für seinen Datenrohling zu sprechen und unser alter Stern, sprach den Zauber aus, und die Menschen legten den Zauber wie immer zu Ihrem Datenrohling, oder nicht ? Nein! Denn der Mensch war böse und hatte den guten Zauber für seine Fälschung erbeten. Da der alte Stern alt und gebrechlich war, erkannte er dies nicht und so konnte der Mensch seine Fälschung in einen infiltrierten Datenhort geben und den guten Schutzzauber dazu legen, ganz wie es die guten Menschen mit Ihren Datenrohlingen taten.

Ein böser Fluch kam über die Datenschiffer und alle diejenigen, die diese Datenrohlinge in Ihre Bratenröhre schoben. Die Menschen wandten sich an die Distributormenschen und diese verstanden die Welt nicht mehr. Genau deswegen hatten Sie doch den Schutzzauber zu Ihrem Rohling gelegt, auf daß die Schiffer vorher erkannten, das Ihrer echt war und der andere nicht. Der Datenrohling war nicht ihrer, ja, aber der Schutzzauber hätte das doch zeigen müssen!

Doch erst  dann, als es zu spät war, erkannten Sie Ihren Fehler: Sie hätten Ihren Schutzzauber in einen anderen Datenhort ablegen müssen, der nicht vom Bösen infiltriert gewesen ist.

Darum liebe Kinder merkt Euch: Digitale Signaturen und das damit signierte Datenpaket aus der gleichen gebrochenen Datenquelle zu vergleichen, ist komplett sinnlos. Signaturen, egal, ob alt und gebrechlich 😉 , gehören auf ein logisch nicht mit dem Datenfile zusammenhängenden anderen Datenspeicher, der anders abgesichert ist, als der für das signierte Datenfile.

Man darf weiterhin behaupten, es wäre eine gute Idee, keine gebrochenen Hashalgorithmen mehr zu benutzen. Aber das ist eine andere Geschichte.