Vereinsserver Unterstützung von rsa-sha2-256

Begonnen von Sidey, 29 Dezember 2024, 22:02:01

Vorheriges Thema - Nächstes Thema

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

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.

Sidey

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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

gvzdus

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.

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

gvzdus

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.

gvzdus

#7
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.

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

gvzdus

Kann es sein, dass Du Port 22022 vergesssen hast, und mit dem hochoffizielle SSH-Demon der Amazon Linux Distribution sprichst? :-)

Otto123

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?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

gvzdus

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.

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Otto123

#13
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-nistp521
Ich 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 58824
Zitatdebug2: 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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker