Diferencia entre SSH Connection refused y timed out

Qué significan "Connection refused" y "Connection timed out" en SSH

Un error de conexión rechazada (Connection refused) y uno de tiempo de espera agotado (Connection timed out) en SSH son fallos opuestos; por tanto, la solución para uno nunca sirve para el otro. "Refused" significa que su paquete llegó al servidor y el kernel del servidor respondió que "no hay nada escuchando aquí". "Timed out" significa que su paquete no llegó a nadie que pudiera responder, por lo que el cliente esperó y se rindió. "Refused" es un problema de servicio en el servidor. "Timed out" es un problema de ruta antes de llegar a él.

Lea la línea exacta que imprimió su cliente, ya que la redacción es el diagnóstico completo.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

El tiempo es la segunda pista. "Refused" aparece de inmediato, aproximadamente en el tiempo que toma un viaje de ida y vuelta. "Timed out" permanece ahí durante muchos segundos antes de mostrarse, porque el cliente sigue retransmitiendo antes de rendirse. macOS imprime Operation timed out para la misma condición. Si el protocolo en sí es nuevo para usted, cómo funciona SSH y qué hace sshd es el contexto que esta guía asume.

Por qué "Connection refused" es una buena noticia

Refused es un reset de TCP (transmission control protocol). Su cliente envía un paquete SYN al puerto 22. Este atraviesa internet, llega a la pila de red del servidor y el kernel no encuentra ningún socket escuchando en ese puerto, por lo que responde con un paquete RST (reset). Su cliente SSH convierte ese RST en las palabras Connection refused.

Ese paquete de retorno demuestra mucho. La dirección es correcta. El host está encendido y enrutando. Nada en la ruta está descartando tráfico hacia ese puerto de forma silenciosa, porque algo regresó desde el extremo remoto. Por lo tanto, todos los sospechosos restantes residen en el propio servidor.

• sshd no se está ejecutando, porque falló al iniciar o nunca fue habilitado.
• sshd está escuchando en otro puerto, generalmente tras un cambio de endurecimiento (hardening).
• sshd está vinculado a una sola dirección, como ListenAddress 127.0.0.1, por lo que solo el propio servidor puede alcanzarlo.
• Un firewall está configurado para rechazar (reject) en lugar de descartar (drop), por lo que el firewall envía el RST en nombre del host. La acción reject de ufw y una regla de nftables que termina en reject with tcp reset hacen esto.

Un caso más parece igual a estos pero no lo es: usted escribió una dirección que pertenece a un host activo diferente. Ese host responde a su SYN, no tiene SSH en el puerto 22 y le rechaza cortésmente. Confirme la dirección antes de perder una hora en el servidor equivocado. Conocer qué es realmente un puerto en escucha en Linux hace que el resto de esta sección se lea más rápido.

Cómo solucionar Connection refused

No puede solucionar esto mediante SSH, porque SSH es precisamente lo que no funciona. Abra la consola web o la consola serie de su proveedor, inicie sesión allí y ejecute los siguientes comandos.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh utiliza el nombre de la unidad en Ubuntu y Debian. En RHEL y sus derivados como AlmaLinux, la unidad es sshd. ss -tlnp enumera todos los sockets TCP en estado de escucha junto con el proceso que los posee, y es la fuente de verdad: si ninguna línea menciona sshd, entonces no hay nada escuchando, independientemente de lo que indique el archivo de configuración. sshd -T imprime la configuración efectiva después de combinar todos los archivos Include, que es donde un puerto olvidado en /etc/ssh/sshd_config.d/ se hace evidente.

Lea la columna de direcciones con atención. 0.0.0.0:22 significa todas las direcciones IPv4 del servidor. [::]:22 significa todas las direcciones IPv6. 127.0.0.1:22 significa solo loopback, por lo que cualquier conexión remota será rechazada mientras que una conexión local mediante ssh localhost funcionará perfectamente.

Si no hay nada escuchando, inicie el servicio y lea el error que aparece cuando no arranca.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t analiza la configuración e imprime el archivo y el número de línea de una directiva incorrecta sin afectar al servicio en ejecución. Ejecútelo antes de cada reinicio, ya que una configuración rechazada provoca que sshd se cierre al iniciar y su próxima conexión sea rechazada.

La trampa de la activación por socket en Ubuntu

