He estado intentando tener un servidor SSH accesible desde casa y abrí el puerto SSH para que fuera accesible desde Internet. Cuando inicio sesión a través de mi dirección IP de LAN, todo va perfectamente. Sin embargo, cuando inicio sesión con mi dirección IP pública, acepta la conexión brevemente y luego la cierra inmediatamente. No hay reglas de firewall habilitadas en esta red. Esto es lo que parece desde mi punto de vista. Reemplacé todos los nombres de usuario con usuario y todas las IP con 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
Aquí está el error en auth.log en el servidor SSH:
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
Aquí está mi /etc/ssh/sshd_config en el servidor SSH:
# 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
Y finalmente, mi /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
Respuesta1
Su cliente dice que el servidor está finalizando la conexión inmediatamente después de enviar el mensaje de "saludo" SSH:
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Ubuntu-10
ssh_exchange_identification: Connection closed by remote host
Y su servidor dice elclienteestá terminando la conexión:
sshd[2762]: Connection closed by authenticating user user 1.1.1.1 port 41122 [preauth]
Eso casi siempre significa algo.en el centroestá enviando RST TCP falsos para que parezca que la conexión se ha cerrado. Dado que se está conectando al puerto 443 (normalmente el puerto HTTPS/TLS) y la desconexión solo ocurre después de que se hayan enviado algunos datos que no son TLS, una conclusión razonable sería que el ISP del servidor o el ISP del cliente están interceptando conexiones HTTPS.
(Es probable que esto suceda cuando se conecta desde una red corporativa estrechamente supervisada, que podría tratar el formato de datos inesperado como una intrusión, o desde una red Wi-Fi pública limitada, que no quiere que sus clientes hagan nada más que navegar por sitios web).
Intente utilizar el puerto 22, que es donde se espera que esté SSH.
Si el puerto 443 es su única opción, puede experimentar contúnelo programas similares, que colocan conexiones arbitrarias basadas en TCP dentro de TLS, haciéndolas parecer muy parecidas a una conexión HTTPS. (Esto no pretende ser HTTP en el interior, por lo que no funcionará si la red realmente está descifrando datos TLS, pero engañará a los firewalls que solo miran la capa externa).
Si el problema está en la red de su empresa o de la universidad, podría ser más fácil (y menos riesgoso) que los administradores permitan el acceso SSH que evitar el filtrado.