Probleme mit SSH zu alten Freifunkroutern

Hallo zusammen,

ich stelle gerade meine privaten Geräte von Windows 11 auf Linux um.
Unter Windows habe ich PuTTy zwecks SSH zu meinem Freifunk-Knoten genutzt, dies klappt auch weiterhin ohne Probleme. Unter Fedora 43 KDE und der Konsole, bekomme ich seit vielen Stunden einfach keine Verbindung zum Router. Ich bin Sachen Linux relativ neu und hatte bereits einige ChatGPT-Chats inkl. SuFu auf diverse Boards. Der Knoten steht eine Stunde entfernt.

FritzBox 4040
0.32.2-beta.0-20220506 / gluon-v2021.1.2
OpenWRT 19.07
Dropbear 2019.78

Unter Windows-PuTTy habe ich die .ppk Datei in eine OpenSSH-Datei konvertiert. Da ich diese OpenSSH-Datei nicht im Fedora Schlüsselbund importieren konnte, habe ich die Datei in /home/Benutzer/.ssh als id_rsa abgeseichert. (-----BEGIN OPENSSH PRIVATE KEY-----)

Abgelegt ist der alte Key und die neuen Keys hier:
/etc/dropbear/authorized_keys inklusive chmod600

Was habe ich versucht?

  • Neue RSA-Schlüssel (2048 Bits) unter Fedora erstellt und dann per PuTTy die neuen Schlüssel auf dem Router unter authorized_keys abgelegt.
  • Neuen ED25519 Schlüssel versucht, welcher wohl aktuell nicht von der Firmware des Routers unterstützt wird.

Was funktioniert:

  • Die schlechte PuTTy-Version aus der Fedora-Repo gezogen und dort über .ppk auf den Server. Mit der Konsole und der id_rsa bekomme ich es nicht hin.
  • Weiterhin PuTTy unter Winows mit altem RSA-Schlüssel
  • Neuer Schlüssel unter Fedora via (Passwörter und Verschlüsselung 47.0.1, Seahorse) erstellt. Diese Datei zum Test als .ppk umgewandelt, mit welcher ich dann ebenfalls einen Zugriff über PuTTy bekam.

Anbei ein paar Befehle, welche bereits in die Konsole getippt wurden:
Client:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Router:

ssh root@IPv6
Unable to negotiate with IPv6 port 22: no matching host key type found. Their offer: ssh-rsa

ssh -oHostKeyAlgorithms=+ssh-rsa root@IPv6
command-line line 0: Bad key types '+ssh-rsa root@IPv6'.

Ebenfalls bekam ich schon Fehlermeldungen mit „libcrypto“
Ich gehe davon aus, dass es an meinem Fedora inkl. id_rsa liegen könnte.

Vielen Dank für Eure Hilfe. :slight_smile:

Altes OpenWrt/Gluon kann nur RSA (Host- und Userschlüssel), aktuelles OpenSSH (ab 8.8) unterstützt in Grundkonfiguration bzw. (ab 9.x?) generell RSA nicht mehr. AFAICS benötigtst Du entweder eine neuere Firmware (ab Gluon v2025.1) oder ein älteres ssh, was noch RSA eingebaut hat, was also +ssh-rsa-Direktiven noch versteht.

2 „Gefällt mir“

Steinalte ff-firmware (hier gluon 2021) will rsa-ssh Schlüssel, jede neuzeitlichen Linux Distro muss man seit etwa 5-7 Jahren an gleich mehreren Stellen die Pistole auf die Brust setzen, das zu erzwingen.

Wie das bei Fedora geht, gerade überfragt.

p. s.

2 „Gefällt mir“

An die Moderation: Das ist kein »Windows-zu-Linux«-Thema, sondern ein Problem mit gezielten Inkompatibilitäten in OpenSSH, daher würde ich »Von Win11 zu Linux: « aus dem Titel streichen.

Hint: nicht in die /etc/ssh/sshd_config packen, ggf. startet dann der OpenSSH-Server nicht mehr, weil er +ssh_dsa und/oder +ssh_rsa nicht mehr kennt … (Für Sie getestet (Deb13) ;-))

3 „Gefällt mir“

Jau!
Berechtigter Einwand. Nicht permanent in die Config tun, auch aus Sicherheitsgründen wegen potentieller ssh session downgrade Angriffe.

Wenn mir vor 15 Jahren jemand gesagt hätte, dass ein Debian stable mal Probleme mit Buildumgebungen oder Netzwerkgeräten haben wird, weil "zu modern“

3 „Gefällt mir“

Danke für die Rückmeldung. An der Gluon-FW kann ich derzeit nichts tun, außer die Betreiber meiner Region zu kontaktieren. Dort hat man ein Update aber schon länger auf dem Schirm.

Wie bekomme ich denn ein älteres ssh? Ist damit eine andere Software unter Fedora gemeint? Oder muss ich einen „älteren“ Key erstellen? Danke

$ grep rsa /etc/ssh/ssh_config
    PubkeyAcceptedKeyTypes=+ssh-rsa
    HostKeyAlgorithms=+ssh-rsa
#   IdentityFile ~/.ssh/id_rsa

Tja, da steht schein’s eine weitere Community vor dem Sprung in die Nach-4/32-Ära und über Gluon v2022.1 könnte es nach Gluon v2025.1 gehen — zumindest lt. Doku dort.

Lt. Karte hat irgendwer 2023 und 2024 schon Firmwares auf Basis von v2023.1 und v2023.2 gebaut — von v2021.1 kann man lt. Gluon-Lifecycle auf v2023.1 springen und von da nach v2025.1 … Aber die Homepage ist 2022 stehen geblieben, auf FB gibt’s seit 2023 nix Neues mehr — toi, toi, toi, das sie die Kurve noch kriegen.

Ehrlich gesagt: keine Ahnung. Müßte ein statisch kompiliertes Binary von nicht neuer als OpenSSH 8.8 sein, das klingt eigentlich prädestiniert für einen Dockercontainer mit einem 2+ Jahre alten Linux, dann würdest Du Dich in den verbinden und von dort aus auf Deinen Knoten gehen … (Ich hab’ für solche Fälle ein älteres Linux in einer VM zur Hand, aber das hilft Dir jetzt auch nicht weiter.) Oder Du versuchst, einen alten OpenSSH-Client selbst zu bauen — auch alles andere als trivial oder vergnügenssteuerpflichtig.

Wie gesagt, das hat null-komma-nichts mit Window/Linux zu tun, Dein Knoten will mit einem Zimmerschlüssel aus dem 18. Jahrhundert in Deinem SSH-Client die Verbindung aufschließen — der hat aber keine Schlüssellöcher mehr sondern nur noch Chipkartenleser :wink:

Oder anders gesagt: Die Firmware auf Deinem Knoten ist zu alt bzw. die Linux-Distribution auf Deinem Rechner ca. zwei Jahre zu neu für diese veraltete Firmare.

(Ich finde ja, man hätte ssh-rsa aus dem OpenSSH-Server nehmen können, aber im OpenSSH-Client drin lassen, aber ich muß die Software auch nicht pflegen …)

1 „Gefällt mir“

Dann bleibt es wohl vorerst bei meinem Fedora-PuTTy. Die Software läuft echt nicht gut.
Vielleicht können die Mods meinen Betreff anpassen.

Ich stoße es dann nochmal in der Region an. :slight_smile:
Danke. :slight_smile:

1 „Gefällt mir“