Recuperarte cuando SSH deja de funcionar

Server Manager se comunica con tu servidor solo por SSH. Si SSH deja de funcionar, Server Manager no puede ayudarte: no tiene ningún otro canal para entrar en la máquina. Pero tu servidor sigue estando bien, y tienes otras formas de recuperar el acceso. Este artículo te ayuda a identificar los síntomas más habituales y te guía por las vías de recuperación.

Lee esto antes de entrar en pánico. Ninguno de los casos habituales de SSH roto significa que tus datos hayan desaparecido. El servidor sigue funcionando; simplemente no puedes iniciar sesión desde donde lo haces normalmente. En el peor de los casos, reinstalas el acceso SSH desde la consola web de tu proveedor en la nube: misma máquina, mismos discos, mismos archivos.

Paso 1 — Lee el error en lenguaje claro

Si intentaste conectarte desde Server Manager y falló, el cuadro de diálogo Connect ya muestra un diagnóstico en lenguaje claro de lo que probablemente está pasando:

Ese mensaje indica la causa más probable. La tabla siguiente relaciona el mensaje que te muestra Server Manager con dónde mirar a continuación.

Paso 2 — Recupéralo desde la consola web de tu proveedor

Si el diagnóstico anterior apunta a que "algo está roto en el propio servidor" (la mayoría de las filas de la tabla), la forma de volver a entrar es la consola web de tu proveedor en la nube: un terminal en el navegador que evita SSH por completo. Todos los proveedores importantes tienen una, aunque con nombres distintos:

Una vez dentro por la consola web, tienes acceso completo a la shell sin pasar por SSH, así que puedes arreglar lo que esté bloqueando SSH y luego volver a Server Manager.

La consola web pide la contraseña local del servidor. Es la contraseña a nivel del sistema operativo para tu usuario en el propio servidor: normalmente la que te envió tu proveedor por correo, o la contraseña que configuraste durante la instalación inicial. No es tu frase de cifrado de Server Manager ni la contraseña de tu cuenta del proveedor en la nube. Si nunca configuraste una y solo usabas una clave, ejecuta passwd <user> mediante el servicio de metadatos de tu proveedor (DigitalOcean tiene "Reset root password" → envía una nueva por correo; AWS permite restablecer la contraseña mediante Systems Manager).

Paso 3 — Corrige las causas más habituales

Una vez dentro por la consola web, revisa lo siguiente:

"He editado sshd_config y me he dejado fuera"

El clásico. Cambiaste algo en /etc/ssh/sshd_config, reiniciaste sshd y ahora no puedes volver a entrar. Recuperación:

bashsudo sshd -t                                  # comprobar sintaxis de la config actual
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.broken
sudo nano /etc/ssh/sshd_config                # deshacer el cambio problemático
sudo sshd -t                                  # comprobar sintaxis otra vez
sudo systemctl restart sshd                   # reiniciar correctamente

Cosas habituales que dejan a la gente fuera:

• PermitRootLogin no mientras se conectan como root → vuelve a permitir root, o crea primero un usuario sudo que no sea root
• PasswordAuthentication no antes de añadir su clave a ~/.ssh/authorized_keys
• Port 2222 (u otro no predeterminado): el servidor sigue activo, solo escucha en otro sitio; vuelve a conectarte al puerto nuevo
• AllowUsers alice que excluye al usuario con el que realmente estás iniciando sesión

"fail2ban ha bloqueado mi IP"

Si escribiste mal la contraseña 3–5 veces seguidas, fail2ban (o sshguard) suele bloquear tu IP entre 10 minutos y una hora. Para comprobarlo y desbloquearla:

bashsudo fail2ban-client status sshd               # ver IPs bloqueadas
sudo fail2ban-client unban <YOUR-IP>           # desbloquear la tuya