Ubuntu 24.04 incluye una unidad de socket de systemd para OpenSSH. Cuando esta unidad está habilitada, systemd retiene el puerto de escucha e inicia sshd por cada conexión, por lo que Port 2222 en sshd_config no produce cambios y el servidor sigue respondiendo en el puerto antiguo. Verifique en qué modo se encuentra su sistema antes de realizar cualquier edición.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Si el socket está habilitado, configure el puerto en la unidad de socket en lugar de en sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

La línea ListenStream= vacía es necesaria, ya que los ajustes de lista de systemd se añaden a lo que ya está configurado. Si la omite, el servidor escuchará en ambos puertos. Aplique el cambio con sudo systemctl daemon-reload y sudo systemctl restart ssh.socket, luego confirme con sudo ss -tlnp que el nuevo puerto es el que está siendo retenido. Cambiar el puerto es un paso habitual en el endurecimiento de SSH en un VPS, y es el paso que más frecuentemente bloquea el acceso a los usuarios.

Por qué "Connection timed out" significa que no hubo respuesta

Un tiempo de espera agotado (timeout) es silencio. Su cliente envió un SYN, lo retransmitió varias veces durante uno o dos minutos y nunca recibió ni un solo paquete de vuelta. No se puede confirmar nada sobre el servidor, ya que no se recibió ninguna comunicación de su parte.

El silencio es exactamente lo que produce una regla DROP, y el descarte (drop) es deliberado. Un rechazo le indica a cualquiera que esté escaneando que el host existe, por lo que ufw y cualquier firewall de red de un proveedor en la nube descartan los paquetes no deseados sin enviar nada de vuelta. Su tiempo de espera agotado suele ser un firewall cumpliendo su función en un puerto que usted quería abierto.

• La dirección es incorrecta: un registro DNS que aún apunta a un servidor que usted reconstruyó, o un error tipográfico que termina en una dirección que nadie utiliza.
• El host no está activo: apagado o a mitad de un reinicio. Una suspensión del proveedor por facturación se ve exactamente igual desde el exterior.
• El firewall del host descarta el puerto 22, la mayoría de las veces porque ufw enable se ejecutó antes de que existiera cualquier regla de permiso.
• Un firewall del proveedor frente a la instancia lo descarta, y el sistema operativo nunca llega a ver el paquete.
• Su propia red bloquea el puerto 22 de salida, lo cual es común en conexiones de oficinas y hoteles.

Ejecute la prueba desde el lado correcto de la conexión

Este es el error que consume más tiempo. No puede diagnosticar un paquete perdido desde el interior de la máquina a la que no llegan los paquetes. Si pudiera iniciar sesión para ejecutar el comando, no tendría el problema. Cada comando de esta sección se ejecuta en su propia máquina.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts muestra la dirección que su máquina utilizará realmente, lo que detecta un registro DNS obsoleto en segundos. ssh -G imprime los ajustes que su cliente aplica tras leer ~/.ssh/config, por lo que detecta un bloque Host antiguo que reescribe silenciosamente el nombre de host, el puerto o el usuario. ssh -vvv muestra hasta dónde llegó el intento: una última línea sobre la conexión a la dirección seguida de una pausa larga indica un tiempo de espera agotado (timeout), mientras que una línea que informa de la versión remota de OpenSSH significa que el TCP ya tuvo éxito y su problema real es la autenticación. En Windows, Test-NetConnection 203.0.113.10 -Port 22 en PowerShell sustituye a nc.

Pruebe el puerto, no el host. Un ping fallido no prueba nada, porque muchos proveedores filtran ICMP (internet control message protocol) en el borde de la red. Un ping exitoso tampoco prueba nada, porque no dice nada sobre el puerto 22.

Luego cambie la única variable que ningún comando puede cambiar por usted: su red. Vuelva a intentarlo desde un punto de acceso móvil (hotspot). Si el punto de acceso conecta y su escritorio no, el bloqueo está de su lado de internet, o la dirección de su oficina ha sido bloqueada en el servidor.

El firewall del proveedor que no puede ver desde el servidor

La mayoría de los paneles de VPS ofrecen un firewall de red, a veces llamado grupo de seguridad o firewall en la nube, que se ejecuta antes de su instancia y mantiene su propia lista de reglas. ufw status en el servidor no puede verlo, por lo cual "pero si ya permití el puerto 22" es una frase tan común. Abra el panel y lea esa lista antes de reescribir una sola regla en el equipo.

