Ich habe also versucht, einen von zu Hause aus zugänglichen SSH-Server zu haben, und habe den SSH-Port geöffnet, damit er vom Internet aus zugänglich ist. Wenn ich mich über meine LAN-IP-Adresse anmelde, läuft alles perfekt. Wenn ich mich jedoch mit meiner öffentlichen IP-Adresse anmelde, wird die Verbindung kurz angenommen und dann sofort wieder geschlossen. In diesem Netzwerk sind keine Firewall-Regeln aktiviert. So sieht es von meiner Seite aus aus. Ich habe alle Benutzernamen durch „user“ und alle IPs durch 1.1.1.1 ersetzt.
user@user:~/Desktop$ ssh -p 443 [email protected] -vvv
OpenSSH_7.9p1 Ubuntu-10, OpenSSL 1.1.1b 26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 1.1.1.1 is address
debug2: ssh_connect_direct
debug1: Connecting to 1.1.1.1 [1.1.1.1] port 443.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Ubuntu-10
ssh_exchange_identification: Connection closed by remote host
Hier ist der Fehler im auth.log auf dem SSH-Server:
Aug 14 23:36:46 user sshd[2761]: Server listening on 0.0.0.0 port 443.
Aug 14 23:36:46 user sshd[2761]: Server listening on :: port 443.
Aug 14 23:36:46 user sudo: pam_unix(sudo:session): session closed for user root
Aug 14 23:36:58 user sshd[2762]: Connection closed by authenticating user user 1.1.1.1 port 41122 [preauth]
Aug 14 23:40:42 user sshd[2790]: Accepted password for user from 1.1.1.1 port 41376 ssh2
Hier ist meine /etc/ssh/sshd_config auf dem SSH-Server:
# 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.
Port 443
#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 yes
StrictModes no
MaxAuthTries 69900
MaxSessions 10932
#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 no
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
ClientAliveCountMax 30000
#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 schließlich meine /etc/hosts.allow:
# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
sshd: ALL
Antwort1
Ihr Client sagt, dass der Server die Verbindung unmittelbar nach dem Senden der SSH-Begrüßungsnachricht beendet:
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Ubuntu-10
ssh_exchange_identification: Connection closed by remote host
Und Ihr Server sagt dieKlientbeendet die Verbindung:
sshd[2762]: Connection closed by authenticating user user 1.1.1.1 port 41122 [preauth]
Das bedeutet fast immer etwasmitten drinsendet gefälschte TCP-RSTs, um es so aussehen zu lassen, als sei die Verbindung geschlossen worden. Da Sie eine Verbindung zu Port 443 herstellen (normalerweise der HTTPS/TLS-Port) und die Trennung erst erfolgt, nachdem einige Nicht-TLS-Daten gesendet wurden, wäre eine vernünftige Schlussfolgerung, dass entweder der ISP des Servers oder der ISP des Clients HTTPS-Verbindungen abfängt.
(Dies passiert wahrscheinlich bei einer Verbindung aus einem streng überwachten Unternehmensnetzwerk, das unerwartete Datenformate möglicherweise als Eindringen betrachtet, oder aus einem eingeschränkten öffentlichen WLAN, das von seinen Kunden nichts anderes als das Durchsuchen von Websites erwarten kann.)
Versuchen Sie es mit Port 22, da dort SSH erwartet wird.
Wenn Port 443 Ihre einzige Option ist, könnten Sie experimentieren mitTunneloder ähnliche Programme, die beliebige TCP-basierte Verbindungen in TLS einfügen, sodass sie sehr wie eine HTTPS-Verbindung aussehen. (Dies gibt innen kein HTTP vor und funktioniert daher nicht, wenn das Netzwerk tatsächlich TLS-Daten entschlüsselt, täuscht aber Firewalls, die nur die äußere Schicht betrachten.)
Wenn das Problem bei Ihrem Firmen- oder Universitätsnetzwerk liegt, ist es möglicherweise einfacher (und weniger riskant), den Administratoren den SSH-Zugriff zu gestatten, als die Filterung zu umgehen.