Nachdem bei mir der Alexa Connector den Dienst verweigert hat und ich erst mal keinen Plan hatte was los war, bin ich auf Fehlersuche gegangen.
Der Fehler der mir zuerst geworfen wurde war:
Unable to negotiate with 88.99.31.202 port 58824: no matching host key type found. Their offer: ssh-rsa
Mit ein bisschen googlen bin ich darauf gekommen das durch ein OpenSSH Update auf meinem Server alte Security-Settings rausgeworfen wurden und jetzt eine Inkompatibilität herrscht.
Die betroffene OpenSSH Version ist 8.8p1. In den Release-Notes steht auch, das bestimmte Hash/Crypto-Algos deaktiviert wurden mit der Version:
https://www.openssh.com/releasenotes.html (https://www.openssh.com/releasenotes.html)
Der Workaround für die Version ist wie folgt:
1. in .ssh-Ordner eine Datei "config" erstellen.
2. in die Datei einfügen:
Host fhem-va.fhem.de
HostName fhem-va.fhem.de
HostKeyAlgorithms=+ssh-rsa
PubkeyAcceptedAlgorithms=+ssh-rsa
3. Fhem neustarten und freuen das es wieder funktioniert.
Könnte man ggf. die Crypto-Algos auf den Fhem Alexa Connector Servern anpassen, sodass neuere (z.B. RSA-SHA256 oder 512. Wird seit Version 7.2 unterstützt) benutzt werden? Ich vermute das einige in näherer Zukunft in diese Problematik reinlaufen werden.
Hallo, erst mal Danke für den Hinweis (Update auf welches Betriebssystem)?
Zur Sache selbst:
RSA ist nicht per se kaputt oder unsicher, es ist nur nicht ansatzweise so effizient (Speed und Bytes) wie ECC. Das Problem wurde bereits diskutiert, denn ursprünglich wurde beim Anlegen des Keys ein RSA_Schlüssel generiert, der nach heutigem Stand zur kurz ist. Daher wurde inzwischen auf 4096-bit-Paare umgestellt:
Findet sich in der user.js in:
Zitatconst prc = execSync(config.sshproxy.ssh + '-keygen', ['-t', 'rsa', '-b', 4096, '-N', '', '-f', pubkey_path], {stdio: 'pipe'});
Nun gibt es zur Umstellung auf ECC gleich 2 Probleme:
- Zum Zeitpunkt des Proxys gab es noch keine saubere ECC-Implementierung für Apache MINA SSHD
- Angenommen, das wäre heute weiter: Dann bleibt das Problem der Portierung, ohne einen ganz neuen Prozess / Service aufzusetzen, denn:
- Sobald der Proxy auch ECC sprechen würde, würden SSH-Clients sich bevorzugt damit verbinden. Hätte der Client (also der User auf dem Raspi) bereits einen ECC-Key, würde dieser präsentiert werden. Da er aber unbekannt ist, wäre der Nutzer nicht authentifiziert. Mit einer Umstellung würden also erst einmal alle mit existierendem ECC-Key auf die Nase fallen.
- Richtig hässlich und fehleranfällig wäre auch ein Prozess, von Alt-RSA-Schlüssel automatisch auf Neu-ECC-Schlüssel umzuziehen, ohne den Nutzer in eine Neuanmeldung zu zwingen.
Aus diesen Gründen bin ich bei RSA (4096 Bit) geblieben.
Bei mir ist es Arch Linux. Rolling Releases... wird jetzt nicht sofort bei Raspian oder Ubuntu aufschlagen, aber evtl. bei Upgrade auf neue LTS Version etc.
Ich glaube das Problem betrifft auch nicht RSA (4096Bit sollten selbst heute noch ausreichend sein) sondern das SHA1 als Hashalgo für die Signatur benutzt wird. Das erlauben von SHA512 sollte ja keinen Effekt auf die vorhanden Schlüssel haben, da lediglich die Nachricht mit einem anderen Algo gehasht wird.
Zitat von: merasil am 11 Oktober 2021, 09:51:20
Ich vermute das einige in näherer Zukunft in diese Problematik reinlaufen werden.
Stimmt! Danke für die Lösung.
Linux 5.14.14-arch1-1
core/openssh 8.8p1-1
@gvzdus, @justme1968
Vielleicht könnt Ihr ja zur angezeigten Fehlermeldung den Lösungsvorschlag von merasil hinzufügen ? Oder gleich per update die entsprechende Datei (~/.ssh/config) anlegen ?
P.S. Ich sehe gerade in MAINTAINER.txt
FHEM/39_alexa.pm justme1968 Frontends/Sprachsteuerung