1781AW 10.42.1311SU13Terrapin SSH Fix - keine Verbindung mehr möglich

[Killerjoe]

Hallo zusammen,
evtl. hat hier jemand Kontakt zu Lancom und kann dies weitergeben.
An einem meiner Router 1781AW habe ich die Software 10.42.1311SU13 eingespielt und dann festgestellt, dass nun keine SSH Verbindung mehr möglich ist. Lauf Release Notes wurde ein Terrapin SSH Fix eingebracht und hängt evtl. mit dem Fehler zusammen. An anderen Routern mit aktueler Firmware habe ich dieses Problem nicht. Switche ich zurück auf die RU12 funktioniert SSH wieder ohne Probleme.
Beim SSH Verbindungsaufbau wird sofort abgebrochen mit der Fehlermeldung: "Remote side sent disconnect message type 10 (connection lost) mit Putty 0.80, RoyalTS 7.2, Ubuntu Linux 22.04.04 LTS usw.

Vielen Dank und viele Grüße
Jochen

[rotwang]

Ich habe hier die SU13 in ein1781EF+ eingespielt (der SSH-Stack ist der gleiche wie auf einem 1781AW) und kann mich problemlos mit dem Gerät per SSH verbinden, sowohl mit Putty 0.80, als auch mit der aktuellen OpenSSH 9.2 in einer Debian Stable, als auch mit einer lokal gebauten OpenSSH 9.6. Alle drei haben bereits die Protokollerweiterung, die Teil der Terrapin-Fixes ist:

Code: Alles auswählen

> sho ssh ses

Active SSH Sessions:

PID    Peer                 User             Role   Auth-Method          Key-Exchange                         Encryption                                         Extensions                               Peer-Identifier
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
261    192.168.11.4:38782   root             Server publickey            curve25519-sha256@libssh.org         chacha20-poly1305@openssh.com                      ext-info,kex-strict-v00@openssh.com      SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2

Das LCOS verlangt die Erweiterung aber nicht zwingend, eine OpenSSH 8.9 unter Ubuntu ohne kex-strict-v00@openssh.com geht bei mir genauso. Wie sieht Deine SSH-Konfig unter Setup/Config/SSH aus? Falls Du die Möglichkeit hast, parallel auf einem anderen Weg auf das Gerät zu kommen (z.B. per Outband), was erzählt ein SSH-Trace während des Verbindungsversuchs?

[Dr.Einstein]

Keinerlei Auffälligkeiten bei uns, egal ob ganz alte, alte oder neue Clients, alle SSH Clients funktionieren weiterhin mit der 10.42SU13.

[Killerjoe]

Vielen Dank für Eure Antworten.
Ok, dann scheint es ein Problem an meinem Router zu sein.

Ich habe eine serielle Verbindung aufgebaut und den Trace aktiviert und hier ist das Ergebnis:

Code: Alles auswählen

root@Lancom_1781AW_Windfang:/
>
[SSH] 2024/03/18 22:37:26,406
Incoming connection request:
--> granted


[SSH] 2024/03/18 22:37:26,411
Creating new SSH server-side connection:


[SSH] 2024/03/18 22:37:26,412
Starting new SSH connection (PID 362):
--> created connection structures
--> opened file
--> wrote our own identification string
--> initial connection handling succeeded, off we go...


[SSH] 2024/03/18 22:37:26,413
--> peer identifier is 'SSH-2.0-PuTTY_Release_0.80'
--> Writing KEXINIT message:
---> not written successfully
--> could not write initial key exchange record, giving up


[SSH] 2024/03/18 22:37:26,413
Deleting SSH connection:

Wenn ich auf die RU12 wieder zurück gehe, sieht meine SSH Session so aus:

Code: Alles auswählen

root@Lancom_1781AW_Windfang:/
> show ssh ses

Active SSH Sessions:

PID    Peer                 User             Role   Method               Encryption                     Peer-Identifier
---------------------------------------------------------------------------------------------------------------------------
274    192.168.1.50:27715                  Server                      aes                            SSH-2.0-PuTTY_Release_0.80

Der Trace mit RU12 sieht so aus:

Code: Alles auswählen

root@Lancom_1781AW_Windfang:/
>
[SSH] 2024/03/18 22:43:06,851
Incoming connection request:
--> granted


