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 😉

Vollversagen bei OpenSSH: Is a directory

Nehmt es mir nicht übel, aber anders als ein komplettes Versagen auf ganzer Linie kann man den Fall bei OpenSSH nicht bezeichnen, zumal es um einen kleinen, aber sinnvollen Bugfix geht.

Vollversagen bei OpenSSH: „Is a directory“

Damit Ihr versteht um was es geht, müssen wir zurückreisen ins Jahr 2010. Damals wurde ein Bugreport im Bugtracker von OpenSSH veröffentlicht: https://bugzilla.mindrot.org/show_bug.cgi?id=1768

Von dem wußte ich aber nichts, als ich 2015 über das Problem gestolpert bin. Das Problem sieht wie folgt aus:

scp testdatei user@servername:/topdir/subdir/

Wenn es „subdir“ als Directory gibt, dann wird testdatei dahin kopiert und alles ist gut. Wenn es „subdir“ aber nicht gibt, dann würde man ja wohl erwarten, eine Fehlermeldung zu bekommen, aus der genau das hervorgeht, oder? Tja, wie soll ich sagen, ähm…nein!

Actual results:

scp: /usr/doesnotexist/: Is a directory

Wow.. oder? Das komplette Gegenteil von dem was man annehmen würde 🙂 Diese Aussage bekommt jeder, der sich OpenSSH selbst aus den original Sourcen kompiliert, denn, obwohl der Fehler schon 2010 gemeldet wurde und 2015 Jakub Jelen von Red Hat einen kompletten Patch geschrieben hat und das seit Fedora 20 und RHEL8 an alle „Nutzer“ in einem „Feldtest“ ausgerollt wurde, sieht sich das Projekt hinter OpenSSH nicht dazu in der Lage.

Eingeführt wurde der Bug übrigens um das Jahr 2005 herum. Damit sind es streng genommen schon 15 Jahre, die der Bug da vor sich hin dümpelt. Da ich Fedora nutze, habe  ich das Problem nicht mehr und viele andere Distros haben den RH Patch übernommen, aber traurig ist das schon, oder?

Leider mußte ich gerade feststellen, daß die neue Fehlermeldung auch nicht gerade viel besser als die alte ist:

scp: /tmp/ugdjkfh/: Not a directory

Das stimmt zwar inhaltlich, gibt aber den wahren Ursprung meiner Meinung nach nur unzureichend wieder 😉 Daher war ich mal so frei, Jakub darauf hinzuweisen, zumal ich den Bug da auch bei RH reportet hatte, vielleicht bekommt man nach 10 Jahren dann doch nochmal ein „Does not exist“ 😀 Wobei man als Server ja unterscheiden können muß zwischen „directory gibts nicht“ und „Du User, darfst da nicht reinschreiben“ unterscheiden wenn so eine Anfrage kommt, sonst könnte ein User niedriger Privilegierung die Verzeichnisstruktur einfach durchtesten. Ok, er könnte das viel einfach, wenn er eingeloggt wäre, aber ggf. hat der Account nur SFTP Zugang, ohne Interaktiven Shellzugang zu haben. Wäre ja denkbar.

Wie man sieht, doch nicht ganz trivial so eine saubere Fehlermeldung 😉

Wenn Ihr jemanden im OpenSSH Team kennt, könnt Ihr Ihn ja mal auf dieses Problem ansprechen. Übrigens erinnert mich das ganz stark an meinen Bugreport an ProFTP, weil deren 20 Jahre alte CHROOT Anweisung den Fall, daß da einer das Ziel per Symlink umgeleitet hat, nicht abgedeckt hatte. Das wurde auch Jahrelang geblockt bis es dann doch wer geschafft hatte, die Entwickler umzustimmen. Leider durfte ich mit dem 20 Jahre Bug-Jubiläumsvortrag nicht auf dem CCC sprechen. Dabei wollte ich nur son 15 Minuten Vortragsfenster im Nebenraum haben. Ich hatte denen sogar einen Patch für das Problem geschickt. Das wäre bestimmt lustig geworden, wenn die ProFTP Devs sich auf der Vortragsliste gesehen hätten 😀 Vielleicht packe ich Euch den Vortrag als PDF mal auf die Seite.

zuviel Wind um Backdoor in OpenSSH

Wie Deutschlands Lieblings-IT-Verschwörer Fefe in seinem Blog berichtet, hat das FBI in einer Informationsfreiheitsanfrage zu OpenBSD mit einem Dokument geantwortet, daß auf eine Backdoor in OpenSSH hindeutet, allerdings schon im Jahr 2002.

Wo da jetzt die Neuigkeit war, wird allerdings nicht gesagt, was nicht verwundert, denn das war gar keine:

https://www.symantec.com/security-center/writeup/2002-111413-3305-99

Der Fall ging ordnungsgemäß durch die Securityportale 🙂 Da war wohl der FTP Server von OpenBSD aufgehebelt worden und jemand hat den Sourcecode verunreinigt. Wurde gefunden, wurde behoben, wurde vergessen 😀

Fedora OpenSSH Alarm: Nicht updaten auf 7.2p2-6 !

Achtung: openssh-server version 7.2p2-6 ist defekt

Das heute von Fedora verteilte Update von openssh „7.2p2-6“ ist defekt. Wer per ssh auf einen Server mit dieser Version einloggt, sieht aus wie root, aber man ist nicht root. Man hat keine Root-Capabilities mehr, was z.b. darin gipfelt, daß man nicht mehr in sein eigenes Homeverzeichis wechseln kann.

Wer in seinem dnf.rpm.log das findet:

Oct 19 14:03:16 INFO Upgraded: openssh-7.2p2-6.fc23.i686
Oct 19 14:03:20 INFO Upgraded: openssh-server-7.2p2-6.fc23.i686
Oct 19 14:03:20 INFO Upgraded: openssh-clients-7.2p2-6.fc23.i686
Oct 19 14:03:20 INFO Cleanup: openssh-clients-7.2p2-3.fc23.i686
Oct 19 14:03:20 INFO Cleanup: openssh-server-7.2p2-3.fc23.i686
Oct 19 14:03:25 INFO Cleanup: openssh-7.2p2-3.fc23.i686

ist betroffen.

Aufgrund des Fehler kann man den Fehler auch  nicht via SSH beheben. Ihr könnt natürlich auf das nächste Fedora Update warten, daß dann offentlich einen Bugfix enthält, aber bis dahin habt Ihr im Notfall ein Problem.

Bei RedHat ist bereits ein Bugticket offen und man arbeitet an einem Fix. Scheinbar ist SELinux, bzw. dessen Abwesenheit daran beteiligt.

Workaround: Downgrade auf 7.2p2-3

Über den Kojilink lädt man die drei Paket runter:

Koji :  http://koji.fedoraproject.org/koji/buildinfo?buildID=756836

dann loggt man sich via MONITOR KONSOLE ein und downgraded die Files mit :

rpm -U –force openssh*rpm

danach in /etc/dnf/dnf.conf einfügen:

exclude=openssh*

erst dann zieht das nächste Update nicht wieder die defekte Version auf den Server.