[Bug][Potential Incompatibility]Alexa Connector Server nutzt alte sshd settings

Begonnen von merasil, 11 Oktober 2021, 09:51:20

Vorheriges Thema - Nächstes Thema

merasil

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

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.

gvzdus

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.

merasil

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.

mimue

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



Gigabyte Brix, Arch Linux, CUL_MAX, TCM310, HM-Lan, LevelJET, VIERA, Fritz AHA, Fritz RC, FBDECT, NetIO, Alexa, Netatmo Presence