Un comando resuelve la cuestión y requiere acceso a la consola. Inícielo en el servidor y luego intente conectar desde su portátil mientras se ejecuta.

sudo tcpdump -ni any tcp port 22

Si no aparece nada mientras su cliente intenta conectar, los paquetes se están descartando antes de llegar al sistema operativo, por lo que el fallo está en el firewall del proveedor o en la ruta hacia el host. Si los paquetes SYN llegan y no sale ninguna respuesta, el descarte es local y pertenece a ufw o nftables. Esa única prueba divide la rama de tiempo de espera a la mitad, razón por la cual vale la pena el viaje a la consola.

Orden de reglas en ufw, IPv6 y el bloqueo accidental

El error en el orden de las reglas de ufw es la causa más frecuente de bloqueos. sudo ufw enable aplica una política predeterminada de denegar conexiones entrantes de inmediato; si no existe una regla para SSH, la sesión actual se mantiene por el estado establecido, pero cualquier conexión nueva agotará el tiempo de espera. Permita el acceso primero y habilite el firewall después.

sudo ufw allow OpenSSH
sudo ufw status verbose

El perfil de aplicación OpenSSH cubre únicamente el puerto 22. Si planea mover SSH al puerto 2222, la regla necesaria es sudo ufw allow 2222/tcp, la cual debe añadirse antes de realizar el cambio de puerto y no después. El conjunto completo de reglas se detalla en conceptos básicos de ufw para un VPS, y el orden seguro es parte de qué hacer en los primeros diez minutos en un VPS nuevo.

IPv6 genera un tiempo de espera que parece inexplicable. Si el nombre de host tiene un registro AAAA, el cliente intenta conectar mediante IPv6 primero; por tanto, si faltan las reglas de IPv6 en el servidor, la conexión se queda colgada mientras que un intento mediante IPv4 funciona correctamente. Debe configurar ambos protocolos manualmente.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Si -4 conecta y -6 no, la solución reside en las reglas IPv6 del servidor, y abrir el mismo puerto para IPv6 en ufw explica el procedimiento paso a paso.

También es posible que se haya bloqueado a sí mismo. fail2ban monitoriza el registro de autenticación e inserta una regla en el firewall contra las direcciones que fallan repetidamente; una clave incorrecta o un script ejecutándose en segundo plano pueden bloquear la dirección IP de toda una oficina. Un bloqueo que descarta paquetes se comporta como un tiempo de espera agotado. Un bloqueo que rechaza devuelve No route to host. Desde la consola:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Añadir su propia dirección a ignoreip es parte de una configuración funcional de fail2ban en Ubuntu 24.04.

Errores que no son ni rechazos ni tiempos de espera agotados

No route to host significa que se recibió un mensaje ICMP de destino inalcanzable. O bien su propia máquina no tiene una ruta hacia esa red, o algo en el trayecto respondió con un rechazo administrativo, que es lo que envía una regla REJECT de iptables.

Network is unreachable es su propia máquina respondiendo. No tiene ninguna ruta para esa familia de direcciones, y es la respuesta habitual cuando un nombre de host se resuelve solo a una dirección IPv6 en una conexión que solo admite IPv4.

kex_exchange_identification: Connection closed by remote host significa que la conexión TCP se estableció y el servidor colgó antes de finalizar el intercambio de claves. El puerto está abierto y sshd está activo, así que revise la carga del servidor, los MaxStartups o un baneo que se aplicó mientras usted se estaba conectando.

Permission denied (publickey) significa que llegó a la autenticación y falló en ese punto. La red y el firewall funcionan correctamente, por lo que nada de esta guía es aplicable. Diríjase a solucionar Permission denied (publickey) en SSH en su lugar.

Cómo recuperar el acceso y evitar un segundo bloqueo

Todo proveedor de VPS serio ofrece una consola que no depende de la red del invitado: una consola serie o una pantalla VNC basada en navegador. Esa consola es la vía de recuperación para ambas ramas de esta guía, ya que sigue funcionando cuando sshd está detenido y cuando una regla de firewall descarta todo el tráfico. Encuéntrela en el panel, inicie sesión como root o como su usuario habitual y ejecute las comprobaciones anteriores. Si nunca estableció una contraseña de root, la mayoría de los paneles pueden restablecerla por usted.

