SSH-Login über Internet auf heimischen Server

[escimo]

Hallo zusammen,

ich bin ich wohl auch Netzwerk-technisch nicht unterrichtet.

Mein Problem: Auf meinem Server läuft Solaris 10 Update 5 inklusive des SSHD. Eine Anmeldung im heimischen Netzwerk (LAN) funktioniert.

Hingegen eine Anmeldung aus dem Internet mittels PuTTY (Windows XP SP2) wird mit der Meldung "Server unexpectedly closed network connection" quittiert.

Der Port 22 für SSH wurde von mir auf dem Internet-Router (Typ NetGear) mittels Port Forwarding eingerichtet. Ein Telnet auf den DNS-Alias und Port 22 zeigt mir, dass eine Verbindung aufgebaut wird.

Hier noch ein Paar Basis-Informationen bezüglich des Servers.

# netstat -an | grep 22
      *.22                 *.*                0      0 49152      0 LISTEN
192.168.xxx.xxx.22    192.168.xxx.xxx.4568  64167     51 49640      0 ESTABLISHED
      *.22                              *.*                             0      0 49152      0 LISTEN

# svcs -a
STATE          STIME    FMRI
<...>
disabled       11:47:48 svc:/network/ipfilter:default
disabled       11:47:48 svc:/network/rpc/keyserv:default
disabled       11:47:48 svc:/network/rpc/nisplus:default
disabled       11:47:48 svc:/network/nis/client:default
disabled       11:47:48 svc:/network/dns/client:default
disabled       11:47:48 svc:/network/ldap/client:default
<...>
disabled       11:47:49 svc:/network/inetd-upgrade:default
<...>
disabled       11:47:49 svc:/network/routing/legacy-routing:ipv4
disabled       11:47:49 svc:/network/routing/legacy-routing:ipv6
disabled       11:47:49 svc:/network/routing/ndp:default
disabled       11:47:49 svc:/network/routing/rdisc:default
disabled       11:47:49 svc:/network/routing/ripng:default
disabled       11:47:49 svc:/network/ipv6-forwarding:default
disabled       11:47:49 svc:/network/ipv4-forwarding:default
<...>
disabled       11:47:49 svc:/system/consadm:default
<...>
disabled       11:48:05 svc:/network/rpc/meta:default
<...>
disabled       11:48:05 svc:/network/rpc/mdcomm:default
disabled       11:48:05 svc:/network/rpc/metamed:default
disabled       11:48:05 svc:/network/rpc/metamh:default
disabled       11:48:05 svc:/network/rpc/rex:default
<...>
disabled       11:48:05 svc:/network/uucp:default
disabled       11:48:05 svc:/network/ftp:default
<...>
online         11:48:05 svc:/network/ssh:default
<...>
online         13:24:18 svc:/system/console-login:default

Ich habe versucht alle Services, die etwas mit der Netzwerk-Problematik zu tun haben könnten, aufzulisten.

Was übersehe ich? Das hat doch nicht wieder etwas mit NAT (Network Address Translation) zu tun? Wie verhält sich das SSHD-System bei Anfragen über LAN-fremde IP-Adressen auf eigene, privilegierte Ports (unter 1024)?

Über ein Paar Tipps würde ich mich sehr freuen.

Viele Grüße

escimo

PS: In der Regel kann ich mir meistens selbst helfen. Es gibt aber Dinge, die mir immer noch ein großes Rätsel sind. Dazu zählt u.a. die Thematik der Protokolle bei vernetzten Systemen. Nun ja, ich benötige halt Zugriff von extern, da ich ja die Woche über nicht daheim bin. Nur ohne SSH - und AVR (Adv. Video Redirection) mittels JAVA über das iRMC funktioniert auch noch nicht; da beanspruche ich dann den techn. FSC-Support - sind mir leider komplett die Hände gebunden.

[Toktar]

Was steht denn in der sshd.conf? Schließt Du externe IP-Adressen aus oder sind diese erlaubt.
Nattest Du ins LAN hinein, oder routest Du die Pakete nur?

[Padde]

In den Server-Logs sollte sich zumindest ein erster Anhaltspunkt finden. Hilfreicher ist aber meist ein ssh -vvv ... ("verbose debugging output") - da mußt du mal schauen, ob PuTTY das auch kann, oder halt einen "gescheiten" Client verwenden.

Alles andere wäre nur Rumgerate. Zum Beispiel verwendet SSH standardmäßig Reverse DNS, was manchmal zu Problemen führen kann, aber ohne irgendeinen weiteren Anhaltspunkt ist das reine Spekulation.

[escimo]

Was steht denn in der sshd.conf? Schließt Du externe IP-Adressen aus oder sind diese erlaubt.
Nattest Du ins LAN hinein, oder routest Du die Pakete nur?

Hier die derzeitige Konfiguration der /etc/ssh/sshd_config (gestaucht)

