ssh auf vdr von aussen klappt nicht

mini · 4. August 2007

Hallo!

Innerhalb meines lokalen Netzes kann ich per ssh auf den (c't)-vdr zugreifen. Versuche ich dies von aussen (entsprechendes Portforwarding für Port 22 ist auf dem Router eingerichtet) so klappt das nicht.

Vom externen client chet (217.160.185.211):

Code

chet:~ # ssh root@213.39.131.12
root@213.39.131.12's password: *****

Dann bekomme ich in auth.log auf dem vdr:

Code

Aug  4 09:30:43 vdr sshd[2730]: Accepted password for root from 217.160.185.211 port 49105 ssh2
Aug  4 09:30:43 vdr sshd[2732]: (pam_unix) session opened for user root by root(uid=0)

Das Login klappt also scheinbar, trotzdem passiert nach der Password-Eingabe nichts mehr am client.

Weiss jemand Rat? Danke!

VG,
Marcus

sparkie · 4. August 2007

du kannst evtl. mal versuchen mit

Code

ssh -v -x root@213.39.131.12

mehr Infos darueber zu erhalten, ab wann es auf der Clientseite haengt. X forwarding wuerde ich zum Test abschalten.

mini · 4. August 2007

Code

chet:~ # ssh -v -x root@213.39.131.12
OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 213.39.131.12 [213.39.131.12] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9
debug1: match: OpenSSH_4.3p2 Debian-9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '213.39.131.12' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
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: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@213.39.131.12's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = POSIX
debug1: Sending env LC_CTYPE = en_US.UTF-8

Alles anzeigen

Danach herrscht Stille.

VG,
Marcus

wirbel · 4. August 2007

So wie sich das liest ist der Fehler nicht auf der vdr Seite.

mini · 4. August 2007

Ich hab das von aussen über den ssh Befehl unter Linux und über putty unter Windows aus verschiedenen Netzwerken probiert, mit dem selben Ergebnis, also schliesse ich ein Problem auf client-Seite eigentlich auch aus.

Kann's noch am Router liegen? Das Portforwarding auf den vdradmin klappt auch von aussen. (Aber das will ich ja gerade mit einem ssl-Tunnel umgehen...)
Die Verbindung und die Authetifizierung klappt ja auch... Hmm... Braucht es noch weitere offene bzw. weitergeleitete ports auf dem Router?

Marcus

wirbel · 4. August 2007

Soweit ich weiß die 22. Versuch doch mal n Crossover Kabel oder ein Hub statt Router.

sparkie · 4. August 2007

kannst du evtl. mal testweise das .profile oder .bash_profile auf der Serverseite (also VDR Seite) umbenennen, so das es nicht gefunden wird? Ist im .profile vielleicht ein Aufruf, der die Probleme verursacht?

Wenn ich testweise 'nen 'sleep 30' in mein .profile einbaue bekomme den gleichen Debug Output wie du - geht genau bis zum 'debug1: Sending environment.' dann ist fuer 30s Schluss.

mini · 4. August 2007

Wenn ich die beiden Dateien umbenennen, ändert sich nichts.

/root/.profile:

Code

# ~/.profile: executed by Bourne-compatible login shells.


if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi


mesg n

/root/.bashrc:

Code

# ~/.bashrc: executed by bash(1) for non-login shells.


export PS1='\h:\w\$ '
umask 022

VG,
Marcus

knebb · 4. August 2007

Zitat

Original von mini
Danach herrscht Stille.

Wie lange wartest Du?

Des weiteren solltest Du das debugging auch auf der Serverseite mal einschalten./etc/sshd/ssd_config

Code

LogLevel DEBUG

Und den Neustart des sshd nicht vergessen.

Lokal geht es einwandfrei?

Evtl. mal ein tcpdump auf dem Server mitlaufen lassen.

foobar42 · 4. August 2007

Klingt so, als sperre irgendwer (firewall/router) die Verbindung von innen nach außen).

EDIT: Ich würde auch mal auf 'nem Port > 1024 den connect versuchen.

knebb · 4. August 2007

Zitat

Original von foobar42
Klingt so, als sperre irgendwer (firewall/router) die Verbindung von innen nach außen).

Noe.
Das laeuft alles innerhalb der TCP-Verbindung ab. D.h. wenn eine Firewall da Pakete blockieren wuerde, kaeme es erst garnicht soweit. Ich kenne auch keine Firewall, die auf Applikationsebene innerhalb von ssh filtert

foobar42 · 4. August 2007

Wer weiß, wie dieser router agiert. Portforwarding z.B. 1111 auf 22 (aber nur in einer Richtung); vielleicht muss der entsprechend konfiguriert werden, dass er beides zulässt.

knebb · 4. August 2007

Zitat

Original von foobar42
Wer weiß, wie dieser router agiert.

Ok, Du hast gewonnen

Zitat

Portforwarding z.B. 1111 auf 22 (aber nur in einer Richtung); vielleicht muss der entsprechend konfiguriert werden, dass er beides zulässt.

[Frauenlogik ON: aber trotzdem!]
Kann nicht sein, da die erste Kommunikation bereits erfolgreich durchlaeuft. Also ist mit auf TCP/IP Schiene wohl alles ok.

Den tcpdump moechte ich nur sehen, um zu pruefen, ob der VDR-ssh weitere Verbindungen aufbaut (z.B. NIS oder identd).

ssh auf vdr von aussen klappt nicht

Jetzt mitmachen!

Teilen