ssh login problem

[Pyrates]

Hallo!

Ich habe einen Root-Server gemietet, auf dem Debian Sarge laeuft, und habe jetzt ein Problem mit dem login per ssh (dasselbe Problem tritt bei Uebertragungen per scp oder sftp auf). Das Problem tritt nur manchmal auf, manchmal funktioniert auch einfach alles, und ich konnte bisher nicht herausfinden, was das beeinflusst ausser dem Zufall.

Folgendes passiert (ab und zu): Ich versuche eine Verbindung per ssh aufzubauen, und werde nach dem Passwort gefragt. Ich gebe es ein, druecke Enter, der Cursor springt in die naechste Zeile.... und dann nichts mehr. Keine Tastatureingaben werden entgegengenommen, es kommt keine Fehlermeldung, es haengt einfach.

Auf der Serverseite kann man sehen, dass ein bisschen was funktioniert hat. Sshd hat geforkt, und auch schon eine bash fuer den user gestartet, der sich einloggen will. Beide kann man natuerlich killen... der user allerdings ist irgendwie noch eingeloggt, auch wenn beide Prozesse beendet sind, das zumindest behauptet "who", und auch die benutzte /dev/pts/* bleibt reserviert.

Am Ende des Postings gebe ich nochmal zwei Auszuege aus dem Log (mit DEBUG1, hoehere Loglevel geben fuer mein Auge auch nicht mehr her) fuer jeweils eine "gute" Session und eine fehlgelaufene (eben wie oben beschriebene).

Das Problem trat erst auf, nachdem ich rssh und/oder scponly installiert und benutzt hatte (d.h. ich hatte bei 2 usern die Shell auf /usr/bin/rssh bzw scponly gesetzt). Allerdings trat/tritt das Problem auch bei usern, die keines von beidem verwendet haben, auf. Ich habe diese inzwischen deinstalliert (mit --purge), aber das Problem bleibt. Beide scheinen auch ansonsten (wenn man es mal mit su versucht) gut zu arbeiten, daher glaube ich irgendwie nicht, dass es daran liegt.

Ich waere wirklich dankbar fuer jeden Hinweis, es finden sich auch keine Fehlermeldungen im ssh-log. Ich gebe auch gerne noch mehr Info raus, was genau wie auf meinem System laeuft (ist ein aktuelles Standard Debian testing, ein paar selbstkompilierte Packete sind installiert, die aber eigentlich nix mit ssh zu tun haben).

Hier jetzt noch die Logauszuege, zuerst von einer Session, die so war, wie sie sein sollte:

Code: Alles auswählen

Mar 29 11:58:06 a15166724 sshd[659]: Connection from ::ffff:128.176.178.42 port 32925
Mar 29 11:58:06 a15166724 sshd[509]: debug1: Forked child 659.
Mar 29 11:58:06 a15166724 sshd[659]: debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p1
Mar 29 11:58:06 a15166724 sshd[659]: debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
Mar 29 11:58:06 a15166724 sshd[659]: debug1: Enabling compatibility mode for protocol 2.0
Mar 29 11:58:06 a15166724 sshd[659]: debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
Mar 29 11:58:06 a15166724 sshd[659]: debug1: PAM: initializing for "root"
Mar 29 11:58:06 a15166724 sshd[659]: debug1: PAM: setting PAM_RHOST to "raeuber32.uni-muenster.de"
Mar 29 11:58:06 a15166724 sshd[659]: debug1: PAM: setting PAM_TTY to "ssh"
Mar 29 11:58:06 a15166724 sshd[659]: Failed none for root from ::ffff:128.176.178.42 port 32925 ssh2
Mar 29 11:58:13 a15166724 sshd[659]: Accepted keyboard-interactive/pam for root from ::ffff:128.176.178.42 port 32925 ssh2
Mar 29 11:58:13 a15166724 sshd[659]: debug1: monitor_child_preauth: root has been authenticated by privileged process
Mar 29 11:58:13 a15166724 sshd[659]: debug1: Entering interactive session for SSH2.
Mar 29 11:58:13 a15166724 sshd[659]: debug1: server_init_dispatch_20
Mar 29 11:58:13 a15166724 sshd[659]: debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
Mar 29 11:58:13 a15166724 sshd[659]: debug1: input_session_request
Mar 29 11:58:13 a15166724 sshd[659]: debug1: channel 0: new [server-session]
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_new: init
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_new: session 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_open: channel 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_open: session 0: link with channel 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: server_input_channel_open: confirm session
Mar 29 11:58:13 a15166724 sshd[659]: debug1: server_input_channel_req: channel 0 request pty-req reply 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_by_channel: session 0 channel 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_input_channel_req: session 0 req pty-req
Mar 29 11:58:13 a15166724 sshd[659]: debug1: Allocating pty.
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_pty_req: session 0 alloc /dev/pts/1
Mar 29 11:58:13 a15166724 sshd[659]: debug1: server_input_channel_req: channel 0 request x11-req reply 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_by_channel: session 0 channel 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_input_channel_req: session 0 req x11-req
Mar 29 11:58:13 a15166724 sshd[659]: debug1: X11 forwarding disabled in server configuration file.
Mar 29 11:58:13 a15166724 sshd[659]: debug1: server_input_channel_req: channel 0 request shell reply 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_by_channel: session 0 channel 0
Mar 29 11:58:13 a15166724 sshd[659]: debug1: session_input_channel_req: session 0 req shell
Mar 29 11:58:13 a15166724 sshd[659]: debug1: PAM: setting PAM_TTY to "/dev/pts/1"
Mar 29 11:58:13 a15166724 sshd[659]: debug1: PAM: establishing credentials
Mar 29 11:58:13 a15166724 sshd[662]: debug1: Setting controlling tty using TIOCSCTTY.
Mar 29 11:58:13 a15166724 sshd[662]: debug1: PAM: reinitializing credentials
Mar 29 11:58:13 a15166724 sshd[662]: debug1: permanently_set_uid: 0/0

Und hier eine Session, bei der das oben erklaerte Problem aufgetreten ist:

Code: Alles auswählen

Mar 30 22:33:15 a15166724 sshd[816]: Connection from ::ffff:217.255.25.47 port 52101
Mar 30 22:33:15 a15166724 sshd[508]: debug1: Forked child 816.
Mar 30 22:33:15 a15166724 sshd[816]: debug1: Client protocol version 2.0; client software version OpenSSH_3.9p1
Mar 30 22:33:15 a15166724 sshd[816]: debug1: match: OpenSSH_3.9p1 pat OpenSSH*
Mar 30 22:33:15 a15166724 sshd[816]: debug1: Enabling compatibility mode for protocol 2.0
Mar 30 22:33:15 a15166724 sshd[816]: debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
Mar 30 22:33:15 a15166724 sshd[816]: debug1: PAM: initializing for "root"
Mar 30 22:33:15 a15166724 sshd[816]: debug1: PAM: setting PAM_RHOST to "pd9ff192f.dip.t-dialin.net"
Mar 30 22:33:15 a15166724 sshd[816]: debug1: PAM: setting PAM_TTY to "ssh"
Mar 30 22:33:15 a15166724 sshd[816]: Failed none for root from ::ffff:217.255.25.47 port 52101 ssh2
Mar 30 22:33:19 a15166724 sshd[816]: Accepted keyboard-interactive/pam for root from ::ffff:217.255.25.47 port 52101 ssh2
Mar 30 22:33:19 a15166724 sshd[816]: debug1: monitor_child_preauth: root has been authenticated by privileged process
Mar 30 22:33:19 a15166724 sshd[816]: debug1: Entering interactive session for SSH2.
Mar 30 22:33:19 a15166724 sshd[816]: debug1: server_init_dispatch_20
Mar 30 22:33:19 a15166724 sshd[816]: debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
Mar 30 22:33:19 a15166724 sshd[816]: debug1: input_session_request
Mar 30 22:33:19 a15166724 sshd[816]: debug1: channel 0: new [server-session]
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_new: init
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_new: session 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_open: channel 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_open: session 0: link with channel 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: server_input_channel_open: confirm session
Mar 30 22:33:19 a15166724 sshd[816]: debug1: server_input_channel_req: channel 0 request pty-req reply 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_by_channel: session 0 channel 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_input_channel_req: session 0 req pty-req
Mar 30 22:33:19 a15166724 sshd[816]: debug1: Allocating pty.
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_pty_req: session 0 alloc /dev/pts/1
Mar 30 22:33:19 a15166724 sshd[816]: debug1: server_input_channel_req: channel 0 request shell reply 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_by_channel: session 0 channel 0
Mar 30 22:33:19 a15166724 sshd[816]: debug1: session_input_channel_req: session 0 req shell
Mar 30 22:33:19 a15166724 sshd[816]: debug1: PAM: setting PAM_TTY to "/dev/pts/1"
Mar 30 22:33:19 a15166724 sshd[816]: debug1: PAM: establishing credentials
Mar 30 22:33:19 a15166724 sshd[819]: debug1: Setting controlling tty using TIOCSCTTY.
Mar 30 22:33:19 a15166724 sshd[819]: debug1: PAM: reinitializing credentials
Mar 30 22:33:19 a15166724 sshd[819]: debug1: permanently_set_uid: 0/0

Danke schonmal fuer jedwede Hilfe.

Cheers
Philipp

[theBrain]

hast Du irgendwo ne Firewall dazwischen?
Auch Personalfirewall ( ich weiß sowas gibts nicht wirklich. Für alle die mich belehren wollen was ne Firewall jetzt wirklich ist) oder sowas Router der irgendwas blockt?

[Pyrates]

Naja, ein Router wohl. Das ipt_nat_ftp modul ist geladen (braucht man fuer sftp), und es laeuft wohl auch iptables. Allerdings wird nix geblockt, nur ein paar bestimmt Ports geforwarded.

Waere auch komisch, wenn's daran laege, weil wie gesagt das Problem nur ab und zu auftritt. Dachtest du an etwas spezielles an der Firewall, was da hinderlich sein koennte? Danke fuer dein Hilfe

Cheers
Philipp

[theBrain]

Du kommst zwar auf Port 22 an aber die kommunikation findet dann ja woanders statt.
Port 32925 scheint zu gehen
[quote]
Mar 29 11:58:13 a15166724 sshd[659]: Accepted keyboard-interactive/pam for root from ::ffff:128.176.178.42 port 32925 ssh2 [/quote]



[quote]Mar 30 22:33:19 a15166724 sshd[816]: Accepted keyboard-interactive/pam for root from ::ffff:217.255.25.47 port 52101 ssh2 [/quote]
Port 52101 nicht.

daher mein Verdacht.

[Pyrates]

Hmm, ok, dann werde ich das mal so drehen, dass mein Rechner ne eigene IP hat, also nix mit Portforwarding oder so sein muss, und probiere das dann aus. Danke fuer den Hinweis!

Cheers
Philipp

[Pyrates]

Nur mal so als follow up, ich habe nix dran getan, das Problem tritt aber nicht mehr auf... weiss auch nicht genau, was da los ist, aber bin wohl zufrieden, dass es wieder funktionert... bis zum naechsten Versuch mit rssh *G*

Cheers
Philipp

[NCoDer]

Und du hast keine Ahnung, wieso es jetzt nicht mehr auftritt? Ich habe das gleiche Problem (ssh hängt, who zeigt root ssh sessions an etc.) und es hat sich bislang leider noch nicht erledigt...

[Pyrates]

Nee, tut mir leid, habe echt keine Ahnung. Habe halt rssh und scponly deinstalliert. Aber da ich es vorher auch nicht immer verwendet habe, waere es seltsam, wenn es daran haengen wuerde...

Cheers
Philipp