Lancom L-54ag ssh Zugang, aber wie ?

[Nils]

Hallo,

ich bin im Besitz von zwei Lancom L-54ag Geräten. (LCOS 5.02)
HTTPS-Login klappt prima, aber vom gleichen Rechner aus geht das ssh-Login nicht. Port ist offen. Passwort stimmt auch. Lediglich die Meldung: Connection to xxx.xxx.xxx.xxx closed kommt. Das ist natürlich nicht so prima.
Verwendete ssh-Version ist übrigens (ssh -V): OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a.
Mit putty kann ich es leider nicht testen, da hier nirgends ein Windows Rechner zur Verfügung steht.

Mit freundlichem Gruß,
Nils

[alf29]

Moin,

hier gegen ein 3050 tut's:

OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004

Eventuell probiert Deine SSH-Version irgendwelche Sachen, die im SSH-
Server des LANCOM nicht implementiert sind.

Gruß Alfred

[Nils]

Morgen,
danke für die schnelle Antwort.

Folgende Version funktioniert übrigens auch
(ssh -V) OpenSSH_4.2p1, OpenSSL 0.9.7e
Sollte also ein Problem mit der 0.9.8er sein. Vielleicht kann man das in der Firmware in Zukunft fixen ?
Zumindest habe ich aber nun einen Rechner mit dem es geht.

Gruß,
Nils

[alf29]

Sollte also ein Problem mit der 0.9.8er sein. Vielleicht kann man das in der Firmware in Zukunft fixen ?

Schwer zu sagen, dazu müßte ich erstmal ein System mit so einer SSH hier haben.
Die Abhängigkeit von der OpenSSL-Version wundert mich etwas, die stellt eigentlich
nur die Krypto-Algorithmen zur Verfügung, und wenn da etwas klemmen würde,
kämst Du gar nicht bis zur Paßwortabfrage...

Gruß Alfred

[alf29]

Hallo Nils,

ich habe mir jetzt mal schnell auf meinem Debian-System eine OpenSSH
gebaut, die sich so meldet:

OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005

...und das funktioniert problemlos. Eventuell hast Du bei den ersten
Connect-Versuchen vergessen, den Benutzernamen anzugeben - also
z.B. ein 'ssh root@...', wenn keine weiteren Admins konfiguriert sind.
Dann könnte das LANCOM in die Login-Sperre gelaufen werden, die
per Default nach 5 Fehlversuchen aktiv wird. Ein Close direkt nach
der Eingabe des Paßworts (eventuell noch garniert mit einem
'service not available') wäre dann die Reaktion.

Gruß Alfred

[Nils]

Hallo Alfred,
hatte schon gehofft es sei die Lösung, da ich tatsälich anfangs den Benutzernamen nicht angegeben hab. Das System bei dem es bei mir nicht geht, ist tatsächlich ein debian (etch). Exakt die gleiche Version wie deine. Bei meinem Gentoo klappt es.

Das ist mein Output von OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 : (ab der Passwort Zeile)
root@XXX.XXX.XXX.XXX's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug1: Sending environment.
debug1: Sending env LANG = de_DE@euro
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 65536 rmax 16384
debug2: channel 0: rcvd close
debug2: channel 0: output open -> drain
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
Connection to XXX.XXX.XXX.XXX closed.
debug1: Transferred: stdin 0, stdout 0, stderr 38 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2811.9
debug1: Exit status -1

Vielleicht hast du eine Idee ? Gibt es eine Gerätinterne Logdatei für diesen speziellen Fall ?

Gruß,
Nils

[Nils]

--kleine Ergänzung--
Ich habe gerade die Loginsperre ausprobiert, diese meldet sich direkt mit:
Received disconnect from XXX.XXX.XXX.XXX: 7: Service not available.

[alf29]

Moin,

so wie das aussieht, ist der komplette SSH-Verbindungsaufbau inkl. Anfrage einer
der Shell (was beim LANCOM dem Aufbau einer interaktiven Kommandozeilensitzung
entspricht) durchgelaufen, aber das RmConf-Modul will aus irgendwelchen
Gründen auf dieser Verbindung keine Sitzung öffnen (direkter Close). Warum
und wieso, könnte man nur herausfinden, wenn ich so eine Gegenstelle hier
hätte - die habe ich aber leider nicht. Etch ist mir ehrlich gesagt noch zu wacklig
zum Benutzen...

Gruß Alfred

[alf29]

Hallo Nils,

ich habe das bei mir auch mal mit Debug-Infos laufen lassen. Der
einzige Unterschied, den ich sehe, ist daß kein Environment
übermittelt wird. Glaube zwar nicht, daß es daran liegen kann,
ich schaue aber morgen mal nach. Meine SSH habe ich bisher
nicht dazu überreden können, Environment-Variablen zu schicken

Gruß Alfred

[Nils]

Hallo Alfred,
da hast du mir direkt die Lösung verraten. Die Firmware kommt tatsächlich nicht mit der environment zurecht, d.h. im Klartext, wenn man vorher "unset LANG" durchführt und sich danach mit ssh verbindet, geht es!!

Gruß,
Nils

[alf29]

Moin,

hm, ja gut, jetzt muß ich nur noch rausfinden, wieso meine ssh hier $LANG nicht
übermitteln will...dann kann ich mich dran machen, das Problem zu suchen...

Gruß Alfred

[Nils]

Hallo Alfred,
hast du schon versucht in der /etc/ssh/ssh_config die Zeile SendEnv LANG LC_*
hinzuzufügen?
Wie die bei mir dareingerutscht ist, weiß ich nicht, aber scheinbar ist das ziemlich verantwortlich dafür. Danach noch exporten und es müßte gehen.
Gruß,
Nils

[alf29]

Hallo Nils,

ich hatte's über $HOME/.ssh/environment versucht, was
nicht so recht klappen wollte.

In ter Tat versucht Deine SSH da Environment-Variablen
zu übermitteln, was gegen ein LANCOM fehlschlagen muß,
weil die LANCOM-CLI einfach keine Environment-Variablen
in diesem Sinne hat (es gibt zwar welche, aber die sind
global und nicht pro Sitzung). Deshalb lehnt das LANCOM
den Request ab...

Ich kann diesen Request auf 'ignorieren' stellen. Das
Problem ist aber auch, daß die OpenSSH sämtliche
ChannelRequests ohne Anfrage auf Fehlercodes nach
dem Motto 'Augen zu und durch' verschickt...

Gruß Alfred