SSH hinter Firewall funktioniert nur teilweise

#1 Hallo,

ich benutze Suse 9 und diesen Rechner als SSH Server und
will von außen z.B. mit Putty mich bei dem Rechner einloggen.
Der Linux Rechner ist hinter einem DSL Router mit Firewall.
Den Port 22 habe ich freigegeben.
Wenn ich nun die Verbindung aufbaue meldet sich der Linux
Rechner auch schön mit Login und Password. Danach bleibt
alles stehen. Die Sache funktioniert jedoch im internen Netzwerk ohne
Probleme. Nun habe ich gedacht ich schaue mal ins messages log-file und
hab dort gefunden : password accepted from : 80.234.34.xx port 57888 ssh2.
Ich denke da ist das Problem. Der Port 57888 ist natürlich nicht freigegeben.
Nun meine Frage : Es ist bei jedem Versuch ein anderer Port. Woher kommt dieser
Port. Vom Linux-Rechner(server) also vom ssh(d) oder vom client ? Wo wird der Bereich festgelegt ? und kann man den server oder den client zwingen immer den gleichen Port zu benutzen ? Ich möchte nicht alle Port von 56000-65000 freigeben !

Vielen Dank im Vorraus.

#2 das ist der Port von Deinem Client, der dynamisch generiert wird.
hast Du den Port 22 nur freigegeben oder auch "geforwardet"?
den Server Port kannst Du beliebig festlegen, sollte allerdings dann im nicht reservierten Bereich sein (also oberhalb 1024), da es sonst evtl. zu Komplikationen kommt.

#3 Hab im sshd_config den port 22 genommen. Im Router
hab ich Port 22 freigegeben und zum Port 22 des Servers geforwardet.
Der Connect funktioniert ja. Nur bleibt nach dem Login und Passwort
(egal welcher benutzer) alles stehen und nix geht mehr.
Habs mit Windows und Putty probiert und mit Linux. Jedes mal
das gleiche Ergebnis.
Im Messages (log) steht dann die Meldung dass das PW korrekt war
und die Verbindung hergestellt wurde :

Oct 29 10:25:31 server sshd[8865]: Accepted password for root from ::ffff:82.82.224.1xx port 58838 ssh2

Ich denke den Port muss ich auch freigeben (routen) nur ist das
schwierig wenns immer ein anderer ist.
Im internen Netzwerk funktioniert SSH(d) einwandfrei von allen Rechnern.
Deswegen denke ich das es an der Firewall liegt.
*grübel*

#4 @mercur

SSH hat nur einen Port und das ist tcp/22.
Der Port in deiner Meldung ist lediglich der client Port, muss natürlich dynamisch sein und hat nichts mit deinem Server am Hut. Vielleicht willst du mal ssh mit -v (verbose mode) nutzen oder tcpdump - eventuell hilft das ja. Eins ist mit sicherheit klar, wenn du eine Login Aufforderung bekommst dann ist der Port auch geforwarded und dein Router ist somit kein Hindernis mehr. Interessant ist jetzt nur noch was danach passiert.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#5 Hallo,

ich habe das selbe Problem, so scheint es zumindest.

Ich kann mich mit ssh einloggen, aber sobald Daten den Besitzer wechseln bricht die Verbindung zusammen. Mir ist aufgefallen, dass ich eine gewisse Datenmenge (weniger als 2048 Byte) immer übermitteln kann. Danach ist schluss.

Ich habe meine Firewall (Port 22 freigegeben) mal überbrückt, also meine Mühle direkt ans Internet angeschlossen. Damit funktioniert alles prima.

Zu beachten ist vielleich, dass ich eigentlich überhaupt nichts auf der Firewall freigeben müsste, da der Request ja von innen nach aussen geht. Diese Zugriffe sind (abgesehen von Reverse-Proxys) ja immer offen.

Das Phänomän tritt aber in beide Richtungen auf. Gleiche Effekte habe ich auch bei der Übertragung via FTP.

Über einen Tipp bin ich sehr dankbar.

Gruss Michael

#6 Hallo

Ich habe bei mir das Problem lösen können:

Die MTU (Packetgrösse) war bei mir auf das maximal erlaubte (1492 Byte) eingestellt. Ich habe den Wert mal testweise auf 1350 herunter gesetzt. Jetzt funktioniert alles.

MTU auf 1492 ist theoretisch Korrekt (1500 laut RCF, 8 benötigt aber der Header) aus irgendwelchen Gründen gabs bei mir damit zumindest Probleme.


Hruss Michael.

#7 @m1

es kann einen kommunikationsknoten in dem netz geben, der diese MTU nicht unterstützt und es somit zu solchen problemen kommt

greez

#8 @m1:

Hast du auf beiden beteiligten Rechnern die MTU herabgesetzt ?
Ich habs auf dem Server auf 1350 gesetzt und daheim bei 1492 gelassen
und nach dem Login und Passwort bleibt SSH immernoch hängen.

Ich werde es zuhause mal anstatt mit Putty (WinXP) mit Linux SSH probieren und -v. Mal sehen was dabei rauskommt.

@Emba:

Sonst noch eine Ahnung an was es liegen könnte. Wie gesagt im internen Firmennetzwerk funktioniert alles wunderbar. Wenn ich von außen mit Putty (WINXP) rein will, kommt ganz normal login und passwort und danach hängt alles.
In der Log datei aufm Linux Server steht nichts aussergewöhnliches.

#9 also der ssh client ist eine sehr gute idee zusammen mit dem schalter -vvv

ich hatte auch schon einige probleme mit putty und solchen hängern
manchmal lag es am DNS, mal am interactive keyboard mode von putty usw....mit dem ssh client hatte ich noch nie probs

greez

#10 Ein Bekannter von mir hat es schon von außen mit SSH probiert aber hat
das gleiche Problem : Es hängt nach der Eingabe des Passworts.

Laut /var/log/messages wurde die Verbindung erfolgreich hergestellt !

#11 klappt es denn mit pub-key?

greez

#12 Hier mal das Ergebnis von ssh -vvv bis zum Hänger !
Es hängt auch mit linux !

OpenSSH_3.8.1p1 Debian 1:3.8.1p1-4, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: /etc/ssh/ssh_config line 33: Deprecated option "RhostsAuthentication"
debug1: /etc/ssh/ssh_config line 37: Deprecated option "FallBackToRsh"
debug1: /etc/ssh/ssh_config line 38: Deprecated option "UseRsh"
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxxxx [80.xxx.xx.xxx] port 22.
debug1: Connection established.
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 1.99, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian 1:3.8.1p1-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 129/256
debug2: bits set: 537/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host mercur-suedlogistik.ath.cx
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host mercur-suedlogistik.ath.cx
The authenticity of host 'xxxx (.xxx.xx.xxx)' can't be established.
RSA key fingerprint is 9a:80:39:b2:f6:b9:3e:04:ec:bf:f8:7f:07:94:6b:28.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxxxx, 80.xxx.xx.xxx' (RSA) to the list of known hosts.
debug2: bits set: 493/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@xxxxxx's password:
debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug2: channel 0: request pty-req
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 0
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: x11_get_proto: /usr/bin/X11/xauth list :0.0 . 2>/dev/null
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req
debug2: channel 0: request shell
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768 <<< HÄNGT !

#13 wie ist der genaue konsolenbefehl?
versuchst du x-forwarding?

greez

#14 Eigentlich nicht bzw. keine Ahnung. Ich bin
in Sachen Linux bzw. ssh mit Linux nicht gerade
der Fachmann. Ich denke es muss am Server liegen. Denn
ein Bekannter der von daheim aus viel mit SSH (linux)
arbeitet kommt auch nicht rein bzw. bei dem bleibts
auch nach dem PW hängen, wenn er versucht bei uns
ins Netzwerk zu kommen.

Ich kann von zuhause aus auch auf andere Rechner mit ssh
zugreifen nur bei uns in der Firma nicht. Ich denke es liegt an
der sshd config. ich hab nur keine Ahnung davon

#15 dann paste doch mal die config

greez