Tu IP actual es la que muestra curl ifconfig.me desde tu conexión de casa (no desde el servidor). Para evitarlo la próxima vez, añádete a /etc/fail2ban/jail.local en ignoreip = cuando vuelvas a tener acceso.

"ufw / iptables me ha dejado fuera"

Activaste el firewall sin permitir explícitamente el puerto 22:

bashsudo ufw status                                # ver reglas actuales
sudo ufw allow 22/tcp                          # permitir SSH explícitamente
sudo ufw reload

Para iptables directamente:

bashsudo iptables -L INPUT -n -v                   # ver qué está bloqueando
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
sudo netfilter-persistent save                 # guardar (Debian/Ubuntu)

"He eliminado mi propia clave pública de authorized_keys"

Si vaciaste por accidente ~/.ssh/authorized_keys (o le pusiste permisos incorrectos con chmod), vuelve a añadirla desde la consola web:

bashmkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys                    # pegar tu clave pública, guardar
chmod 600 ~/.ssh/authorized_keys

La clave pública es el archivo de una sola línea corto, normalmente en ~/.ssh/id_ed25519.pub (o id_rsa.pub) en tu portátil. Pega la línea completa, incluido el prefijo ssh-ed25519 … y el sufijo user@host.

Si ya no tienes la clave pública original, genera un nuevo par de claves en tu portátil:

bashssh-keygen -t ed25519 -C "you@laptop"          # crea ~/.ssh/id_ed25519 + .pub
cat ~/.ssh/id_ed25519.pub                       # pegar esto en authorized_keys

"El firewall de mi proveedor ha cambiado solo"

No ha cambiado solo, pero los proveedores sí ajustan periódicamente las políticas predeterminadas. Abre la página Security List / Network Security Group / Firewall Rules de tu proveedor y comprueba que el puerto 22 (o el puerto en el que escuche tu SSH) siga permitido desde internet público (0.0.0.0/0) o desde tu rango de IP específico.

Si tu IP cambió (ISP de casa, mudanza a otra ciudad, cambio a móvil) y habías limitado el firewall a tu IP antigua, la IP nueva estará bloqueada. Amplía la regla temporalmente a 0.0.0.0/0, entra y luego vuelve a restringirla si quieres.

Paso 4 — Vuelve a conectarte desde Server Manager

Cuando SSH funcione desde tu terminal (prueba con ssh -v <user>@<host>), vuelve a Server Manager y haz clic en Connect server. Introduce de nuevo las credenciales y estarás donde estabas. El historial de chat de la sesión anterior habrá desaparecido (las sesiones SSH viven solo en RAM por diseño), pero tus sitios y servicios del servidor no se habrán tocado.

Si tienes el servidor guardado (con una frase de cifrado de Server Manager), selecciónalo en el desplegable en lugar de introducirlo de nuevo.

Opciones de último recurso

Si no puedes entrar ni siquiera por la consola web del proveedor, todavía tienes opciones:

• Restaurar una snapshot: si hiciste una snapshot antes de que algo saliera mal (y la mayoría de los proveedores las ofrecen, a veces de forma automática), restaura esa snapshot. Pierdes los cambios posteriores, pero recuperas un sistema que sabes que funcionaba.
• Reconstruir desde una copia de seguridad: si tienes un paquete .tar.gz de Server Manager (consulta Copias de seguridad), crea un servidor nuevo, instala Server Manager en él y usa el asistente Restaurar desde una copia de seguridad. Mismo sitio, servidor nuevo.
• Desconectar el disco y montarlo en otra VM: es avanzado, pero funciona en la mayoría de los proveedores. Detén la VM rota, desconecta su disco de arranque, conéctalo a una VM que funcione como disco secundario, móntalo, edita los archivos que se rompieron (sshd_config, authorized_keys), desmóntalo, vuelve a conectarlo a la VM original y reinicia. La documentación de tu proveedor tiene los pasos detallados.

Prevención — antes de cambiar nada relacionado con SSH

