Ich habe einen Server in meinem lokalen Netzwerk, den ich für die Arbeit über SSH verwende. Ich habe keine Probleme, mich über das LAN damit zu verbinden. Das Problem tritt auf, wenn ich versuche, mich von außerhalb damit zu verbinden. Ich habe die Portweiterleitung für Port 2209 (meinen benutzerdefinierten SSH-Port) sowie für Web-Ports eingerichtet. Als ich ihn eingerichtet habe, konnte ich einmal eine Verbindung herstellen, aber nur etwa eine Woche später tritt bei der Verbindung immer wieder eine Zeitüberschreitung auf.
Gleichzeitig kann ich eine Webseite vom Server aus öffnen, Port 80 funktioniert also einwandfrei. Es ist eigentlich nur Port 2209. Ich habe bestätigt, dass die Portweiterleitung korrekt ist, dass dieser Port in der Windows-Firewall als Ausnahme eingerichtet und die Regel aktiviert ist. Trotzdem tritt bei der Verbindung eine Zeitüberschreitung auf.
Bitte lassen Sie mich wissen, ob Sie Screenshots oder Protokolle benötigen. Ich kann sie bereitstellen. Ich bin nicht sicher, welche Informationen für eine optimale Beurteilung erforderlich sind.
UPD 1: In den Kommentaren wurde darauf hingewiesen, dass SSH mit der Option -vvv ausgeführt werden soll. Hier sind die Protokolle:
❯ ssh -vvv -p 2209 andrey@<ip>
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "<ip>" port 2209
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to <ip> [<ip>] port 2209.
debug1: connect to address <ip> port 2209: Resource temporarily unavailable
ssh: connect to host <ip> port 2209: Resource temporarily unavailable
Gleichzeitig ist die Verbindung innerhalb des LANs völlig problemlos. Das Gleiche gilt für die Verbindung zum HTTP des Servers über das WAN.
Und hier ist meine SSH-Konfiguration:
❯ cat /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj 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 override the
# default value.
Include /etc/ssh/sshd_config.d/*.conf
Port 2209
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# 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 yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange 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
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Und /etc/ssh/sshd_config.dist leer, also ist dies die einzige Konfiguration.
UPD 2: Mir ist aufgefallen, dass ich nie erwähnt habe, wie ich es genau eingerichtet habe. Es ist eine Windows-Maschine, aber SSH befindet sich innerhalb von WSL. Ich muss also durch die Windows-Firewall, um an SSH zu gelangen.
Antwort1
Wie in allen Fällen dieser Sache war es keine seltsame, mysteriöse Kraft, die mich blockierte. Ich habe mir die Portweiterleitung im Router und in der Firewall in Windows angesehen. Aber nachdem ich in den Einstellungen meines Routers nachgesehen hatte, stellte ich fest, dass er eine sehr minimale Firewall hat, die fast nichts tut, außer Pings aus dem WAN zu blockieren. Ich schätze, alle meine SSH-Clients haben Ping als ersten Schritt verwendet und wenn dieser fehlgeschlagen ist, haben sie keine Verbindung hergestellt.
Wenn Sie ein ähnliches Problem haben, schauen Sie einfach in Ihrem Server nach.UndRoutereinstellungen für alle Optionen.