termalConnection refused y Connection timed out parecen hermanos — SSH no conectó en ninguno de los dos casos — pero son hallazgos opuestos, y apuntan a mitades distintas de la pila. Saber cuál de los dos tienes delante recorta la lista de sospechosos a la mitad antes de que teclees un solo comando de diagnóstico. Esta es la rutina de dos minutos: qué demuestra cada error, la única sonda que los separa de todo lo demás, y una lista de comprobación para cada rama. (Para los errores que ocurren después de que la conexión TCP tiene éxito — fallos de auth, avisos de clave de host, sesiones que mueren — mira el anillo descifrador.)
| Error | Qué demuestra | Causa probable | Primer comando |
|---|---|---|---|
Connection refused | El host está encendido y dijo que no activamente (volvió un RST) | Nada escucha en ese puerto, o una regla de firewall REJECT | ss -tlnp | grep sshd desde la consola |
Connection timed out | No volvió nada en absoluto — silencio en el camino | IP incorrecta, host caído, o un DROP silencioso (grupo de seguridad / firewall de la nube) | nc -vz host 22, luego revisa el firewall de la nube |
Qué demuestra cada error en realidad
Connection refused significa que la máquina te respondió. Tu SYN de TCP llegó a un host vivo, y el host dijo que no activamente — volvió un paquete RST o un ICMP port-unreachable. Eso es una cantidad sorprendente de buenas noticias: la IP es correcta, la ruta funciona, el host está encendido, y nada en el camino se está comiendo tus paquetes. El problema es acotado: nada escucha en ese puerto, o una regla de firewall lo está rechazando (no descartando).
Connection timed out significa silencio. Tus paquetes salieron y nunca volvió nada. Eso no demuestra casi nada sobre el servidor — puede estar caído, la IP puede ser incorrecta, o (lo más habitual) algo entre tú y él está descartando paquetes en silencio: un grupo de seguridad de la nube, un firewall con política DROP, un agujero negro de NAT o VPN.
Una regla mnemotécnica: refused = la máquina te habló; timed out = nunca lo hizo. Refused es un problema del host. Timed out suele ser un problema del camino.
Paso 1: sondea el puerto, no el host
Sáltate ping como primer movimiento — prueba lo que no toca en ambas direcciones. Un host que responde al ping puede aun así descartar el puerto 22 (los firewalls de la nube filtran por puerto), y un host que ignora el ping puede estar sirviendo SSH tan feliz (el ICMP se bloquea en todas partes). El ping no demuestra nada de lo que necesitas.
Sondea el puerto de verdad:
nc -vz example.com 22(¿Sin netcat? telnet example.com 22 funciona — cualquier salida que empiece por SSH-2.0-... significa que sshd respondió.) Tres resultados:
Connection refused— toma la rama de refused de abajo.- Se cuelga, luego expira — toma la rama de timed-out.
- Tiene éxito — el TCP está bien y tu problema está dentro del propio SSH: usuario o clave equivocados (
Permission denied (publickey)tiene su propia guía (en inglés)), una clave de host que no coincide, o algo quessh -vnombrará sin rodeos.
La rama de refused: encuentra qué (no) está escuchando
Necesitarás otra vía hacia la máquina — la consola web del proveedor existe para justo este momento.
¿Está corriendo sshd?
systemctl status sshd # the unit is "ssh" on Debian/UbuntuSi está muerto, no lo reinicies sin más — comprueba por qué: journalctl -u sshd (o -u ssh) muestra cómo salió. Una causa frecuente es una edición de config que no parsea; sshd -t valida el archivo y nombra la línea mala antes de que reinicies hacia el mismo fallo.
¿Escucha donde crees?
sudo ss -tlnp | grep sshdDos trampas se esconden en esta salida. El puerto: alguien movió SSH a 2222 y estás llamando al 22 — conecta con ssh -p 2222, y luego fíjalo por host en ~/.ssh/config (en inglés) para no volver a deducirlo nunca. La dirección: una línea ListenAddress puede atar sshd a una sola interfaz, así que responde en la IP privada y rechaza en la pública.
¿El firewall local está rechazando? sudo ufw status, sudo iptables -L -n, o nft list ruleset — busca reglas REJECT que cubran tu puerto. Una regla REJECT produce justo este error: el host está encendido, sshd quizá incluso esté escuchando, y el firewall responde en su nombre.
¿Te han baneado? La acción por defecto de fail2ban rechaza, así que un baneo parece Connection refused — solo desde tu IP. La señal: funciona desde el hotspot del teléfono pero no desde tu red. Desde la consola: fail2ban-client status sshd, luego fail2ban-client unban <your-ip> — y arregla lo que reintentara una credencial mala las veces suficientes para ganarse el baneo.
La rama de timed-out: encuentra dónde mueren los paquetes
Confirma primero la dirección. Da vergüenza exactamente una vez. ssh -v imprime la IP que marca de verdad — compárala con el panel del proveedor. El DNS obsoleto tras una migración, y la IP elástica que no sobrevivió a una parada de instancia, son ambos clásicos.
Revisa el firewall de la nube a continuación, porque es la respuesta la mayoría de las veces. Los grupos de seguridad (AWS), los NSG (Azure) y las reglas de firewall de VPC (GCP) descartan por defecto el tráfico de entrada — en silencio, que es precisamente un timeout. Busca una regla de entrada que permita TCP 22 desde tu dirección. La variante traicionera: una regla fijada a «My IP» hace meses, y tu IP ha cambiado desde entonces. Las ACL de red a nivel de subred son una segunda capa, menos visitada, que vale la pena mirar cuando el grupo de seguridad parece correcto.
Traza el camino cuando las reglas de la nube cuadran:
traceroute example.com # mtr example.com for a live view
sudo traceroute -T -p 22 example.com # TCP to the actual port — closest to the truthEl traceroute normal usa UDP o ICMP, que los firewalls tratan distinto de TCP 22 — la forma -T -p 22 prueba lo que SSH experimenta de verdad. Donde los saltos dejan de responder es, más o menos, donde mueren tus paquetes.
Sospecha de tu propio lado. Las redes de invitados de hoteles, cafeterías y oficinas bloquean el 22 saliente de forma rutinaria, y las VPN corporativas lo redirigen o lo descartan. La prueba de aislamiento es el hotspot del teléfono: si SSH funciona ahí, tu servidor está bien y el problema es la red en la que estabas.
Un firewall con política DROP en el propio host se ve idéntico a un descarte del lado de la nube visto desde fuera — si tienes acceso a la consola, revisa también iptables/nftables en la máquina.
El exótico: el port knocking. Un servidor que corre knockd descarta todo hasta que ve una secuencia secreta de intentos de conexión en otros puertos. Si un predecesor montó la máquina y cada puerto expira desde todas partes, pregunta por ahí antes de quemar una tarde con teorías de enrutamiento.
Quédate con la versión de dos minutos
La rutina entera se comprime bien: sondea el puerto con nc -vz. Refused → entra por consola, revisa sshd, el puerto de escucha, las reglas REJECT, fail2ban. Timed out → confirma la IP, revisa el grupo de seguridad de la nube, luego traceroute y tu propia red. El ping no aparece en ningún sitio.
Los datos recurrentes — qué puerto, qué usuario, qué host necesita keepalives — van en ~/.ssh/config (en inglés), no en tu memoria. Y parte del diagnóstico puede ser estado permanente en lugar de una carrera a mitad del incidente: Termalin guarda el puerto, el usuario, la clave y los ajustes de keepalive con cada host guardado y muestra el estado en vivo por host — así que «¿la máquina siquiera está encendida?» y «¿qué puerto era?» se responden antes de que conectes, y el servidor que solo escucha en 2222 deja de ser algo que redescubres cada trimestre.
Termalin es un cliente SSH gratuito y multiplataforma que guarda los puertos, usuarios, claves y keepalives por host junto al host y muestra el estado del host en vivo — descárgalo, o explora la lista completa de funciones.