Protocol 2
Port 22
ListenAddress ::
AllowTcpForwarding no
GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PrintMotd no
KeepAlive yes
SyslogFacility auth
LogLevel info
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
KeyRegenerationInterval 3600
StrictModes yes
LoginGraceTime 600
MaxAuthTries    6
MaxAuthTriesLog 3
PermitEmptyPasswords no
PasswordAuthentication yes
PAMAuthenticationViaKBDInt yes
PermitRootLogin no
Subsystem       sftp    /usr/lib/ssh/sftp-server
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes

In den Server-Logs sollte sich zumindest ein erster Anhaltspunkt finden. Hilfreicher ist aber meist ein ssh -vvv ... ("verbose debugging output") - da mußt du mal schauen, ob PuTTY das auch kann, oder halt einen "gescheiten" Client verwenden.

Hier etwas Output (Logging von PuTTY):

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.06.02 00:44:16 =~=~=~=~=~=~=~=~=~=~=~=
Event Log: Writing new session log (SSH packets mode) to file: C:\Dokumente und Einstellungen\schaarst\Desktop\putty.log
Event Log: Looking up host "<DynDNS-Host>"
Event Log: Connecting to <ext. IP-Adresse> port 22
Event Log: Failed to connect to <ext. IP-Adresse>: Network error: Connection timed out
Event Log: Network error: Connection timed out

Ist nicht sehr viel. Wo finde ich Logs auf dem Server zum SSHD?

Ich schaue mir erst mal ein Paar Man-Pages an:
# man sshd

SEE ALSO
     login(1), scp(1),  ssh(1),  ssh-add(1),  ssh-agent(1),  ssh-
     keygen(1),    svcs(1),    gkadmin(1M),   kadmin(1M),   sftp-
     server(1M),    ssh-keysign(1M),    svcadm(1M),    pam(3PAM),
     rhosts(4),   ssh_config(4),  sshd_config(4),  attributes(5),
     gss_auth_rules(5), kerberos(5), pam_roles(5), smf(5)

Grüße
escimo

[Ten Little Indyans]

Hier etwas Output (Logging von PuTTY):

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.06.02 00:44:16 =~=~=~=~=~=~=~=~=~=~=~=
Event Log: Writing new session log (SSH packets mode) to file: C:\Dokumente und Einstellungen\schaarst\Desktop\putty.log
Event Log: Looking up host "<DynDNS-Host>"
Event Log: Connecting to <ext. IP-Adresse> port 22
Event Log: Failed to connect to <ext. IP-Adresse>: Network error: Connection timed out
Event Log: Network error: Connection timed out

Ist nicht sehr viel. Wo finde ich Logs auf dem Server zum SSHD?

Das ist jetzt aber ein anderer Fehler als der ursprünglich genannte ("Server unexpectedly closed network connection").

Bei einem Timeout gehe ich erstmal davon aus das die Verbindung in mindestens eine Richtung gar nicht durchlässig ist, also z.B. Dein Port Forwarding nicht richtig tut. Entweder die SSH-Pakete vom Client kommen beim Server gar nicht an, oder dessen Antwort findet nicht den Weg zum Client. Da könnte jetzt das Log auf dem Server helfen das Problem einzugrenzen. Der SSHD schickt seine Meldungen an den syslog:

SyslogFacility auth
LogLevel info

Wo diese auth.info Meldungen abgelegt werden hängt von Deiner Syslog-Konfiguration ab. Ich würde erstmal in den Dateien unter /var/log und /var/adm danach suchen.

[signal_15]

ssh funktioniert bei dir aber generell!? putty von einem anderen rechner im selben subnetz funktioniert!? dann kann ich mir nicht vorstellen warum es nicht gehen sollte. ausser: der netgear ist nicht richtig konfiguriert. hast du das routing/nat mit einem anderen port wie z.b. telnet/http/ftp ausprobiert?

ct,

[escimo]

Hi zusammen,

also um Missverständnissen aus dem Weg zu räumen: Ich habe eine SSH-Sitzung über das Internet auf mein NAS (Port 22) gestartet, dann über den iRMC den Server hochgefahren und mich dann mittels einer weiteren SSH-Sitzung auf den Server angemeldet. Damit schließe ich den Router als Fehlerquelle aus. Was bleibt ist der Server, der noch total nackig ist. Eventuell fehlen dann noch einige Konfigurationen, die im Vorfeld gemacht werden müssen (Zertifikate, Routen o.ä.) ? 

Eine Default-Route zwischen den zwei Netzwerkadaptern exisitiert z.B. noch nicht. Aber das kann es eigentlich nicht sein.

[signal_15]

...und mich dann mittels einer weiteren SSH-Sitzung auf den Server angemeldet.

von wo aus hast du die 'weitere ssh sitzung' auf den server aufgebaut? von deinem nas aus? dan geht doch dein ssh. wo liegt dann das problem?

ct,

[signal_15]

ach, und noch ein tip. ich habe mittels nat/pat den ssh port auf meinem router nicht auf'm port 22 laufen sondern einem anderen. irgendwann ist es mir einfach zu bunt geworden. es gab tage da hatte ich in den log dateien mehr als 10000 (in worten: zehntausend) eintraege bezueglich 'Login failed'. es gibt genug leute die nichts zu tun haben. um sich die zeit zu vertreiben werden portscans gefahren und alles was nach nem login riecht mittels brute force attacken (wie sagt man auf neudeutsch) gepentested. einfach einen unaufaelligen port waehlen, wie z.b. 19/tcp/chargen oder 70/tcp/gopher, und somit das /var/log/auth klein halten.

