1
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 user@1.1.1.1 -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
Do you still have this issue if you try to use a different port? It's likely that one of your ISPs is intercepting HTTPS connections, and blocking anything that goes over port 443 but doesn't look like HTTPS. (Note how both hosts seem to think the connection was closed by the other side.) – user1686 – 2019-08-16T06:10:00.107
@grawity shoot, I think you're right. I tried changing ssh to mutliple other random ports and it refused to even establish a connection. Shouldnt ssh on port 443 look just like https though? It's all encrypted, right? – mama moss – 2019-08-16T12:20:30.260
No. The payload is encrypted, but the "envelope" used by SSH looks very different from TLS. That said, you could use a tool to put SSH inside TLS. – user1686 – 2019-08-16T13:10:33.687