[SSH] 2024/03/18 22:43:06,857
Creating new SSH server-side connection:


[SSH] 2024/03/18 22:43:06,857
Starting new SSH connection (PID 274):
--> created connection structures
--> opened file
--> wrote our own identification string
--> initial connection handling succeeded, off we go...


[SSH] 2024/03/18 22:43:06,858
--> peer identifier is 'SSH-2.0-PuTTY_Release_0.80'
--> Writing KEXINIT message:
---> omitting ssh-dss from own set of allowed host key algorithms because DSS key does not fulfill min/max key length requirements
---> resolving ecdsa-sha2 to ecdsa-sha2-nistp256 as own host key algorithm
---> written successfully


[SSH] 2024/03/18 22:43:06,873
Received Message 20 on connection (PID 274):
--> Message is KEXINIT:
---> Peer key exchange algorithm list is 'sntrup761x25519-sha512@openssh.com,curve448-sha512,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,diffie-hellman-group15-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1,ext-info-c,kex-strict-c-v00@openssh.com'
---> selected 'curve25519-sha256@libssh.org' as key exchange algorithm
---> peer supports extension message
---> omitting ssh-dss from own set of allowed host key algorithms because DSS key does not fulfill min/max key length requirements
---> resolving ecdsa-sha2 to ecdsa-sha2-nistp256 as own host key algorithm
---> Peer host key algorithm list is 'ssh-ed448,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss'
---> selected 'ecdsa-sha2-nistp256' as host key algorithm
---> initial guess wrong
---> Peer C->S crypto algorithm list is 'aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,3des-ctr,3des-cbc,blowfish-ctr,blowfish-cbc,arcfour256,arcfour128'
---> selected 'aes256-ctr' as C->S crypto algorithm
---> Peer S->C crypto algorithm list is 'aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,3des-ctr,3des-cbc,blowfish-ctr,blowfish-cbc,arcfour256,arcfour128'
---> selected 'aes256-ctr' as S->C crypto algorithm
---> Peer C->S MAC algorithm list is 'hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-etm@openssh.com'
---> selected 'hmac-sha2-256' as C->S MAC algorithm
---> Peer S->C MAC algorithm list is 'hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-etm@openssh.com'
---> selected 'hmac-sha2-256' as S->C MAC algorithm
---> Peer C->S compression algorithm list is 'none,zlib,zlib@openssh.com'
---> selected 'none' as C->S compression algorithm
---> Peer S->C compression algorithm list is 'none,zlib,zlib@openssh.com'
---> selected 'none' as S->C compression algorithm


[SSH] 2024/03/18 22:43:06,880
Received Message 30 on connection (PID 274):
--> Message is KEX_ECDH_INIT:
---> peer Curve25519 key read
---> start Curve25519 key generation


[SSH] 2024/03/18 22:43:06,925
Curve25519 private key generation completed on connection (PID 274) (took 44422 us):
 -> correct instance, pass on:


[SSH] 2024/03/18 22:43:06,925
---> resulting master key:
 <33 bytes>


[SSH] 2024/03/18 22:43:06,971
KEXInit Curve25519 master secret computation completed on connection (PID 274) (took 45157 us):
 -> correct instance, pass on:


[SSH] 2024/03/18 22:43:06,996
ECDSA signature computation completed on connection (PID 274) (took 24845 us):
 -> correct instance, pass on:
---> wrote KEX_ECDH_REPLY message
---> sent NEWKEYS message to peer
---> activated S->C keys
---> reenabling data transfer
---> wrote EXT_INFO message with 1 extension

Viele Grüße
Jochen

[GrandDixence]

Es ist nicht die Problemlösung, aber eine schnelle Problemumgehung:

Wenn der LANCOM-Router mit RSA-Schlüsselmaterial (4096 Bit) für den SSH-Server ausgerüstet ist, würde ich den LANCOM-Router so umkonfigurieren, dass als Hostkey-Algorithmus ein sicheres RSA-Verfahren zum Einsatz kommt. Gemäss Trace verschluckt sich der LANCOM-Router an der Hostkey-Alogrithmus-Konfiguration. Das Wieso überlasse ich den LANCOM-Entwicklern...