ct,

[escimo]

von wo aus hast du die 'weitere ssh sitzung' auf den server aufgebaut? von deinem nas aus? dan geht doch dein ssh. wo liegt dann das problem?

Um das auf andere Art zu darzustellen:

Fall 1: SSH-Sitzung aus Internet auf das NAS
Router-Einstellung: Port Forwarding von Port 22 auf <IP-NAS>
Ergebnis: Verbindung möglich

Fall 2: SSH-Sitzung von NAS im LAN auf SERVER
Router-Einstellung: irrelevant, da selbes Netz
Ergebnis: Verbindung möglich

Fall 3: SSH-Sitzung aus Internet auf den SERVER
Router-Einstellung: Port Forwarding von Port 22 auf <IP-NAS> löschen, dann
neues Port Forwarding von Port 22 auf <IP-SERVER>
Ergebnis: Verbindung nicht möglich

Die Fehlerquelle ist der Server. Im folgenden setze ich jetzt den Log-Level auf "debug". Anschließend werde ich versuchen mittels snoop die Pakete auf die IP des Routers untersuchen.

Hinweis: Der Router besitzt einen integrierten 4fach-Hub.

Gruß
escimo

[Toktar]

In der sshd_config steht:

Protocol 2
Port 22
ListenAddress ::

Das ist eine IPv6 Adresse. Lauscht der Dienst auch noch auf einer IPv4 Adresse. Ich kenne jetzt die Provider nicht so genau, aber das IPv6 im Internet geroutet wird, ist mir fremd.

Ein ListenAdress 0.0.0.0 könnte helfen.
Mit netstat nochmal überprüfen, auf welchen Protokollen die Shell dann lauscht.

[signal_15]

jetza sama beinand. das mit snoop ist eine gute idee und waere natuerlich das naechste was ich dir geraten haette (wer's glaubt.-) spass bei seite. aber warum willst du die adresse des routers als filter benutzen? das wird dir rein gar nichts bringen. du musst den filter auf eine der ip adressen setzen die an der verbindung teil nehmen. zum einen ist das dein server, mal angenommen mit der 172.16.10.5, und einem client im internet der die ssh verbindung aufbauen will und z.b. die adresse 213.45.166.176 hat. dein router hat in diesem beispiel die 172.16.10.1.

probiers mal aus. ein 'snoop from or to 172.16.10.1' wird nichts bringen. er ist ja auch nicht an der verbindung beteiligt. ja schon, der verkehr geht doch ueber ihn!? das schon. aber er ist nicht an ihn gerichtet und kommt auch nicht von ihm.

ein 'snoop from or to 213.45.166.176' wird da schon mehr hervor bringen. und wenn du dir die packete genau ansiehst, dann wirst du sehen in welcher weise dein router bei der verbindung 'hilft'. die packete die von deinem server an die 213.45.166.176 rausgehen habe welche destination-mac? richtig, die deines routers. der ip-stack erkennt ja, dass packete fuer 213.45.166.176 nicht direkt zugestellt werden koennen und gibt das packet an deinen router. nicht aber weil im dem packet die destination-ip deines routers steht sonder die destination-mac.

ct,

[escimo]

Ich habe es doch gewusst!

Nachdem ich beim NAS die Default-Route gesehen habe bin ich wieder stutzig geworden, und siehe da... 

Eine Default-Route zwischen den zwei Netzwerkadaptern exisitiert z.B. noch nicht. Aber das kann es eigentlich nicht sein.

Das war es aber leider doch! Der Server wusste einfach nicht, auf welchem Wege er die Pakete an den "Requester" zurückschicken sollte. Also sollte man ihm das auch sagen. Natürlich wieder über den Router.

# route add default 192.168.0.100
# netstat -r

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.0.100        UG        1          0
<...>
localhost            localhost            UH        1          0 lo0

So am Rande: snoop ist nicht installiert. So eine Mist aber auch. Das muss ich mal noch nachholen. 

Mit dem Thema SSH werde ich mich eingehender beschäftigen. Ist nicht zu unterschätzen.

Grüße
escimo

PS: Auf dieser Seite unter Punkt 5 kann man es auch nochmal nachlesen.

[signal_15]

an dem eintrag "ListenAddress ::" kanns nicht liegen. erstens steht in der datei ueber dem eintrag "# IPv4 & IPv6" und gilt somit fuer beide versionen, und zweitens steht bei mir das selbe drinnen und es funktioniert so.

andere frage: nicht dass ich dich fuer bloed halte, aber steht in der /etc/defaultrouter auch die ip deines routers? vielleicht ein tippfehler!?

wie sieht es mit der /etc/netmasks aus? ist die maske fuer dein internes netz richtig angegeben?

ct,

[signal_15]

also doch.-) war ich mit'm schreiben zu langsam.

ct,