ssh über internet

[sparks]

Hallo,

Ich habe einen Router und einen Debian-Rechner und würde gerne sshd vom Internet aus erreichbar machen.
Dazu habe ich im Router den Port 22 auf den Debian-Rechner weitergeleitet.

Jedoch bekomme ich beim Verbindungsaufbau über die externen IP einen timeout. Im internen Netz läuft der SSH-Service ohne Probleme.

Um einen Fehler im Port-Forwarding auszuschließen, habe ich den Port 22 auf einen anderen Rechner geleitet und dort funktioniert es.

/etc/hosts.deny ist leer und iptables ist nicht konfiguriert, hat also die Standardeinstellungen.

Wo könnte das Problem liegen?

 

[Wolfgang]

Hallo
Hast du den Port in beide Richtungen weitergeleitet?
Wie sieht denn deine /etc/ssh/ssh_config bzw. sshd_config aus?

Gruß Wolfgang

 

[sparks]

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin no
StrictModes yes

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

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

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

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

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

Hast du den Port in beide Richtungen weitergeleitet?

Kann ich nicht sagen. Der Router ist ein Eumex 300 IP und bietet keine große Fülle an Einstellungsmöglichkeiten. Man kann nur den Port 22 auf den entsprechenden Port auf einem internen Rechner weiterleiten.

Aber prinzipiell muss es ja funktionieren, da sonst das Weiterleiten auf den anderen Rechner auch nicht klappen würde.

 

[Wolfgang]

Hallo
Mit welchen User versuchst du dich einzuloggen?
Root ist bei dir verboten.

PermitRootLogin no

Portforwarding bei eumex300ip findest du unter
Netzwerk / NAT & Portregeln
Dort erstellst du eine neue Regel.
Dabei sowohl öffentlich als auch privat für diesen Port eingeben.

Gruß Wolfgang

 

[sparks]

Hallo
Mit welchen User versuchst du dich einzuloggen?
Root ist bei dir verboten.

PermitRootLogin no

Portforwarding bei eumex300ip findest du unter
Netzwerk / NAT & Portregeln
Dort erstellst du eine neue Regel.
Dabei sowohl öffentlich als auch privat für diesen Port eingeben.

Gruß Wolfgang

Dass man sich mit root nicht einloggen kann, ist beabsichtigt. Ich melde mich mit einem normalen Nutzerkonto an.
Die Port-Weiterleitung ist im Router eingestellt.

Bis zur Anmeldung komme ich gar nicht. Der SSH-Client gibt "Operation timed out" aus.

Ich habe auch schon mit tcpdump den Verkehr mitgeschnitten und er kommt definitiv zustande, nur erkenne ich dort keinen Fehler.

 

[Fallout]

Bis zur Anmeldung komme ich gar nicht. Der SSH-Client gibt "Operation timed out" aus.

Ich habe auch schon mit tcpdump den Verkehr mitgeschnitten und er kommt definitiv zustande, nur erkenne ich dort keinen Fehler.

Das heißt, auf dem ssh-Server kommen die Pakete an, aber es erfolgt keine Antwort? Dann hört sich das stark nach einem netfilter wie iptables o. ä. an, der da noch ein Wörtchen mitredet.