Una breve lista de comprobación antes de editar sshd_config que le ha ahorrado a mucha gente un susto a las 2 de la mañana:

1. Abre una segunda sesión SSH antes de editar: así, si te dejas fuera de la sesión nueva, la antigua seguirá activa y podrás revertir los cambios.
2. **sudo sshd -t** antes de reiniciar: detecta la mayoría de los errores de sintaxis.
3. Prueba la nueva configuración sin hacerla permanente. sudo /usr/sbin/sshd -D -p 2222 -f /etc/ssh/sshd_config.new ejecuta un sshd de prueba en el puerto 2222 usando una configuración de prueba. Entra por SSH con -p 2222 para verificarlo; si funciona, entonces cambia la configuración y reinicia de verdad.
4. Ten preparado el acceso a la consola web de tu proveedor antes de empezar. Abre la pestaña, inicia sesión, confirma que la consola funciona y luego empieza a editar.
5. **No ejecutes ufw enable por SSH** sin ejecutar antes sudo ufw allow 22/tcp.

Para los cambios que Server Manager hace desde el chat: Faro se detiene para pedir tu aprobación en cada comando, y no propondrá nada que vaya a romper SSH (sin ediciones de sshd_config, sin ufw enable sin una regla explícita que lo permita). Las que suelen atrapar a la gente son las sesiones manuales con nano /etc/ssh/sshd_config.

Preguntas frecuentes

¿He perdido algo? No: tus archivos, tus sitios y tus bases de datos están exactamente como los dejaste. SSH es solo el canal; el servidor en sí no se ha tocado.

¿Se ha perdido el historial de chat? Sí. Las sesiones SSH viven solo en RAM: cuando la sesión termina (por tu lado o por el lado del servidor), el chat se reinicia. Eso sí, el trabajo que hizo el chat en el servidor permanece: sitios desplegados, configuraciones editadas y servicios instalados persisten con normalidad.

¿Puedo evitar esto por completo? En gran parte, sí. La vía guiada por Server Manager es más segura (aprobación en cada paso; sin ediciones de sshd_config). El riesgo viene de las sesiones SSH manuales en las que editas la configuración por tu cuenta. Si lo haces todo mediante Server Manager, el bloqueo de acceso casi nunca ocurre.

Mi servidor está en un proveedor que no aparece en la tabla anterior. El principio es universal: la mayoría de los proveedores tienen alguna forma de consola fuera de banda (VNC, serie, shell web). Busca en la documentación de tu proveedor "console" o "rescue mode". Si tienes acceso físico (homelab), un monitor y un teclado hacen la misma función.

Server Manager dice "Connection refused", pero acabo de usar SSH desde mi terminal hace 5 minutos. O bien sshd se ha caído (compruébalo desde la consola de tu proveedor: systemctl status sshd), o fail2ban ha bloqueado la IP del VPS de Server Manager (distinta de tu IP de casa: Server Manager se ejecuta en su propio centro de datos y tu servidor ve esa IP como origen). Añade la IP de salida de Server Manager a la lista blanca de ignoreip = en fail2ban, o relaja los ajustes de findtime/maxretry.

Qué NO cubre este artículo

• Recuperación a nivel de cuenta (olvidaste tu inicio de sesión de Server Manager, olvidaste la contraseña de tu cuenta del proveedor en la nube): eso va por otra vía, el flujo de recuperación de cuenta del proveedor y el restablecimiento de contraseña de Server Manager en la página de inicio de sesión.
• Rescate de discos cifrados (raíz cifrada con LUKS que no se desbloquea): depende del proveedor; consulta su documentación para "rescue mode" o "single-user boot".
• Clave SSH perdida definitivamente sin ningún otro método de acceso: llegados a ese punto, lo práctico es reconstruir desde una copia de seguridad. Consulta Restaurar desde una copia de seguridad y Copias de seguridad para ver el panorama completo.