Halöchen,
ich bin derzeit dabei, das Docker Image für alexa-fhem auf Bookworm zu aktualisieren.
Damit einher kommt auch eine neue openssl Version, die den schon seit längerem SHA-1 hash Algorithmus deaktiviert.
Mir sind natürlich Möglichkeiten bekannt weiterhin SHA1 für OpenSSL zu aktivieren, allerdings hat das deaktivieren ja seinen Grund.
Die erzeugten RSA Keys, sollten meiner Meinung nach auch weiterhin mit SHA2 256 funktionieren.
Nach meinem derzeitigen Kenntnisstand unterstützt der Vereinsserver allerdings derzeit kein SHA2-256 oder SHA2-512.
Die Unterstützung dieser Algorithmen wäre wünschenswert.
Was wäre dafür denn zu tun?
Viele Grüße
Sidey
Hi Sidey,
der Vereinsserver verwendet im System
OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022
Ich verstehe die Frage nicht komplett, liegt aber an meinem geringen Verständnis für das gesamte Thema. Ich brauche keine Erklärung.
Ich will aber die Diskussion mitlesen ;)
Gruß Otto
Ich vermute, es geht hier um das Programm, was auf dem VA-Server des Vereins laeuft, und die Verbindung zwischen Amazon und den Benutzern herstellt.
Die Benutzer verbinden sich per SSH mit diesem Programm @fhem-va.fhem.de, was wiederum von Amazon kontaktiert wird.
Es existiert eine neuere Version der vom Programm verwendeten SSHD Bibliothek, was eventuell das o.g. Problem loesen koennte.
Keine Ahnung, wieviel Aufwand der Austausch bedeutet, das muesste der Autor sagen.
Ich denke, auf dem Vereinsserver läuft ein Apache Mina:
https://github.com/gvzdus/sshd-oauthmux/blob/b2571b006227166760192d4e8b7aa0495b31260b/pom.xml#L33
In Version 2.2.0 wird nur SHA1 unterstützt.
Ab Version 2.3.0 kann Apache Mina auch SHA2 256/512:
https://github.com/apache/mina-sshd/blob/master/docs/changes/2.3.0.md#behavioral-changes-and-enhancements
Auf der Clientseite (die für uns nicht relevant ist) muss seit dem ssh-rsa explizit aktiviert werden.
Einige Versionen größer 2.3.0 beinhalten Bugfixes und Anpassungen.
Aktuell ist Version 2.14.0
Diese soll für den Server noch ssh-rsa unterstützen:
https://github.com/apache/mina-sshd/blob/1cc0c0c98e6489449dccff65dd6dc81e74d947c3/docs/standards.md?plain=1#L145
Ich denke, um die bestehenden Installation weiterhin zu unterstützen muss auch erst mal ssh-rsa weiterhin im Server unterstützt werden, aber zusätzlich braucht es weitere Optionen wie SHA2 oder auch ed25519.
Grüße Sidey
Ich habe mich gestern etliche Stunden "rumgeärgert".
Die Migration auf 2.3.0 ist noch relativ problemlos: Dann wird "rsa-sha2-512" angeboten und unterstützt. Zwar benötigt der sonstige Code Änderungen, die erscheinen mir aber noch harmlos.
2.14.0 ist eine gewisse Hölle:
- Sehr viele, tiefe Änderungen, insbesondere auch im PortForwarder-Code (also beim "Trick", auf Serverseite nicht real einen Port zu öffnen, sondern nur virtuell die einkommenden AWS-Requests in den Channel zum Client zu schicken)
- Support von RSA raus
- RSA-Hostkey wird nicht mehr geladen, stattdessen ein neuer erzeugt
Vor allem aber: Sobald der Vereinsserver etwas Moderneres als RSA anbieten würde, der Nutzer also z.B. mit ed25519 ankommt, fehlt der alte SSH-Key, der den Nutzer identifiziert.
Meine (schon sehr alten) Überlegungen gingen dahin, auf 2 Ports zu lauschen: "Legacy RSA Only" und "modern", und weitere "Befehle" zu implementieren, die eine automatische Migration "RSA auf ..." unterstützen. Das erfordert natürlich auch Änderungen an alexa-fhem - aber das ist noch "milde".
Vorschlag:
- Auf 2.3.0 kann ich wohl problemlos gehen und ggf. zurückfallen: Wenn Dir das was bringt.
- Für einen Support aktueller Verfahren erscheint es mir schwierig, eine MINA-Version zu finden, in der noch beides möglich ist. Die Dokumentation von MINA ist übersichtlich...
Wenn die Migration auf 2.3.0 bereits hilft, kann ich das umgehend probieren.
Hallo gvzdus,
ich denke die Migration auf 2.3.0 hilft schon mal.
Das ein Upgrade von 2.3.0 auf 2.14 kein einfaches Unterfangen wird habe ich mir schon vorstellen können, aber so ganz schlau würde ich aus dem Changelog auch nicht.
Der alte RSA Key sollte mit sha2-256 bereits funktionieren, das wäre ja schon ein Schritt.
PS: einen Testserver gibt es nicht oder?
Grüße Sidey
Wenn Du magst: Auf 3.255.239.36:22022 teste ich gerade mit 2.3.0. Hier kannst Du die Befehle wie "status", "register" etc. probieren und den Algorithmus sehen.
Ich habe soeben den Vereinsserver auf Mina 2.3.0 aktualisiert. Das scheinen alle Clients "überlebt" zu haben, die Verbindungen der Nutzer wurden wieder aufgebaut.
Update: Auch einmal den Flow des Trennens des Skills sowie des Wiederverbindens getestet.
Hi gvzdus,
Zitat von: gvzdus am 04 Januar 2025, 11:31:10Wenn Du magst: Auf 3.255.239.36:22022 teste ich gerade mit 2.3.0. Hier kannst Du die Befehle wie "status", "register" etc. probieren und den Algorithmus sehen.
Ich habe getestet, aber mir scheint, dass SHA2-256 oder SHA2-512 derzeit nicht akzeptiert wird:
debug1: Offering public key: /alexa-fhem/.ssh/id_rsa RSA SHA256:ZT9YvC8kNL9xK0WwvyZ+Udj1nd3nZzN7+nnUyf8YjPc explicit
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: keyboard-interactive,publickey
debug1: No more authentication methods to try.
alexa-fhem@3.255.239.36: Permission denied (keyboard-interactive,publickey).
Hast Du es mit SHA2 oder nur mit SHA1 probiert?
Viele Grüße
Sidey
Kann es sein, dass Du Port 22022 vergesssen hast, und mit dem hochoffizielle SSH-Demon der Amazon Linux Distribution sprichst? :-)
Zitat von: gvzdus am 04 Januar 2025, 11:53:39Ich habe soeben den Vereinsserver auf Mina 2.3.0 aktualisiert.
Ich habe da ne Zwischenfrage: Wer lauscht jetzt eigentlich auf va.fhem.de auf Port 58823? Dort werden mir zwei Verbindungen angezeigt, aber mit Telnet bekomme ich keinen Banner. Ich meine früher war das anders.
Auf Port 58824 meldet sich jetzt
SSH-2.0-APACHE-SSHD-2.3.0
Steht die 2.3.0 für die erwähnte Mina Version?
Moin, 58823 ist der HTTP-Listener von Tomcat. Du erreichst ihn von außen unter https://va.fhem.de/.
Hier kommen zumindest die HTTP(s)-Requests beim Aktivieren des Skills zum Tomcat an.
Ja, SSH-2.0-APACHE-SSHD-2.3.0 bedeutet, dass die neue(re) MINA-Version aktiv ist.
Zitat von: gvzdus am 04 Januar 2025, 12:54:32Kann es sein, dass Du Port 22022 vergesssen hast, und mit dem hochoffizielle SSH-Demon der Amazon Linux Distribution sprichst? :-)
Leider war es das nicht
Ich habe es so verbunden:
ssh -v -F .ssh/config -p 22022 3.255.239.366
Viele Grüße
Sorry das war ein Eigentor, der Befehl fragt nur den Client
Ich habe davon ja nicht viel Ahnung,
aber Unterstützt unser va.fhem.de nicht jetzt sha2 ?ssh -Q sig va.fhem.de -p 58824
ssh-ed25519
ssh-rsa
rsa-sha2-256
rsa-sha2-512
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521Ich meine, das war vor der Änderung von Georg anders.Bin ich damit auf der richtigen Spur? Aktualisierter va Server
ssh -vvv va.fhem.de -p 58824Zitatdebug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group18-sha512,diffie-hellman-group17-sha512,diffie-hellman-group16-sha512,diffie-hellman-group15-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
Zumindest ein ältere ssh Server in meiner Umgebung liefert da keinerlei sha2 Einträge
Zitatdebug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc
debug2: ciphers stoc: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc
debug2: MACs ctos: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1-96,hmac-sha1,hmac-md5
Zwischenzeitlich kann ich berichten, dass die Verbindung mit dem Testserver und SHA2-256 jetzt klappt.
Aufgefallen ist mir aber, dass sich der Fingerprint vom Server geändert hat.
Zu va.fhem.de klappt es hingegen nicht.
Grüße Sidey
ich weiß nicht ob Du da fhem-va.fhem.de nehmen musst. Die hinterlegten IP sind aber identisch.
Auf "meinem" Testserver (meine Spiel-Instanz bei AWS, die hoch- und runterfährt) ist eh' buntes Chaos.
Du musst ja die zig Level unterscheiden:
- Hostkey-Format
- KeyExchange
- Signatur
- Verschlüsselung
etc.
Zu dem Elend von Apache MINA gehört eine völlig unbefriedigende Hostkey-Verwaltung. Das scheint nie produktiv mit mehreren Verfahren parallel gelaufen zu sein, sondern immer nur mit einem Verfahren. Zu den Tücken gehört auch, MINA dazu zu bewegen, auch nur einen selbst generierten Key zu persistieren.
Ich werde da kurzfristig nicht weiterkommen, einen Migrationspfad auf ED25519 / ECDSA im Parallelbetrieb zu RSA anzubieten.
Selbst auf 2 getrennten Ports "zickt" MINA.
Hi gvzdus,
Ja ist für mich leider auch etwas kryptisch. Ich werde das die Tage noch genauer vergleichen.
Ggf. weichen wir etwas vom Thema ab, aber was spricht eigentlich dagegen ein opensshd zu verwenden?
Darüber kann man doch einen ssh Tunnel aufbauen um darüber wäre es doch grundsätzlich möglich die Kommunikation zu dem Webserver zu etablieren.
Grüße Sidey
Weil ja zwar der Befehl "Öffne einen Listener-Port auf dem Zielserver und verbinde ihn mit meinem lokalen nodejs" (ssh -R) verwendet wird, aber der Zielserver keine realen TCPIP-Ports öffnet, sondern sie nur virtuell mit einkommenden HTTP-Requests von Amazon beschickt.
Ich denke mal, Rudi hat kein Problem mit der Veröffentlichung: Es sind aktuell 2671 Nutzer verbunden, es werden also 2671 TCP-Verbindungen "gehalten".
Da hätte man eher vor 5 Jahren auf Websockets setzen sollen - war dem Andre sein Reden, aber ich wollte SSH :-)
Die "Magie" der Software ist ja: "Egal, wie Dein SSH-Key ist: Annehmen tue ich Dich. Beweise im folgenden, dass ich legitim Dir die für Dich bestimmten Amazon-Requests weiterleiten darf - danach ist Dein Secret bei Amazon mit Deinem SSH-Key verknüpft".
Ho gvzdus,
Die Verbindung zum Testserver lässt sich leider nicht mehr aufbauen um die Unterschiede analysieren zu können.
Da der Server grundsätzlich rsa-sha2-256 und 512 anbietet vermute ich hier einen der in 2.3.0 noch vorhandenen Bugs.
Aktuell weiss ich nicht, was ich effektiv machen kann um zu helfen.
Grüße Sidey
ich bin heute auch auf bookworm gegangen (raspi) und tja... problem
alexaFHEM.ProxyConnection
error; Reverse Proxy replied with neither registered nor unregistered status: out: err:fhem@fhem-va.fhem.de: Permission denied (keyboard-interactive,publickey).
wie kann ich SHA1 bei bookworm aktivieren, damit alles wieder läuft?
Zitat von: mkraus81 am 10 Januar 2025, 20:25:32ich bin heute auch auf bookworm gegangen (raspi) und tja... problem
alexaFHEM.ProxyConnection
error; Reverse Proxy replied with neither registered nor unregistered status: out: err:fhem@fhem-va.fhem.de: Permission denied (keyboard-interactive,publickey).
wie kann ich SHA1 bei bookworm aktivieren, damit alles wieder läuft?
Wie das geht, habe ich dir gerade per pm schon geschrieben.
Grüße Sidey
@Sidey DANKE für die Hilfe... kann man die Lösung nicht hier posten, falls andere auch das Problem haben?
Zitat von: mkraus81 am 10 Januar 2025, 20:53:09@Sidey DANKE für die Hilfe... kann man die Lösung nicht hier posten, falls andere auch das Problem haben?
Die Lösung ist eigentlich nicht mehr diese SHA Methode zu verwenden und stattdessen eine die als sicher eingestuft wird. Daher werde ich es hier nicht Posten.
Es gibt dazu auch schon Posts im Forum, die meinen Verdacht bestätigen, dass hier einfach ohne Wissen Dinge angewendet werden, weil es halt geht.
Ob sich aus dem Workaround ein reales Sicherheitsrisiko ergibt vermag ich nicht zu bewerten, aber empfehlen werde ich diese Vorgehensweise nicht die ich dir geschrieben habe.
Über das Docker Image habe ich ja wenigstens die Chance den Workaround wieder zu entfernen.
Grüße Sidey
ich kenn mich mit dem SHA Methode so auch nicht aus...
aber klar, wenn das eine Sicherheitslücke ist, sollte man das beim "Server" anpassen...
aber wenn ich das hier richtig lese scheint dies nicht ganz so einfach zu sein