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?
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?
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?