Issues with SSH from an external IP
So I've been trying to have an accessible SSH server from home, and I opened the SSH port so that It would be accessible from the internet. When I log in through my LAN IP address, everything goes perfectly. Yet when I log in with my public IP address, It accepts the connection briefly, then immediately closes the connection. No firewall rules are enabled on this network. Here's What it looks like from my end. I replaced all usernames with user, and all IP's with 1.1.1.1.
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
Here's the error in the auth.log on the 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
Here's my /etc/ssh/sshd_config on the 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
And Finally, my /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
Your client says the server is terminating the connection immediately after sending the SSH "greeting" message:
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Ubuntu-10
ssh_exchange_identification: Connection closed by remote host
And your server says the client is terminating the connection:
sshd[2762]: Connection closed by authenticating user user 1.1.1.1 port 41122 [preauth]
That almost always means something in the middle is sending fake TCP RSTs to make it look like the connection has been closed. Since you're connecting to port 443 (normally the HTTPS/TLS port) and disconnection only happens after some non-TLS data has been sent, a reasonable conclusion would be that either the server's ISP or the client's ISP is intercepting HTTPS connections.
(This is likely to happen when connecting from a closely supervised corporate network, which might treat unexpected data format as an intrusion, or from a limited public Wi-Fi, which doesn't want its customers to do anything but browse websites.)
Try using port 22, which is where SSH is expected to be.
If port 443 is your only option, you could experiment with stunnel or similar programs, which put arbitrary TCP-based connections inside TLS making them look very much like an HTTPS connection. (This doesn't pretend to be HTTP on the inside, so it won't work if the network is actually decrypting TLS data, but it'll trick firewalls which only look at the outer layer.)
If the problem is with your company network or university network, it might be easier (and less risky) to have the admins allow SSH access than to bypass the filtering.