• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Server über Internet mit Putty nicht erreichbar

G

gTux

Hilfe !!! Ich habe hier einen server von einem bekannten, der müsste ueber putty durch dyndns erreichbar sein - früher gings.

Jetzt kann ich den aber mit putty durch dyndns nicht erreichen. Ich bekomme folgende Meldung von putty:

"PuTTY Fatal Error
Disconnected: No supported authentication methods available"

Das ist ein Popup - Fehlermeldung.

Dann kann ich auch von dem server den router pingen, aber ich kann nicht http://www.google.de pingen. Somit kann ich auch die online updates nicht machen.
Egal ob ich die Firewall ein oder ausschalte (SuSEfirewall2) - es ändert sich nichts. SSH und port 22 ist für extern und auch intern erlaubt.

Daten:
netzwerk 192.168.40.0/24
router 192.168.40.1
server 192.168.40.100
client1 192.168.40.10
client2 192.168.40.11

Portfreigabe im router ist eingetragen - von port 12005 auf 22. Ich erreiche auch meinen eigenen Server auf die gleiche Weise durch dyndns.
Auch wenn ich statt der dyndns Adresse die aktuelle IP des Routers nehme, kann ich den Server nicht erreichen.

Suse 11.2 wird benutzt.
Linux 2.6.31.5-0.1-desktop x86

In der resolv.conf steht "nameserver 192.168.40.1". Wenn ich http://www.google.de pinge, dann kommt die Fehlermeldung in der bash:
connect: network is unreachable

Das scheint was mit dns zu sein.

Das hier ist meine sshd_conf - vielleicht ist da ein Fehler?

Code: 
#	$OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 180m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of 
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no
 

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes 
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/lib64/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	ForceCommand cvs server

Durch das LAN komme ich rein - nur bei dyndns klappt es nicht. Die dyndns adresse kann ich übrigens pingen.

Kann ich irgendwo auslesen ob die Pakete zum Server durchdringen?
 
OP
G

gTux

Die Putty configuration habe ich von meinem eigenen Server übernommen und nur die dyndnsadresse und den Port abgeändert. Meinen Server erreiche ich mit der config.

Hier die gewünschte Ausgabe:
Code: 
dewey:~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.40.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

Hier die ifcfg-eth0:
Code: 
dewey:~ # cat /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.40.100/24'
MTU='1492'
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
NETMASK='255.255.255.0'
NETWORK='192.168.40.0'
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'

Ich hatte übrigens zuvor mit yast die IP, Netzmaske und den Gateway eingetragen...
 
M

marce

versuchst Du vom internen Netz aus auf die DynDNS-Adresse zuzugreifen (also von einem der oben genannten Clients)? Die meisten Home-Router können das nicht - da geht der Zugriff nur, wenn Du wirklich von extern kommst...
 
OP
G

gTux

Ja, das tue ich. Aber ich habe eine Fritz box 7270 - und auch den anderen server erreiche ich aus diesem netz per dyndns.
 
M

marce

ist der andere Server im gleichen Netz? Lt. Deiner Beschreibung oben nämlich nicht.

Anders formuliert: Auf Dyn-DNS-Freigaben zugreifen, die hinter dem gleichen Home-Router wie der Client sitzen geht meist nicht.
Code: 
Cl1 -> Router1 -> DynDNS --+
                           !
SV1 <- Router1 <- ext.IP <-+
geht nicht während
Code: 
Cl1 -> Router1 -> DynDNS --+
                           !
SV2 <- Router2 <- ext.IP <-+
geht.
 
prinzunix

prinzunix

Wo bitte hat Dein Rechner eine Defaultroute? Ohne die geht schon mal gar nie nix nach Extern.

Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.3.201   0.0.0.0         UG    0      0        0 eth0

4. Zeile z.B. Destination 0.0.0.0 .
 
prinzunix

prinzunix

marce schrieb:
ist der andere Server im gleichen Netz? Lt. Deiner Beschreibung oben nämlich nicht.

Anders formuliert: Auf Dyn-DNS-Freigaben zugreifen, die hinter dem gleichen Home-Router wie der Client sitzen geht meist nicht.
Code: 
Cl1 -> Router1 -> DynDNS --+
                           !
SV1 <- Router1 <- ext.IP <-+
geht nicht
Zum Vergrößern anklicken....

Da muss dann noch ein anderer Fehler vorliegen. Das geht auch, wie ich es hier täglich mache, z.B. wenn ich meine lokal gehostete Webseite über die externe. IP oder die externe URL aufrufe. Zwar nicht mehr DynDNS mittlerweile, weil feste IP, aber mit DynDNS ging es früher auch.
 
OP
G

gTux

Der andere Server hat die IP 192.168.40.102 und natürlich ist er im gleichen Netz.

Ich glaube, wenn das Problem mit den Pingen von google.de gelöst wird, dann wird auch putty gehen. Das muss damit zusammenhängen.

Ich habe von einem anderen Rechner ( nicht im gleichen Netz ) über das Internet eine Verbindung versucht. Das klappt auch so nicht. Den anderen Server erreiche ich problemlos.
 
prinzunix

prinzunix

Hast Du das Gateway eingetragen (interne Adresse des Routers) irgendwas mit 192.168.40.??? ?
Danach noch mal das Routing prüfen mit route -n . Da muss dann so eine Zeile sein:

Code: 
0.0.0.0         192.168.40.???   0.0.0.0         UG    0      0        0 eth0

Dann muss der Router noch NAT machen, was die aber per default eigentlich tun.
 
OP
G

gTux

Ja, wo denn? Ich habe das mit yast gemacht. Jetzt ist es wieder weg... eigenartig. Ich versuchs mal gleich.
 
prinzunix

prinzunix

Hast Du denn auch eine PAT (port address translation) auf dem Router für den Port 22 auf die interne IP des anzusprechenden Rechners gemacht? Ansprechen musst Du dann über die DynDNS auf Port 22 von dem Router.
 
OP
G

gTux

Ne, ich habe das so gemacht:

Code: 
Aktiv 	Bezeichnung        Protokoll 	    Port 	        an Computer 	an Port
dewey SSH 	                TCP 	       12005 	dewey-server 	   22

Ist eine Fritzbox 7270.
 
OP
G

gTux

Na logo tue ich es. Wie gesagt - mit anderen Server klappts. Ist auch suse 11.2

Ok, also wenn ich die fw in yast stoppe, komme ich immer noch nicht durch.
 
OP
G

gTux

Gelöst! Ich habe einfach alles relevanten Sicherheitspudates installieren - der Server wurde monatelang nicht aktualisiert - und siehe da ?! - es geht jetzt! Was es genau war, finden wir wohl nie raus, aber es geht schon mal - das ist gut.

Thanks für eure Unterstützung.
 
framp

framp

Moderator
Teammitglied
gTux schrieb:
... Ich habe einfach alles relevanten Sicherheitspudates installieren - der Server wurde monatelang nicht aktualisiert ...
Zum Vergrößern anklicken....
8O Das sollte man bei einem Server, der vom Intenet zugreifbar ist, tunlichst automatisch sicherstellen oder aber regelmäßig manuell vornehmen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben