Qué te dice el mensaje
ssh: connect to host 203.0.113.10 port 22: No route to hostMensajes parecidos significan cosas distintas, así que comprueba que tienes este. Cada fila de abajo se produjo con una regla o una configuración reales:
| Mensaje | Qué pasó |
|---|---|
No route to host | Ninguna máquina respondió en esa dirección de la red local, o un firewall respondió host-prohibited |
Network is unreachable | Tu máquina no tiene ninguna ruta, a menudo por falta de puerta de enlace predeterminada |
Connection refused | La máquina respondió, pero nada acepta conexiones en ese puerto, o un firewall lo rechazó con port-unreachable. Mira Connection refused |
Connection timed out | No volvió ninguna respuesta, a menudo por un firewall que descarta paquetes. Mira Connection timed out |
Primera prueba
ping -c 3 203.0.113.10
nc -vz -w 10 203.0.113.10 22Algunos servidores ignoran el ping, así que un ping fallido por sí solo prueba poco. Un ping que funciona mientras el puerto 22 da No route to host apunta directamente a un firewall en el servidor, que es la causa 2.
Causa 1: la máquina está apagada o la dirección es incorrecta
En la misma red local, tu máquina pregunta quién tiene la dirección. Si nadie responde, obtienes este error en unos segundos. En Linux puedes ver la consulta fallida:
ip neigh show to 203.0.113.10203.0.113.10 dev eth0 FAILEDEn macOS usa arp -n 203.0.113.10, que muestra incomplete o ninguna entrada.
Comprueba que la máquina está encendida y conectada, y revisa su dirección actual desde su propia consola o desde la lista de dispositivos de tu router. Los routers domésticos suelen asignar una dirección nueva tras reiniciarse. Un servidor en la nube puede tener una IP nueva después de pararlo y arrancarlo.
Causa 2: un firewall del servidor te rechaza
Esta regla produce exactamente el mismo mensaje en el cliente, aunque la máquina esté encendida y sshd en marcha:
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibitedEl rechazo predeterminado de firewalld en sistemas tipo Red Hat da el mismo resultado. Desde una consola en el servidor, mira qué hay:
sudo firewall-cmd --list-all
sudo iptables -S INPUT
sudo nft list rulesetPara permitir SSH con firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadCon ufw, mira cómo permitir SSH con ufw. En una cuenta en la nube, revisa también el grupo de seguridad o el firewall de red del proveedor.
Causa 3: falta una ruta o la VPN está apagada
Pregunta a tu sistema por dónde enviaría el paquete. Estos dos comandos solo leen la tabla de rutas:
ip route get 203.0.113.10route -n get 203.0.113.10El primero es para Linux y el segundo para macOS. Mira la interfaz y la puerta de enlace:
- Una dirección privada como 10.x que sale por tu Wi-Fi normal en lugar de por la VPN: la VPN está apagada, o no cubre esa subred.
- Dos redes que usan el mismo rango, como una red doméstica y una VPN ambas en 192.168.1.x: gana la equivocada. Cambia una de ellas.
- Una puerta de enlace incorrecta en el propio servidor: puede recibir tus paquetes y no responder. Revisa
ip routedesde su consola.
Si a esa red solo se llega desde otro servidor, pasa por él con un jump host y ProxyJump.
Causa 4: aislamiento del Wi-Fi
Las redes de invitados y muchas redes de oficinas u hoteles impiden que los dispositivos hablen entre sí. Si el mismo comando funciona desde otra red, o desde una conexión por cable, ese es el motivo. Pasa a la red principal o llega a la máquina a través de una VPN.
Causa 5: macOS o iOS bloquean la app en la red local
Desde macOS 15, los programas necesitan el permiso de Red local para llegar a máquinas de tu LAN. Apple dice que las herramientas de línea de comandos ejecutadas desde Terminal se permiten automáticamente, y que otros programas quedan bloqueados hasta que concedas el permiso. Así que si ssh a una dirección de la LAN falla dentro de otra app de terminal o editor pero funciona en Terminal, abre Ajustes del Sistema, luego Privacidad y seguridad, luego Red local, y activa esa app. En iPhone y iPad cualquier app SSH necesita el mismo permiso: Ajustes, luego Privacidad y seguridad, luego Red local. No afecta a las direcciones de internet pública.
Preguntas
¿No route to host es un problema de mi clave SSH?
No. La conexión falló antes de que SSH empezara, así que las claves, las contraseñas y el usuario no tienen nada que ver. Revisa la red: la dirección, un firewall o una ruta.
¿Por qué ping funciona pero SSH dice No route to host?
La máquina está encendida y un firewall en ella rechaza el puerto 22 con una respuesta host-prohibited. Revisa iptables, nftables o firewalld en el servidor, y el grupo de seguridad del proveedor.
¿Qué diferencia hay entre No route to host y Connection timed out?
No route to host es una respuesta clara: la dirección no es accesible. Un timeout significa que no llegó ninguna respuesta, casi siempre por un firewall que descarta los paquetes sin avisar.
Fuentes
- TN3179: Understanding local network privacy, Apple
- Manual de firewall-cmd, firewalld
- iptables-extensions(8), objetivo REJECT