sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Solaris/x86 und OpenSolaris => Thema gestartet von: escimo am 01. Juni 2008, 20:30:28
-
Hallo zusammen,
ich bin ich wohl auch Netzwerk-technisch nicht unterrichtet.
Mein Problem: Auf meinem Server (http://www.sonnenblen.de/sun_x86/solaris_10_auf_fsc_primergy_tx120_mit_intel_3000er_chipsatz-t4941.0.html;msg31374#msg31374) 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.
-
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?
-
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.
-
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
-
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.
-
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,
-
Hi zusammen,
also um Missverständnissen aus dem Weg zu räumen: Ich habe eine SSH-Sitzung über das Internet auf mein NAS (http://) (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.
-
...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,
-
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,
-
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
-
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.
-
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,
-
Ich habe es doch gewusst!
Nachdem ich beim NAS die Default-Route gesehen habe bin ich wieder stutzig geworden, und siehe da... :D
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 (http://www.adminschoice.com/docs/solaris_network_configuration.html#Router%20Configuration) kann man es auch nochmal nachlesen. ;)
-
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,
-
also doch.-) war ich mit'm schreiben zu langsam.
ct,
-
Die /etc/defaultrouter habe ich mit folgendem Eintrag noch angelegt:
192.168.0.100
Vielen Dank für Eure tatkräftige und ausführliche Hilfe und die vielen Tipps. :)
Viele Grüße
escimo
PS: Die Verbindung ist aber echt lahm über die UMTS-Karte. Da kann man sich bei jedem Buchstaben einen Kaffee zwischendurch holen und gemütlich trinken. ;D
-
PS: Die Verbindung ist aber echt lahm über die UMTS-Karte. Da kann man sich bei jedem Buchstaben einen Kaffee zwischendurch holen und gemütlich trinken. ;D
ssh "saugt" bei mir selbst DSL oefters. Vielleicht doch mal mit Telnet versuchen ;)
-
Vielleicht doch mal mit Telnet versuchen ;)
Lieber nicht. ;)
-
warum denn nicht? geht es dir um sicherheit? eine verschluesselte verbindung schuetzt dich nur vor'm abhoeren. um eine verbindung abhoeren zu koennen braucht es schon einiges an know-how und jede menge zeit. natuerlich gibt es eine handvoll personen auf der welt die ueber das know-how und die noetigen resourcen verfuegen eine ungesicherte verbindung abzuhoeren. aber die haben mit an sicherheit grenzender wahrscheinlichkeit anderes zu tun als deine telnet verbindung zu belauschen. sehr unwahrscheinlich, dass dabei ein grosser profit/gewinn rauskommen wuerde. oder hast du das coca-cola rezept irgendwo bei dir auf deinen rechnern versteckt? viel wahrscheinlicher ist eine brute-force attacke auf das login. und da bietet ssh vor telnet keinen vorteil (halt: wir reden nicht davon mittels zertifikat sich zu authentifizieren, dann sieht's natuerlich anders aus).
ct,
-
warum denn nicht? geht es dir um sicherheit? ... sehr unwahrscheinlich, dass dabei ein grosser profit/gewinn rauskommen wuerde. oder hast du das coca-cola rezept irgendwo bei dir auf deinen rechnern versteckt?
Wir wissen natürlich, dass es sowas wie Sicherheit(en) nicht wirklich gibt, sondern man es wohl eher als "Schadensreduzierung" ansehen sollte. Und ja, vielleicht habe ich ja das Rezept von Coca-Cola auf meinem heimischen Server. Oder war es Pepsi? ::)
Zudem stehe ich noch am Anfang aller Konfigurationen. Der SSH-Zugang soll nur der erste Schritt in einer langen Kette von "schadensreduzierenden" Maßnahmen sein. Um es mal grob abzustecken: ich baue mir mittels Containers+Zones eine "Sandbox" worin die Inhalte eingestellt werden, die Online gehen sollen.
Hauptgrund für die Anschaffung des Servers waren ein bis zwei kleine, private Projekte und die immer noch anstehenden Zertifzierungen für Solaris 10. Mein letztes Kombi-System war ein PC Markte "Eigenbau" (Pentium 3/800, Slot-1, 768MB RAM, 2x20GB HDD, 2x 3Com FastEthernet), der sowohl als Solaris 8 Workstation sowie als Server erhalten musste, diese Aufgaben dennoch mit Bravur meisterte. ;)
Grüße
escimo
-
au ja, das waere ein nettes project. auf basis von lance sptizner's "Armoring Solaris" einen aktuellen leitfaden fuer sol10 zu schreiben.
http://www.windowsecurity.com/whitepapers/Armoring_Solaris.html (http://www.windowsecurity.com/whitepapers/Armoring_Solaris.html)
ct,