Cuando no existe una consola, la alternativa es el modo de rescate del proveedor. Este arranca un pequeño sistema de recuperación y monta su disco, lo que le permite editar /etc/ssh/sshd_config o eliminar una regla de firewall sin conexión y reiniciar.

Dos hábitos previenen el próximo bloqueo. Mantenga una segunda sesión SSH abierta siempre que edite sshd o el firewall, ya que esa sesión sobrevive gracias al estado establecido mientras prueba una nueva. Además, programe una reversión automática antes de realizar un cambio de firewall arriesgado.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

La primera línea programa a ufw para desactivarse en diez minutos. Aplique sus nuevas reglas, abra una nueva sesión SSH para verificar que funcionan y luego ejecute la segunda línea para cancelar la reversión. Si se bloquea a sí mismo, espere diez minutos y el firewall se desactivará por sí solo. Esto deja el servidor sin filtrar hasta que habilite ufw de nuevo, así que utilice este método mientras esté frente al teclado y no como una configuración permanente.

El orden de trabajo

1. Lea el texto del error y observe cuánto tiempo tardó en aparecer.
2. Refused: vaya a la consola y compruebe sudo ss -tlnp para ver si existe un socket a la escucha, su puerto y la dirección a la que está vinculado.
3. Timed out: desde su propia máquina confirme la dirección, luego verifique el firewall del proveedor en el panel y, finalmente, el firewall del host en el servidor.
4. Ninguna de esas cadenas: ya tiene una conexión TCP establecida, por lo que debe tratarlo como una cuestión de autenticación o de carga del servidor, no como un problema de red.

FAQ

¿Por qué SSH indica "Connection refused" si sshd está en ejecución?

Porque el rechazo proviene del socket, no del servicio, y un sshd en ejecución aún puede rechazarle. Abra la consola del proveedor y ejecute sudo ss -tlnp. Un socket en 127.0.0.1:22 rechaza a todo cliente remoto porque está vinculado únicamente a la interfaz de loopback. Un socket en otro puerto rechaza a cualquiera que siga usando el 22. Si se utiliza la activación por socket de systemd, el puerto proviene de ssh.socket y no de sshd_config, así que revise también systemctl is-enabled ssh.socket. Una regla de reject en ufw también devuelve un rechazo en nombre del host, por lo que debe leer sudo ufw status verbose antes de sacar conclusiones.

¿Por qué SSH agota el tiempo de espera si ufw ya permite el puerto 22?

Porque un tiempo de espera agotado significa que no se recibió respuesta, y ufw no es el único firewall en la ruta. La mayoría de los paneles de VPS ejecutan un firewall de red delante de la instancia, y el sistema operativo nunca ve lo que ese firewall descarta. Desde la consola, ejecute sudo tcpdump -ni any tcp port 22 e intente conectar desde su equipo mientras se ejecuta. Que no lleguen paquetes significa que el descarte es ascendente, en el panel. Que lleguen paquetes pero no salga respuesta significa que el descarte es local, en ufw o nftables.

¿Un ping fallido significa que mi VPS está caído?

No. Muchos proveedores filtran ICMP en el borde de la red, por lo que un servidor que gestiona tráfico normalmente puede ignorar cada ping que usted envíe. Un ping exitoso es igual de poco concluyente en la otra dirección, ya que no indica si el puerto 22 está abierto. Pruebe el puerto directamente con nc -vz -w 5 203.0.113.10 22 desde su propia máquina, o con Test-NetConnection 203.0.113.10 -Port 22 en PowerShell en Windows.

Cambié el puerto SSH y ahora nada conecta. ¿Qué salió mal?

Dos situaciones causan esto. Si el firewall nunca recibió una regla para el nuevo puerto, los intentos hacia el nuevo puerto agotan el tiempo de espera mientras el puerto 22 rechaza la conexión, por lo que sudo ufw allow 2222/tcp debe aplicarse antes del cambio de puerto y no después. Si el equipo utiliza la activación por socket de systemd para SSH, Port 2222 en sshd_config es ignorado y systemd sigue manteniendo el puerto antiguo, lo cual puede confirmar con systemctl is-enabled ssh.socket. Recupere el acceso a través de la consola del proveedor, corrija el error correspondiente y luego conecte con ssh -p 2222 user@203.0.113.10 una vez que sudo ss -tlnp muestre el nuevo socket.