VPS Linux no responde a SSH: cómo recuperar el acceso sin reinstalar
¿VPS Linux colgada y SSH no conecta? Diagnostica la causa real (red, firewall, sshd, disco lleno) y recupera el acceso sin reinstalar desde cero.
Una VPS Linux que dejó de responder a SSH es el tipo de problema que parece grave pero rara vez lo es. En el 90% de los casos la máquina sigue funcionando normalmente — lo que falló fue un componente específico entre tú y el shell: ruta de red, firewall, daemon sshd, o el disco se llenó y el sistema dejó de aceptar conexiones nuevas.
Esta guía es para quien tiene una VPS Linux inaccesible ahora mismo y necesita recuperar el acceso sin tocar el botón de reinstalar. La reinstalación borra todo y casi siempre es innecesaria. El camino correcto es diagnosticar desde la consola fuera de banda del panel del hosting, identificar la causa real y corregir en pocos minutos.
Tiempo estimado: 10 a 20 minutos, según la causa. Asumiendo Ubuntu 22.04 o 24.04 LTS — los comandos sirven con pequeñas variaciones para Debian 12, AlmaLinux 9 y Rocky Linux 9.
Requisitos previos
Necesitas el panel de Hostini abierto con acceso a la consola fuera de banda (VNC o serie) de la VPS afectada, la contraseña de root actual o de un usuario con sudo, y una segunda terminal/pestaña para probar la reconexión sin perder la sesión de consola.
Ubuntu 22.04 / 24.04 LTS 22/tcp Panel Hostini 10–20 min Triaje rápido: descubre qué falló
Antes de abrir la consola, conviene hacer dos pruebas desde fuera para descartar hipótesis. Toman 30 segundos y te ahorran investigar lo que no es.
Desde tu equipo local, prueba si la VPS responde a ping:
ping -c 4 TU.IP.DE.VPSSi el ping vuelve, la máquina está viva y la red funciona. Si no vuelve, puede ser un problema de red del datacenter (raro), VPS apagada, o ICMP bloqueado por firewall — pasa a la siguiente prueba.
Prueba específicamente el puerto 22 con nc o telnet:
nc -vz TU.IP.DE.VPS 22Resultado succeeded significa que el sshd está escuchando y el firewall permite la conexión — el problema es autenticación o baneo por fail2ban. Resultado Connection refused significa que el sshd no está corriendo. Connection timed out significa firewall bloqueando o VPS sin red.
Estas dos salidas ya dividen el problema en tres categorías claras: red/VPS caída, daemon caído, o autenticación. Abres la consola con una hipótesis, no a ciegas.
Accediendo a la consola fuera de banda
La consola es un canal de emergencia que conecta directo al terminal serie de la máquina virtual — independiente de SSH, firewall o red. Es tu llave de repuesto.
En el panel de Hostini, ve a Servicios → tu VPS → Consola. La consola se abre en una ventana dentro del propio navegador. En algunos navegadores hay que activar el foco del teclado haciendo clic una vez en el área negra.
Inicia sesión con root y la contraseña definida en el aprovisionamiento, o con tu usuario sudo. Si olvidaste la contraseña de root, usa el procedimiento de reset del panel — reinicia la VPS en modo single-user y permite redefinirla.
La latencia de la consola es mayor y no hay historial de comandos por defecto. Evita escribir comandos largos a mano — copia y pega cuando puedas. Los comandos destructivos con sintaxis equivocada se ejecutan igual.
Diagnóstico en la consola: 4 verificaciones en orden
Ya dentro de la consola, ejecuta estas cuatro verificaciones en secuencia. La primera que falle es probablemente tu causa raíz.
1. ¿El daemon sshd está corriendo?
sudo systemctl status sshSi aparece active (running), bien — pasa a la siguiente. Si aparece inactive, failed o dead, el servicio se cayó. Levántalo con:
sudo systemctl start ssh
sudo systemctl enable sshRevisa los logs recientes para entender por qué se cayó:
sudo journalctl -u ssh -n 50 --no-pagerCausas comunes de failed: sintaxis inválida en /etc/ssh/sshd_config tras edición manual, certificado de host corrompido, u OOM killer matando el proceso.
2. ¿El sshd escucha en el puerto esperado?
sudo ss -tlnp | grep sshSalida esperada con puerto 22:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))Si el puerto es distinto de 22, tú o alguien editó Port en /etc/ssh/sshd_config. Ajústalo a 22 (o abre el puerto nuevo en el firewall — siguiente punto) y reinicia el servicio.
3. ¿El firewall está dejando pasar?
En Ubuntu/Debian el firewall por defecto es ufw:
sudo ufw status verboseBusca una línea 22/tcp ALLOW IN Anywhere. Si no aparece, añádela:
sudo ufw allow 22/tcp
sudo ufw reloadEn AlmaLinux/Rocky usa firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadSi habilitas ufw sin antes liberar el puerto 22, la conexión SSH se cae al instante. La consola fuera de banda lo resuelve, pero el dolor de cabeza es evitable: siempre sudo ufw allow 22/tcp antes de sudo ufw enable.
4. ¿El disco está lleno?
df -hSi / o /var aparece al 100% (o 99% con Avail en cero), el sshd no puede crear archivos de sesión y las nuevas conexiones fallan silenciosamente tras el handshake. Libera espacio:
sudo journalctl --vacuum-time=2d
sudo apt clean
sudo find /var/log -name "*.gz" -mtime +7 -deleteLuego ejecuta df -h de nuevo para confirmar que liberaste al menos unos 500 MB e intenta SSH otra vez.
Causas menos obvias
Cuando las cuatro verificaciones anteriores pasan pero SSH sigue sin conectar, conviene revisar tres culpables secundarios.
fail2ban baneó tu IP
Si fallaste la contraseña varias veces o tienes otro servicio corriendo en el IP que disparó el ban, tu IP puede estar en la blacklist:
sudo fail2ban-client status sshdLa salida lista los IPs baneados. Para liberar el tuyo:
sudo fail2ban-client set sshd unbanip TU.IP.PUBLICAPara saber tu IP pública desde fuera de la VPS, ejecuta curl ifconfig.me en un shell local — operadoras con CGNAT entregan IPs distintos del esperado.
sshd_config roto
Las ediciones manuales en /etc/ssh/sshd_config rompen el daemon silenciosamente cuando contienen sintaxis inválida. Valida:
sudo sshd -tSin salida = config ok. Cualquier mensaje apunta a la línea problemática. Corrige y reinicia:
sudo systemctl restart sshCambio de clave SSH del host
Si reinstalaste paquetes de SSH o restauraste un snapshot, la clave del host puede haber cambiado. Desde tu equipo local, el cliente reclama con REMOTE HOST IDENTIFICATION HAS CHANGED. Elimina la entrada antigua:
ssh-keygen -R TU.IP.DE.VPSY reconecta normalmente.
Verificación: confirma que volvió
Antes de cerrar la consola, valida la recuperación por dos vías independientes.
En una pestaña local, abre una nueva sesión SSH normalmente:
ssh [email protected]Si conecta, perfecto. Mantén la sesión abierta mientras haces el siguiente paso.
Aún con la consola fuera de banda abierta, confirma que la sesión SSH está registrada:
sudo ss -tnp | grep :22Deberías ver al menos una conexión ESTAB (establecida) viniendo de tu IP. Esto prueba que red, firewall y sshd están funcionando de punta a punta.
Cada vez que vayas a editar sshd_config, ufw o iptables, deja la consola abierta en una ventana y abre una segunda sesión SSH para probar el cambio. Si la segunda sesión funciona, puedes cerrar la primera con seguridad. Ese hábito de dos sesiones evita el 90% de los lockouts.
Próximos pasos
Recuperar el acceso es solo el comienzo — después conviene endurecer la configuración para evitar que se repita.
- Configura autenticación por clave SSH y desactiva la contraseña con
PasswordAuthentication noensshd_config. Antes de cerrar la sesión, prueba la clave en una segunda pestaña. - Instala y ajusta
fail2banpara banear IPs con un bantime razonable (1h) y maxretry de 5 — banear de más crea lockouts propios. - Crea snapshots regulares de la VPS desde el panel antes de cambios grandes en SSH o en el firewall. El rollback de snapshot es más rápido que la reinstalación.
- Si gestionas varias VPS, considera centralizar el acceso con un bastion host — un único puerto expuesto a internet y el resto detrás de él.
- Documenta tu puerto SSH, usuario admin y procedimiento de consola en tu propio runbook. En una emergencia nadie quiere recordar eso de memoria.
Si necesitas una VPS con consola fuera de banda confiable y snapshots integrados — lo que vuelve trivial este tipo de recuperación — la VPS Hostini entrega ambos en el panel estándar, sin coste adicional.
Preguntas frecuentes
¿Por qué mi VPS Linux responde a ping pero no a SSH?
Ping responde en capa 3 (ICMP) y SSH es capa 7 (TCP/22). Si ICMP vuelve pero TCP/22 no, el kernel de la VPS está vivo pero el sshd se detuvo, está escuchando en otro puerto, o el firewall (ufw/iptables/nftables) bloquea el puerto 22. Usa la consola fuera de banda del panel para inspeccionar `ss -tlnp` y `ufw status`.
¿Reiniciar la VPS desde el panel resuelve un SSH colgado?
Resuelve cuando la causa es proceso zombi, kernel oops u OOM killer reciente — básicamente cualquier estado de memoria inconsistente. No resuelve si la causa es configuración persistente: sshd_config roto, firewall con regla mala o disco raíz lleno. Por eso conviene diagnosticar vía consola antes de reiniciar a ciegas.
¿Cómo acceder a la VPS sin SSH funcionando?
Por la consola serie/VNC fuera de banda ofrecida en el panel del hosting. Ese canal es independiente del sshd y del firewall — conecta directo al tty de la máquina virtual. Inicias sesión con la contraseña de root o un usuario sudo existente y puedes editar archivos, reiniciar servicios y ajustar reglas de red.
¿El disco lleno puede tumbar el SSH?
Sí. Cuando `/` o `/var` llega al 100%, el sshd no puede escribir en `/var/log/auth.log`, escribir en `/run`, ni crear archivos temporales de la sesión — y la conexión falla justo después del handshake. Limpiar logs antiguos en `/var/log` y paquetes en `/var/cache/apt` suele reabrir el acceso en segundos.
Cambié el puerto SSH y me dejé fuera. ¿Cómo revierto?
Entra por la consola fuera de banda como root, abre `/etc/ssh/sshd_config`, vuelve a poner `Port` en 22 (o en el puerto que el firewall permite), ejecuta `sudo systemctl restart sshd` y ajusta `sudo ufw allow 22/tcp`. Siempre prueba el nuevo puerto en una segunda sesión antes de cerrar la actual — ese es el error número uno de quien endurece SSH.
¿Puede fail2ban estar bloqueando mi IP?
Sí, si fallaste la contraseña varias veces. Vía consola, ejecuta `sudo fail2ban-client status sshd` para ver IPs baneados. Para liberar el tuyo, usa `sudo fail2ban-client set sshd unbanip TU.IP.AQUI`. Confirma tu IP pública con `curl ifconfig.me` antes — operadoras con CGNAT pueden darte un IP distinto del que esperabas.