Tutoriales de VPS
SSH bloqueado tras activar UFW en un VPS (2026): reglas de firewall, consola y lista de recuperación con modo rescate
SSH deja de conectar de repente tras activar UFW. Normalmente el servidor no está roto: el problema es el puerto SSH, el firewall de la nube o el orden de las reglas. Este artículo cubre cuatro situaciones —aún conectado, bloqueado fuera, solo consola y modo rescate— con comandos de diagnóstico y recuperación listos para copiar.
SSH bloqueado tras activar UFW en un VPS (2026): reglas de firewall, consola y lista de recuperación con modo rescate
El error más común cuando alguien activa un firewall en un VPS por primera vez no es "no haber activado la protección de seguridad", sino haber ejecutado primero:
sudo ufw enable
Después, la sesión SSH actual aguanta un rato, pero un terminal nuevo ya no conecta. Poco después la red parpadea, la SSH existente también se cae y el servidor te deja literalmente fuera de la puerta.
Esto es muy habitual, sobre todo en sistemas Ubuntu / Debian. UFW no tiene ningún problema: simplemente bloquea las conexiones entrantes que no has permitido explícitamente. El problema real suele estar en uno de tres puntos:
- No permitiste antes el puerto SSH
- Cambiaste el puerto SSH pero solo permitiste el 22
- El grupo de seguridad del proveedor cloud y las reglas UFW del sistema se contradicen
Este artículo aborda dos estados: "aún puedo conectar" y "ya no puedo conectar". No te apresures a reinstalar el sistema: la mayoría de los casos se pueden recuperar.
Si todavía tienes una ventana SSH que no se ha desconectado, trabaja en ella primero y no la cierres.
Si ya no puedes conectar en absoluto, pero la consola del VPS ofrece VNC, Console, Serial Console o Rescue Mode, aún tienes oportunidad de recuperarlo.
Mira primero el error:
ssh root@your_server_ip
Los síntomas habituales se agrupan más o menos así:
| Síntoma | Causa más probable |
|---|---|
Connection timed out | Firewall, grupo de seguridad, puerto no permitido |
Connection refused | El servicio SSH no escucha, o el puerto es incorrecto |
Permission denied | Problema de clave, usuario o permisos |
| Solo la red de la oficina/casa no conecta | Tu IP local está restringida o Fail2Ban la bloqueó por error |
Si ves Permission denied, el foco no está en UFW; consulta primero este artículo: Qué hacer si VPS SSH Permission denied.
Si es Connection timed out, sigue leyendo este artículo.
Este es el caso más fácil de recuperar. No reinicies, no cierres sesión, no cierres el terminal.
sudo ufw status verbose
Si ves algo como:
Status: active
Default: deny (incoming), allow (outgoing), disabled (routed)
significa que la entrada se deniega por defecto. A continuación, confirma si el puerto SSH está permitido.
No adivines el puerto. Mira directamente los listeners:
sudo ss -lntp | grep ssh
Puede que veas:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=888,fd=3))
O quizá:
LISTEN 0 128 0.0.0.0:2222 0.0.0.0:* users:(("sshd",pid=888,fd=3))
Luego revisa el archivo de configuración para confirmar:
sudo grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
Si no hay salida de Port, normalmente es el 22 por defecto.
Si SSH está en el 22 por defecto:
sudo ufw allow OpenSSH
sudo ufw allow 22/tcp
OpenSSH es el perfil de aplicación de UFW, normalmente equivale a permitir el 22, pero recomiendo además escribir una regla explícita 22/tcp: es más clara al diagnosticar después.
Si lo cambiaste al 2222:
sudo ufw allow 2222/tcp
Si no estás seguro del puerto, no borres reglas a lo loco: primero permite el puerto en el que SSH está escuchando realmente.
sudo ufw reload
sudo ufw status numbered
Deberías ver algo como:
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 2222/tcp ALLOW IN Anywhere
Luego, sin salir de la ventana actual, abre otro terminal y prueba:
ssh root@your_server_ip
Si usas un puerto personalizado:
ssh -p 2222 root@your_server_ip
Cuando la nueva ventana conecte, cierra la antigua.
Muchos paneles de VPS ofrecen VNC Console, Serial Console o Web Console. No pasan por el puerto SSH público, así que cuando UFW bloquea SSH, la consola normalmente sigue abriéndose.
Tras entrar en la consola, inicia sesión en el sistema. Luego ejecuta:
sudo ufw status numbered
Si solo es que el puerto SSH no está permitido, añade la regla directamente:
sudo ufw allow 22/tcp
sudo ufw reload
Si no estás seguro del puerto SSH:
sudo ss -lntp | grep ssh
sudo grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
Luego permite el puerto real:
sudo ufw allow 2222/tcp
sudo ufw reload
Si tienes prisa por recuperar el acceso, puedes desactivar UFW temporalmente:
sudo ufw disable
Pero esto es solo un autosalvamento temporal. En cuanto puedas volver a entrar por SSH, restaura enseguida las reglas mínimas:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Si tu SSH no está en el 22, sustituye 22/tcp por el puerto real.
Si el panel del VPS no tiene consola utilizable, o no puedes iniciar sesión en la consola, tendrás que usar Rescue Mode. Los nombres varían según el proveedor; los más comunes son:
- Rescue Mode
- Recovery Mode
- Rescue ISO
- Boot from ISO
- Emergency Console
Tras entrar en modo rescate, el sistema suele arrancar en un entorno Linux temporal. Lo que debes hacer es montar el disco del sistema original y entrar para modificar las reglas UFW o desactivar UFW directamente.
Primero mira los discos:
lsblk
Suponiendo que la partición del sistema original es /dev/vda1, móntala:
sudo mkdir -p /mnt/sysroot
sudo mount /dev/vda1 /mnt/sysroot
Si hay particiones boot o efi separadas, móntalas según la situación real. La mayoría de los VPS pequeños solo tienen una partición raíz.
Entra en el sistema original:
sudo mount --bind /dev /mnt/sysroot/dev
sudo mount --bind /proc /mnt/sysroot/proc
sudo mount --bind /sys /mnt/sysroot/sys
sudo chroot /mnt/sysroot
Desactiva UFW:
ufw disable
O añade reglas de permiso:
ufw allow 22/tcp
ufw reload
Sal y reinicia:
exit
sudo reboot
Si no estás familiarizado con el modo rescate, puedes consultar también: Cómo usar el modo rescate de un VPS.
Mucha gente solo cambia UFW dentro del sistema y olvida que el panel del proveedor cloud tiene otra capa de firewall.
La ruta de acceso público suele ser:
你的电脑 -> 云厂商安全组/防火墙 -> VPS 系统 UFW -> sshd 服务
Si cualquier capa está bloqueada, SSH no conecta.
Por eso debes comprobar a la vez:
- Si el grupo de seguridad del proveedor cloud permite el puerto SSH
- Si la regla de entrada solo permite una IP concreta
- Si el VPS tiene vinculada la IPv4 / IPv6 pública correcta
- Si el UFW del sistema permite el mismo puerto
- Si sshd escucha realmente en ese puerto
Si los servicios de tu sitio tampoco son accesibles, consulta: Servicio de VPS iniciado pero no accesible desde Internet.
De ahora en adelante, no ejecutes directamente ufw enable. Un orden más seguro es:
sudo ufw status verbose
sudo ss -lntp | grep ssh
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --dry-run enable
sudo ufw enable
sudo ufw status numbered
Si usas un puerto SSH personalizado, por ejemplo 2222:
sudo ufw allow 2222/tcp
Luego abre otra ventana SSH para probar y cierra la conexión antigua solo cuando confirmes que la nueva funciona.
--dry-run no activa realmente las reglas, pero te permite ver qué haría UFW. No puede detectar todos los problemas por ti, pero es más seguro que activar el firewall directamente.
Si en el VPS corre Docker, mirar solo UFW puede inducir a error. Docker modifica las reglas de iptables, así que algunos puertos pueden quedar expuestos a Internet mediante el mapeo de puertos de Docker aunque UFW no parezca permitirlos.
Por ejemplo:
docker run -p 8080:80 nginx
Estos puertos no están necesariamente bajo el control total de UFW. En producción es mejor:
- Permitir solo los puertos necesarios en el grupo de seguridad del proveedor cloud
- Vincular los servicios Docker a
127.0.0.1siempre que sea posible - Enrutar el acceso externo de forma unificada mediante un proxy inverso Nginx / Caddy
- No mapear bases de datos, Redis ni paneles de administración directamente a Internet
Si tienes problemas de acceso anómalo a servicios Docker, consulta: Qué hacer si un contenedor Docker de VPS se reinicia constantemente.
Si SSH sigue en el 22 por defecto, normalmente no hay problema. Pero si cambiaste Port en /etc/ssh/sshd_config, puede que OpenSSH no te salve.
Lo seguro es permitir el puerto real:
sudo ufw allow 2222/tcp
Permitiste el 2222 en el sistema pero el panel cloud solo permite el 22: también dará timeout.
Ambos lados deben coincidir.
Los números de ufw status numbered cambian a medida que borras. Borra una a la vez y vuelve a consultar tras cada borrado:
sudo ufw status numbered
sudo ufw delete 3
sudo ufw status numbered
No borres varias seguidas basándote en números antiguos.
UFW es esencialmente una herramienta front-end; por debajo sigue siendo un sistema de reglas. Si además escribes iptables / nftables a mano, usas Docker y activas un firewall en la nube, el diagnóstico se complica.
Para un VPS normal, mantén primero la simplicidad: el firewall de la nube gestiona la entrada pública y UFW hace el permiso mínimo dentro del sistema.
Si ahora no puedes entrar por SSH, haz esto en orden:
- Mira si el error SSH es
timed outoPermission denied - Comprueba si el grupo de seguridad del proveedor cloud permite el puerto SSH
- Intenta iniciar sesión mediante Web Console / VNC Console
- Ejecuta
ufw status numbered - Usa
ss -lntp | grep sshpara encontrar el puerto SSH real - Permite el puerto real:
ufw allow 端口/tcp - Tras
ufw reload, abre otra ventana para probar - Si la consola tampoco funciona, entra en Rescue Mode para desactivar o reparar UFW
- Qué hacer si Fail2Ban bloquea un VPS por error: si sospechas que tu IP local está bloqueada y no es un problema de UFW, lee esto.
- Qué hacer si VPS SSH Permission denied: si SSH llega al servidor pero falla la autenticación, revisa claves, usuarios y permisos.
- Cómo usar el modo rescate de un VPS: si no puedes entrar en la consola y necesitas reparar el sistema desde un entorno de rescate.
Recuerda una última cosa: antes de activar UFW, permite primero el puerto SSH actual y mantén abierta una ventana SSH antigua. Activar el firewall más rápido no es más seguro: si el orden de las reglas es incorrecto, lo primero que bloquea suele ser a ti mismo.