SSH mit 1823

[jhilgers]

Hi,

seit der Firmware 7.6 RC1 komme ich nicht mehr per SSH (intern & extern) auf das Lancom 1823. Komischerweise mit mein Lancom 1511 funktioniert es noch weiterhin.

Bekomme die Meldung: ssh_exchange_identification: read: Connection reset by peer

Woran kann das liegen? Kann ich das irgendwo im trace sehen?

Gruss
Jochen

[alf29]

Moin,

funktioniert bei mir auf einem 1823 ohne Probleme. Welchen SSH-Client verwendest Du?
Hat das Gerät schon genügend Entropie erzeugt (ein 'show random' zeigt an, ob der Generator
schon geseedet wurde oder nicht)?

Einen SSH-Trace im LANCOM gibt es nicht. Wenn Du eine OpenSSH benutzt, kannst Du dort ein
'-v' für Debug-Ausgaben setzen.

Gruß Alfred

[jhilgers]

Hi Alfred,

ich benutze das ssh von MacOS (also openSSH_5.1p1).
Wenn ich -v als Parameter nutze, bekomme ich folgende Ausgabe:

imacjh:~ jhilgers$ ssh -v 10.0.1.1
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 10.0.1.1 [10.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /Users/jhilgers/.ssh/identity type -1
debug1: identity file /Users/jhilgers/.ssh/id_rsa type -1
debug1: identity file /Users/jhilgers/.ssh/id_dsa type -1
ssh_exchange_identification: read: Connection reset by peer

Wenn ich danach show random auf dem Lancom ausführe, bekomme ich nur Random generator seeded from persistent RAM.
Currently saving gathered entropy to nowhere.

Gruss
Jochen

[jhilgers]

Komme zur Zeit nur per Telnet auf das Gerät.
Komischerweise komme ich kurz nach einem Neustart des Lancom auf das Lancom auch per SSH drauf...

Gruss
Jochen

[LoUiS]

Hi,

schau doch mal unter "/Status/Config", gibts da irgendwelche Login Fehler, Sperren oder Rejects?


Ciao
LoUiS

[alf29]

Moin,

so wie die Debug-Ausgabe aussieht, kommt gerade noch die unterliegende TCP-Verbindung zustande,
aber schon das allererste Paket der SSH-Aushandlung wird nicht ausgetauscht - da ginge es in etwa
so weiter:

Code: Alles auswählen

debug1: Remote protocol version 2.0, remote software version lancom
debug1: no match: lancom
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9etch2

Der Entropiegenerator ist auch eingerichtet und eine Login-Sperre dürfte erst deutlich später greifen.

Am plausibelsten wäre m.E. irgendein Resourcenengpaß, derentwegen der SSH-Stack den
Verbindungsaufbau sofort wieder abbricht. Ein 'sho mem' in beidne Fällen (geht bzw. geht nicht)
könnte da einen Hinweise geben.

Gruß Alfred

[jhilgers]

Hi,

unter /Status/Config gibt es keine Neuen Login Fehler, Sperren oder Rejects. Da passiert nichts, wenn ich per SSH auf das Gerät gehen möchte.

Show mem zeigt mir zur Zeit (wo es nicht geht):
> sho mem

Total: 26.9 MBytes
Status : Blocks Big Small Total
-------------------------------------------------------
USED : 14328 5.8 MBytes 64 Bytes 16.7 MBytes
FREE : 1431 10.0 MBytes 64 Bytes 10.2 MBytes

Jetzt starte ich den Lancom neu und ssh funktioniert:
> show mem

Total: 26.9 MBytes
Status : Blocks Big Small Total
-------------------------------------------------------
USED : 12590 5.8 MBytes 64 Bytes 15.3 MBytes
FREE : 16 11.5 MBytes 64 Bytes 11.6 MBytes

Gruss
Jochen

[alf29]

Moin,

Hm, 10 MByte ist immer noch mehr als genug für eine SSH-Session...ich habe selber mal
genau diese Version gebaut (allerings unter Linux, ich habe keinen Mac), und das sieht
normal aus:

Code: Alles auswählen

OpenSSH_5.1p1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /home/alfred/.ssh/config
debug1: Applying options for *
debug1: Connecting to 192.168.11.144 [192.168.11.144] port 22.
debug1: Connection established.
debug1: identity file /home/alfred/.ssh/identity type -1
debug1: identity file /home/alfred/.ssh/id_rsa type 1
debug1: identity file /home/alfred/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version lancom
debug1: no match: lancom
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host '192.168.11.144' is known and matches the RSA host key.
debug1: Found key in /home/alfred/.ssh/known_hosts:37
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/alfred/.ssh/identity
debug1: Offering public key: /home/alfred/.ssh/id_rsa
debug1: Authentications that can continue: password,publickey
debug1: Offering public key: /home/alfred/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.


#
| LANCOM 1823 VoIP (Annex B)
| Ver. 7.60.0000RC100 / 28.09.2008 / 6.26/E74.02.50.2-PM
| SN.  000000000000
| Copyright (c) LANCOM Systems

lc1823n, Connection No.: 002 (LAN)


root@lc1823n:/

ohne Nachstellmöglichkeit sehe ich da leider erstmal keinen weiteren Ansatz. auß er daß
jetz exzessiv Debug-Firmwaren hin- und herwandern. Kann man ungefähr feststellen,
ab wann der SSH-Zugang nicht mehr funktioniert? Z.B. nach Aufbau einer WAN- oder
VPN-Verbindung oder nach einer VoIP-Verbindung?

Gruß Alfred

[jhilgers]

Hi Alfred,

das liegt meines Wissens nicht am SSH-Client. Unter Linux hatte ich die selben Probleme.

Seit eben funktioniert noch das SSH. Zwei Anrufe waren zwischenzeitlich und ich habe eben mal beide WAN-Verbindungen manuell getrennt. So sieht es aus, wenn es funktioniert:

Code: Alles auswählen

OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 10.0.1.1 [10.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /Users/jhilgers/.ssh/identity type -1
debug1: identity file /Users/jhilgers/.ssh/id_rsa type -1
debug1: identity file /Users/jhilgers/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version lancom
debug1: no match: lancom
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host '10.0.1.1' is known and matches the RSA host key.
debug1: Found key in /Users/jhilgers/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/jhilgers/.ssh/identity
debug1: Trying private key: /Users/jhilgers/.ssh/id_rsa
debug1: Trying private key: /Users/jhilgers/.ssh/id_dsa
debug1: Next authentication method: password
jhilgers@10.0.1.1's password: 

Werde mal ein Auge drauf werfen, wann ungefähr der Fehler auftritt.

Gruss
Jochen

[rbreuer]

Vielleicht hilft im Fehlerfall auch die Angabe von mehr als einem v beim ssh-Aufruf bei der Analyse. Bis zu drei sind möglich (ssh -vvv).

Gruß, Rolf

[jhilgers]

Hi Rolf,

leider nicht. Ergibt die gleiche Ausgabe.

Gruss
Jochen

[alf29]

Moin,

Ein Wireshark-Trace *könnte* vielleicht noch ein paar Erkenntnisse bringen, ich fürchte, nach
der bisherigen Beschreibung wird man aber nicht viel mehr als ein SYN/SYN-ACK/ACK mit
direkt darauf folgendem Reset sehen...

Fruß Alfred