Allgemein erscheint mir dieser SSH-Server als unsicher konfiguriert. Hier wäre ein Abgleich von:

LCOS-Menübaum > Setup > Config > SSH

https://www.lancom-systems.de/docs/LCOS ... _28_4.html

mit den Angaben von BSI TR-02102-4 angebracht:
https://www.bsi.bund.de/DE/Themen/Unter ... _node.html

Zum Beispiel:

Code: Alles auswählen

Setup->Config->SSH->SFTP-Server->In-Betrieb			Nein

Setup->Config->SSH->Cipher-Algorithmen                          aes256-gcm
Setup->Config->SSH->Hostkey-Algorithmen				rsa-sha2-256,rsa-sha2-512
Setup->Config->SSH->MAC-Algorithmen				hmac-sha2-512
Setup->Config->SSH->Max-Hostkey-Laenge				8192
Setup->Config->SSH->Min-Hostkey-Laenge				4096
Setup->Config->SSH->Schluesselaustausch-Algorithmen             curve25519-sha256

[rotwang]

Das da ist Dein Problem:

Code: Alles auswählen

[SSH] 2024/03/18 22:37:26,413
--> peer identifier is 'SSH-2.0-PuTTY_Release_0.80'
--> Writing KEXINIT message:
---> not written successfully
--> could not write initial key exchange record, giving up

Das ist eine Folge der Terrapin-Fixes, die in der 10.42 und 10.50 aufgetreten ist, je nachdem wie viele Algorithmen unter Setup/Config/SSH/Key-Exchange-Algorithms eingeschaltet sind. Durchforste mal die Liste, ob Du davon einen oder zwei nicht brauchst. Das Problem ist nach der SU13 behoben worden, es ist aber noch kein neuerer RU/SU der 10.42 released worden. Bei so alten Firmwaren (die 10.42 ist die älteste LCOS-Version, die überhaupt noch gepflegt wird...) passiert das halt nicht mehr so häufig.

[Dr.Einstein]

Die 10.42 ist EoL, würde mich wundern, wenn da noch ein offizieller Release kommt.

[Hagen2000]

@Killerjoe: Hat wahrscheinlich mit dem eigentlichen Problem nichts zu tun, aber läuft dein Router schon auf Sommerzeit?

[Killerjoe]

Hallo zusammen und vielen Dank für Eure Hilfe!

Wie von GrandDixence und Rotwang vorgeschlagen, lag es an den Schlüssleaustausch-Algorithmen, bzw. genauer gesagt an einem Algorithmus, diffie-hellman-group-exchange-sha1.
Wenn dieser aktiv ist mit SU13, dann funktioniert keine SSH Verbindung zum Router.
Wenn ich nur diesen weg nehme, geht es.
Ich habe nun auch bei den anderen SSH Konfigurationen die unsicheren Varianten deaktiviert, das Problem lag allerdings nur an iffie-hellman-group-exchange-sha1.

@Hagen2000, nein die Sommerzeit läuft noch nicht auf dem Router, wie kommst Du darauf?

Vielen DAnk und viele Grüße
Jochen

[sixty]

@Hagen2000, nein die Sommerzeit läuft noch nicht auf dem Router, wie kommst Du darauf?

Vermutlich hat es ihn gewundert, daß Du am "18. März 2024 21:46" eine Antwort schreibst mit einem Logauszug von "2024/03/18 22:43:06,851".
Es gibt tatsächlich Authentifizierungsmethoden, bei denen eine korrekte Uhrzeit +/- ein paar Minuten erforderlich ist, auf SSH (egal ob mit Paßwort oder Key) trifft das allerdings nicht zu.

[Hagen2000]

Stimmt! Zumal ich in den Abendstunden im Forum die Trace-Meldungen von Killerjoe gelesen habe und dachte "huch, ist das schon spät!". Beim Blick auf die Uhr war es dann aber rund 1h früher. Vielleicht stimmt ja auch die eingestellte Zeitzone nicht?

[Killerjoe]

Danke, das ist mir gar nicht aufgefallen. Aber als ich die Konfiguration durchgegangen bin, hatte ich NTP (wieder) eingeschaltet.
Anscheinend habe ich das letzten Sommer ausgeschaltet und dadurch lief der Router noch auf Sommerzeit