Ubuntu 24.04: UFW te dejó fuera — recupera acceso SSH de forma segura desde la consola

enero 1, 2026 • febrero 3, 2026 • Lectura: 23 min • Views: 10

¿Te fue útil?

Activaste UFW (o lo “endureciste”), tu sesión SSH se cayó y ahora el puerto 22 parece estar de retiro silencioso. Aún puedes acceder al servidor vía la consola del hipervisor, consola serial del proveedor cloud, KVM/iDRAC o cualquier línea de vida fuera de banda que tengas. Bien. Eso es suficiente.

Esta es la forma solo por consola y segura para producción de recuperar SSH sin convertir tu firewall en papel higiénico. Diagnosticaremos primero, cambiaremos una cosa a la vez y dejaremos el sistema más fiable que cuando empezaste. Recuperar el acceso es solo la mitad del trabajo; no repetir el incidente es la otra mitad.

Reglas básicas: no empeores la situación

Cuando estás bloqueado, la tentación es “simplemente desactivar el firewall”. A veces ese es el palanca de emergencia correcta. Pero en producción debes ser deliberado, porque el mismo paso en falso que bloqueó SSH puede también abrir bases de datos, paneles de administración o servicios internos a Internet por accidente.

Este es el conjunto de reglas que uso:

La consola es tu plano de control. Mantén una sesión de consola abierta hasta que tengas una sesión SSH nueva confirmada. No cierres tu único paracaídas a mitad de salto.
Prefiere cambios aditivos. Añade una regla allow de alcance estrecho antes de eliminar reglas deny o restablecer UFW.
Valida la ruta de red. El firewall puede ser inocente. Interfaz equivocada, IP equivocada, sshd caído, problemas de enrutamiento, security groups del cloud—hay muchos sospechosos.
Haz los cambios reversibles. Usa comentarios, anota la hora, conserva una copia de la salida antes/después.

Una cita que tengo pegada al tablero mental: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. Se aplica al trabajo con firewalls más de lo que cualquiera quiere admitir.

Hechos interesantes y contexto histórico (sí, importa)

Los firewalls son tecnología antigua con nuevas envolturas. Saber qué hay debajo de UFW te ayuda a evitar depuraciones basadas en supersticiones.

UFW es un front-end, no un firewall. Escribe reglas al filtrador de paquetes del kernel—históricamente iptables, y cada vez más nftables en Ubuntu moderno.
iptables fue la opción por defecto durante años. Muchos tutoriales “clásicos” asumen cadenas y salidas de iptables que no coinciden con sistemas respaldados por nft.
nftables llegó para unificar IPv4/IPv6 y simplificar la gestión de reglas. Ya no es “nuevo”, pero muchos runbooks de operaciones siguen pretendiendo que sí.
El puerto por defecto de SSH (22) es una convención, no una ley. La seguridad por cambio de puerto es en su mayoría una táctica para reducir logs, no un control real de acceso.
Las políticas por defecto de UFW son un arma cargada. “Default deny incoming” es correcto para servidores, pero puede descartar patrones de tráfico existentes que olvidaste.
Los bloqueos por IPv6 son comunes. La gente permite IPv4 en 22 y olvida IPv6; clientes que prefieren IPv6 fallarán “misteriosamente”.
Los firewalls del cloud preceden a UFW en la ruta de tu petición. Security groups/NACLs pueden bloquearte mucho antes de que el paquete llegue a tu kernel.
El filtrado stateful es la razón por la que sesiones existentes a veces sobreviven. Conntrack puede mantener una sesión SSH establecida viva mientras las nuevas fallan—justo hasta que te desconectas y te arrepientes.
UFW puede estar habilitado con reglas incompletas. La herramienta no lee tu mente; hará cumplir “deny” mientras todavía estás escribiendo “allow”.

Guía de diagnóstico rápido

Esta es la ruta más rápida hacia el cuello de botella. Síguela en orden. La idea es evitar cambiar la capa equivocada.

Primero: confirma que sshd está vivo y escuchando donde crees

¿Está sshd en ejecución?
¿Está escuchando en el puerto esperado y en las direcciones esperadas (0.0.0.0 vs una IP concreta)?
¿Lo vinculaste accidentalmente a localhost o a una interfaz interna?

Segundo: confirma que la red del host es sana

¿La IP correcta está en la interfaz correcta?
¿Existe la ruta por defecto?
¿Puedes alcanzar tu gateway?

Tercero: confirma la capa de firewall que realmente está descartando paquetes

¿Cambios en security groups del cloud o firewall del proveedor?
¿Estado y reglas activas de UFW?
¿Las reglas subyacentes de nftables/iptables coinciden con la salida de UFW?

Cuarto: arregla con el menor radio de impacto

Añade un allow temporal desde tu IP de gestión (o subred).
Verifica que puedes abrir una nueva sesión SSH.
Luego limpia y endurece.

Verdad seca y divertida #1: El firewall nunca “te odia personalmente”; solo aplica lo que le dijiste, incluida la parte que no querías.

Recuperación desde consola: restablecer SSH de forma segura

Asumimos que tienes acceso por consola (físico, IPMI/iDRAC, consola del hipervisor, consola serial del cloud). Has iniciado sesión como un usuario con sudo o como root.

El enfoque más seguro es:

Confirma que sshd está en ejecución y escuchando.
Confirma qué dirección/puerto pretendes permitir (a menudo 22, a veces un puerto no estándar).
Añade la regla allow más estrecha posible en UFW para SSH desde una fuente de confianza.
Verifica con logs y un intento real de SSH.
Solo entonces elimina excepciones de emergencia o reglas más amplias.

Si no conoces tu IP de gestión (sucede), usa un allow temporal amplio en tu red interna o rango VPN, no 0.0.0.0/0, y pon un recordatorio para ajustarlo. “Temporal” sin seguimiento es como nacen los tickets de seguridad.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay comandos reales que puedes ejecutar. Cada tarea incluye: qué ejecutas, qué significa la salida y qué decisión tomas a continuación. Ejecútalos desde la consola en el host afectado.

Task 1: Confirma que estás en el host que crees

cr0x@server:~$ hostnamectl
 Static hostname: server
       Icon name: computer-server
         Chassis: server
      Machine ID: 7e3c0f0d3a1c4b3a9c1d2f3a4b5c6d7e
         Boot ID: 2b1d2c3e4f5a6b7c8d9e0f1a2b3c4d5e
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-36-generic
    Architecture: x86-64

Significado: Confirma la versión del SO y del kernel; Ubuntu 24.04 implica que UFW puede usar un backend nftables dependiendo del empaquetado/config.

Decisión: Procede asumiendo que la herramienta nft moderna podría ser relevante; no pegues a ciegas invocaciones de iptables de 2016.

Task 2: Comprueba si SSH está en ejecución

cr0x@server:~$ systemctl status ssh --no-pager
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-12-28 09:07:12 UTC; 21min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1123 (sshd)
      Tasks: 1 (limit: 18763)
     Memory: 3.6M (peak: 4.2M)
        CPU: 72ms
     CGroup: /system.slice/ssh.service
             └─1123 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Significado: sshd está en ejecución. Si estuviera inactivo/fallado, el firewall no sería tu problema principal.

Decisión: Si está inactivo, soluciona sshd primero (config, claves, puerto). Si está activo, continúa con los sockets de escucha.

Task 3: Verifica en qué puerto/dirección escucha sshd

cr0x@server:~$ ss -ltnp | grep -E '(:22|:2222)\s'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1123,fd=3))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=1123,fd=4))

Significado: SSH escucha en el puerto 22 en IPv4 e IPv6. Si ves solo 127.0.0.1:22 o una IP de interfaz específica, el acceso remoto puede fallar independientemente de UFW.

Decisión: Si la escucha parece correcta, céntrate en el firewall y el filtrado aguas arriba. Si no, corrige /etc/ssh/sshd_config (p. ej., ListenAddress, Port) y recarga.

Task 4: Confirma tu IP y la ruta por defecto

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens3             UP             203.0.113.10/24 2001:db8:1234:5678::10/64

cr0x@server:~$ ip route
default via 203.0.113.1 dev ens3 proto static
203.0.113.0/24 dev ens3 proto kernel scope link src 203.0.113.10

Significado: La interfaz está arriba, la IP existe y la ruta por defecto está presente.

Decisión: Si falta la ruta por defecto, arregla la red primero; UFW no arreglará “no hay ruta al host”.

Task 5: Comprueba si UFW está siquiera habilitado

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     DENY IN     Anywhere
22/tcp (v6)                DENY IN     Anywhere (v6)

Significado: UFW está activo y niega explícitamente SSH. Ese es tu bloqueo.

Decisión: No reinicies todo. Añade una regla allow estrecha por encima de este deny, o elimina el deny si fue accidental (después de validar qué lo creó).

Task 6: Inspecciona reglas numeradas para poder corregir quirúrgicamente

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     DENY IN     Anywhere
[ 2] 22/tcp (v6)                DENY IN     Anywhere (v6)

Significado: Puedes borrar por número de regla sin adivinar la sintaxis.

Decisión: Si el deny es obviamente erróneo, bórralo. Si no estás seguro, añade primero un allow desde la IP de gestión y luego borra.

Task 7: Añade un allow temporal desde tu IP de gestión (recomendado)

cr0x@server:~$ sudo ufw allow from 198.51.100.25 to any port 22 proto tcp comment 'TEMP: restore SSH from mgmt IP'
Rule added

Significado: Esto crea una regla allow más específica. UFW normalmente ordena reglas para que las específicas puedan preceder.

Decisión: Intenta hacer SSH desde 198.51.100.25. Si funciona, recuperaste el acceso con exposición mínima.

Task 8: Verifica el orden de reglas y la política efectiva

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    198.51.100.25
[ 2] 22/tcp                     DENY IN     Anywhere
[ 3] 22/tcp (v6)                DENY IN     Anywhere (v6)

Significado: El allow se evalúa antes que el deny para IPv4. IPv6 sigue denegado globalmente, lo cual está bien si tu vía de gestión es solo IPv4.

Decisión: Si tus clientes se conectan por IPv6, debes también permitir IPv6 desde tu prefijo de gestión o desactivar la preferencia IPv6 en el cliente (temporal) mientras arreglas reglas.

Task 9: Revisa los logs de UFW para paquetes SSH descartados

cr0x@server:~$ sudo journalctl -k -g 'UFW BLOCK' --since '10 minutes ago' --no-pager | tail -n 5
Dec 28 09:26:03 server kernel: [UFW BLOCK] IN=ens3 OUT= MAC=aa:bb:cc:dd:ee:ff SRC=203.0.113.50 DST=203.0.113.10 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=54321 DF PROTO=TCP SPT=51514 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

Significado: Los paquetes llegan al host y UFW los está bloqueando. Buena noticia: el enrutamiento aguas arriba y los firewalls del proveedor probablemente no sean el cuello de botella.

Decisión: Arregla las reglas de UFW, no los security groups del cloud.

Task 10: Confirma qué backend está activo (nftables vs iptables) e inspecciona reglas crudas

cr0x@server:~$ sudo ufw show raw | head -n 25
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
:ufw-logging-deny - [0:0]
:ufw-logging-allow - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-reject-forward - [0:0]
-A ufw-user-input -p tcp --dport 22 -s 198.51.100.25 -j ACCEPT
-A ufw-user-input -p tcp --dport 22 -j DROP
COMMIT

Significado: Ves la lógica real de accept luego drop. Esa es la verdad en disco.

Decisión: Si la vista cruda no coincide con ufw status, puede que tengas aplicación parcial o que otro gestor de firewall interfiera. Investiga antes de añadir más reglas.

Task 11: Elimina la regla deny accidental (arreglo quirúrgico)

cr0x@server:~$ sudo ufw delete 2
Deleting:
 allow 22/tcp
Proceed with operation (y|n)? y
Rule deleted

Significado: Eliminaste la regla #2 según la numeración actual. (Sí, la numeración cambia al añadir/eliminar. Siempre vuelve a comprobar.)

Decisión: Si tu intención es permitir SSH de forma general, reemplaza el deny por un allow a tu CIDR de administración, VPN o bastión—no “Anywhere” a menos que tengas una buena razón y otros controles.

Task 12: Establece una política sensata para SSH (elige tu veneno, pero elige uno)

Opción A: permitir SSH solo desde una subred de gestión (mejor para la mayoría de servidores de producción):

cr0x@server:~$ sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp comment 'SSH from mgmt subnet'
Rule added

Opción B: permitir SSH desde cualquier lugar (aceptable para bastiones con autenticación fuerte y monitorización):

cr0x@server:~$ sudo ufw allow 22/tcp comment 'SSH'
Rule added

Significado: Estás expresando intención. UFW está más contento cuando las reglas reflejan patrones de acceso reales.

Decisión: Si eliges “Anywhere”, debes compensar con configuración SSH fuerte (solo claves, sin login root, posiblemente controles tipo fail2ban y buenos logs).

Task 13: Maneja IPv6 explícitamente (porque tu cliente lo hará)

cr0x@server:~$ sudo ufw status verbose | grep -E 'IPv6|v6'
22/tcp (v6)                DENY IN     Anywhere (v6)

cr0x@server:~$ sudo ufw allow from 2001:db8:9999::/48 to any port 22 proto tcp comment 'SSH from mgmt IPv6'
Rule added

Significado: Las reglas IPv6 son entradas separadas. Si usas IPv6, trátalo como de primera clase.

Decisión: Si no usas IPv6 en absoluto, no dejes políticas semicongeladas. O desactívala en el nivel SO/red intencionalmente (con un plan de despliegue) o bloquéala de forma consistente.

Task 14: Valida con una conexión SSH real, luego verifica logs

cr0x@server:~$ sudo journalctl -u ssh --since '10 minutes ago' --no-pager | tail -n 8
Dec 28 09:31:44 server sshd[1890]: Connection from 198.51.100.25 port 55312 on 203.0.113.10 port 22 rdomain ""
Dec 28 09:31:45 server sshd[1890]: Accepted publickey for admin from 198.51.100.25 port 55312 ssh2: ED25519 SHA256:Zk1...
Dec 28 09:31:45 server sshd[1890]: pam_unix(sshd:session): session opened for user admin(uid=1000) by (uid=0)

Significado: La conexión llegó a sshd y se autenticó. Estás de vuelta en marcha.

Decisión: Solo ahora deberías eliminar excepciones temporales y finalizar la política.

Task 15: Si debes, haz un disable/enable controlado de UFW

cr0x@server:~$ sudo ufw disable
Firewall stopped and disabled on system startup

cr0x@server:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Significado: Este es el “gran palanca”. Puede sacarte del apuro, pero también puede abrir todo el host brevemente, dependiendo de otras capas.

Decisión: Úsalo solo cuando entiendas la exposición y tengas controles compensatorios (firewall del cloud, red privada, ventana de mantenimiento). Prefiere correcciones de reglas dirigidas.

Task 16: Confirma persistencia e integración con systemd

cr0x@server:~$ systemctl is-enabled ufw
enabled

cr0x@server:~$ sudo ufw status
Status: active

Significado: UFW se aplicará al arranque y está activo ahora.

Decisión: Si está deshabilitado, decide si esa es una postura intencional. “Lo deshabilitamos para recuperarnos y lo olvidamos” no es una estrategia, es un incidente futuro.

Tres micro-historias corporativas desde el campo

1) Incidente causado por una suposición errónea: “Allow SSH” no significó lo que pensaban

Una empresa mediana gestionaba una flota de servidores Ubuntu repartidos entre subredes públicas y privadas. El equipo tenía una costumbre: mantener SSH abierto solo al rango de la VPN corporativa. Razonable. Un día, durante una ola de actualizaciones de SO, un ingeniero decidió “estandarizar reglas de firewall” y desplegó cambios de UFW mediante automatización.

El cambio parecía seguro en la revisión de código: añadía ufw allow 22/tcp y luego una regla deny-all. La suposición fue que “deny-all” solo afectaría puertos no listados, y que SSH seguiría abierto. Lo que se pasó por alto: un rol antiguo también añadía deny 22/tcp en hosts que debían ser accesados solo a través de un bastión. Dos fuentes de verdad. Una amigable, otra hostil.

Durante el despliegue, las sesiones SSH existentes permanecieron vivas por el seguimiento de estado, así que nadie lo notó. Luego un script de mantenimiento cerró sesiones inactivas. De repente, las nuevas sesiones fallaron en una parte de la flota. El NOC vio “SSH down” y lo trató como una caída de red. No lo era. Era software funcionando exactamente como se le indicó, aplicando políticas contradictorias.

La recuperación fue lenta porque el equipo intentó arreglarlo desde sus portátiles primero. No pudieron entrar. Finalmente usaron las consolas del proveedor cloud para añadir una regla allow desde una IP de gestión, exactamente como hicimos arriba. La solución real fue aburrida: eliminar la regla deny duplicada, añadir comentarios y hacer que un solo módulo fuera dueño de las reglas SSH. La lección del postmortem fue aún más aburrida: “las suposiciones no son tests”.

2) Optimización que salió mal: reducir el conjunto de reglas sin entender la evaluación

Otra organización tenía un equipo de seguridad que detestaba “reglas desordenadas”. Pidieron al equipo de plataforma que “redujera el número de entradas del firewall” y quitaran “allow de IPv6 redundantes”. El equipo de plataforma cumplió rápido. Demasiado rápido.

Eliminaron allows explícitos de IPv6 con la idea de que “nadie usa IPv6” y para reducir ruido en auditoría. Pero un subconjunto de portátiles corporativos prefería IPv6, y su cliente VPN filtraba rutas IPv6 de una forma que hacía que los clientes intentaran v6 primero. Resultado: fallos intermitentes de SSH según el SO del cliente, la red y el orden de respuesta DNS. Los tickets fueron una obra maestra de confusión.

Luego vino la “optimización”: para mantenerlo simple, alguien reemplazó una regla allow-from específica por un allow amplio y confió en la limitación de velocidad de SSH a nivel de aplicación. Redujo el número de reglas. También aumentó la exposición y el volumen de logs, y hizo que los intentos de fuerza bruta fueran más visibles para todo el mundo río abajo.

La solución final tampoco fue glamorosa: restaurar reglas IPv6 explícitas, mantener listas de allow ajustadas y usar logging de UFW en low/medium más agregación centralizada de logs. El equipo aprendió que “menos reglas” no es inherentemente mejor. Las reglas correctas sí lo son.

3) Práctica aburrida pero correcta que salvó el día: acceso por consola y despliegues escalonados

Una empresa de servicios financieros tenía una costumbre que desearía que todos copiaran: cada servidor de producción tenía acceso fuera de banda probado, y cada cambio de firewall se hacía en tres pasos. Paso uno: añadir la nueva regla allow. Paso dos: verificar conectividad desde al menos dos redes. Paso tres: eliminar la regla vieja. La secuencia suena pedante. También es la razón por la que dormían tranquilos.

Una noche, un ingeniero endureció los defaults de UFW en un grupo de hosts y eliminó accidentalmente una subred de gestión de la lista de allows. Lo notaron en minutos porque su prueba de humo (un simple intento de conexión SSH) falló en staging. La misma automatización habría afectado producción a continuación.

Incluso si hubiera impactado producción, el playbook requería mantener la sesión de consola abierta y tener un comando de rollback listo. No tuvieron que usarlo, porque el despliegue escalonado detuvo el radio de impacto en “unos pocos servidores de prueba”. Sin heroicidades. Sin puentes de pánico. Sin ejecutivos preguntando por qué “un cambio de firewall puede tumbar ingresos”.

Arreglaron la configuración, volvieron a ejecutar la prueba y siguieron. Lo más impresionante fue lo poco interesante que fue el incidente. Ese es el objetivo.

Listas de verificación / plan paso a paso

Checklist de recuperación (desde consola, riesgo mínimo)

Mantén la consola abierta. No la cierres hasta que tengas una nueva sesión SSH.
Confirma sshd en ejecución: systemctl status ssh.
Confirma escucha: ss -ltnp | grep sshd.
Confirma red del host: ip -br addr, ip route.
Revisa estado de UFW: ufw status verbose.
Añade allow estrecho: ufw allow from <mgmt-ip> to any port 22 proto tcp.
Verifica orden de reglas: ufw status numbered.
Intenta SSH desde la IP de gestión.
Confirma en logs: journalctl -u ssh y opcionalmente UFW kernel blocks.
Elimina reglas deny accidentales.
Decide la política final de SSH: allow-list vs anywhere; incluye decisión sobre IPv6.
Elimina allowances TEMPORALES y añade comentarios a las reglas permanentes.

Checklist de estabilización (después de recuperar acceso)

Registra la salida “antes/después” del estado de UFW en tu ticket.
Confirma que las reglas del firewall del cloud/security group coinciden con tu intención.
Confirma endurecimiento de SSH: solo claves, desactivar login root, métodos de autenticación sensatos.
Asegura que puedes alcanzar la máquina por consola fuera de banda (y que las credenciales funcionan).
Programa un seguimiento para ajustar cualquier allow temporal amplio.

Verdad seca y divertida #2: Nada dice “empresa” como una regla de firewall llamada TEMP de hace dos trimestres que todos temen eliminar.

Errores comunes: síntomas → causa raíz → solución

Síntoma: SSH se agota; UFW muestra “active” pero existe “allow 22/tcp”.
Causa raíz: Permitiste IPv4 pero te conectas por IPv6 (o viceversa), o permitiste la IP/rango equivocado de interfaz.
Solución: Añade reglas v6 explícitas para tu prefijo de gestión, o confirma que el cliente use IPv4; verifica con ss y ufw status verbose.
Síntoma: SSH “No route to host” o fallo inmediato; UFW no muestra nada en logs.
Causa raíz: Bloqueo aguas arriba (security group del cloud, NACL), problema de enrutamiento o IP/DNS pública equivocada.
Solución: Verifica el firewall del proveedor y la IP de la instancia; comprueba ip route y la consola del proveedor. No sigas editando UFW cuando los paquetes nunca llegan.
Síntoma: Sesiones SSH existentes funcionaron hasta que se desconectaron; nuevas sesiones fallan.
Causa raíz: Firewall stateful permitió conexiones establecidas; las nuevas entrantes están bloqueadas por la política.
Solución: Añade una regla allow para nuevas conexiones. No confundas “sigo conectado” con “está bien”.
Síntoma: UFW dice que la regla está presente, pero el comportamiento no cambia.
Causa raíz: Otro gestor de firewall sobreescribió reglas, UFW no aplicó correctamente, o estás depurando el host/namespace equivocado.
Solución: Inspecciona ufw show raw, busca otros servicios (contenedores, orquestación) y confirma que estás en la máquina correcta (hostnamectl).
Síntoma: SSH llega al host pero la autenticación falla tras cambios en UFW.
Causa raíz: Cambios coincidentes en sshd config, permisos de claves o problemas PAM; UFW recibe la culpa por ser el último cambio.
Solución: Mira journalctl -u ssh, valida /etc/ssh/sshd_config y prueba localmente con ssh localhost.
Síntoma: Permitiste el puerto 22, pero SSH está en 2222 (o viceversa).
Causa raíz: Desajuste entre la configuración de sshd y las reglas del firewall; a veces causado por guías de endurecimiento.
Solución: Confirma el puerto de escucha con ss -ltnp; actualiza UFW en consecuencia: ufw allow 2222/tcp.
Síntoma: Estás seguro de que permitiste la IP de tu oficina, pero todavía no puedes conectar.
Causa raíz: Tu IP de origen cambió (ISP doméstico, hotspot móvil, salida de VPN).
Solución: Confirma tu IP de salida actual desde un servicio conocido o desde herramientas corporativas; luego permite esa IP temporalmente. Prefiere VPN/bastión para egress estable.
Síntoma: UFW enable advierte que puede interrumpir SSH, y luego lo hace.
Causa raíz: Habilitaste UFW antes de añadir la regla allow, o la política default incoming se aplicó.
Solución: Desde la consola, añade reglas allow primero; luego habilita. Para cambios remotos, programa una ventana de mantenimiento o usa un mecanismo de rollback temporizado.

Evitar el próximo bloqueo (sin inventos)

Una vez recuperado el acceso, tómate cinco minutos para reducir la probabilidad de repetición. El objetivo no es teatro de seguridad maximalista; es acceso controlado que no se rompa durante el trabajo rutinario.

1) Haz el acceso SSH explícito y estrecho

Elige uno de estos patrones:

Modelo bastión: Solo los hosts bastión aceptan SSH desde Internet; todos los demás servidores permiten SSH solo desde la subred del bastión.
Modelo VPN: Los servidores permiten SSH solo desde el pool de direcciones VPN.
Modelo subred de gestión: Red administrativa dedicada (on-prem o cloud) tiene acceso; el resto no.

No mezcles patrones a la ligera. Los patrones mixtos son la forma en que acabas con reglas allow/deny contradictorias y una sesión de consola a medianoche.

2) Trata IPv6 como real

Si tu host tiene una dirección IPv6 global, Internet puede alcanzarlo por IPv6 a menos que filtros aguas arriba digan lo contrario. Decide de forma deliberada:

Si usas IPv6, escribe reglas v6 allow para las mismas fuentes que IPv4.
Si no usas IPv6, o bien desactívala intencionalmente (con pruebas) o mantenla por defecto-deny y asegúrate de que tus clientes no la prefieran inesperadamente.

3) Mantén las reglas de UFW legibles

Usa comentarios. El tú del futuro es un extraño que no merece sufrir.

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    198.51.100.0/24             # SSH from mgmt subnet
[ 2] 80/tcp                     ALLOW IN    Anywhere                    # HTTP
[ 3] 443/tcp                    ALLOW IN    Anywhere                    # HTTPS

Decisión: Si tus reglas no cuentan una historia, reescríbelas hasta que lo hagan.

4) Añade un método de rollback para cambios remotos de firewall

En entornos maduros, los cambios de firewall se aplican con un rollback automático si las pruebas de conectividad fallan. Puedes aproximarlo sin herramientas sofisticadas mediante despliegues en etapas y verificación desde una sesión separada, o usando programadores de tareas para revertir si no se cancela. Si manejas producción, invierte en un mecanismo real de cambios en lugar de confiar en el valor personal.

Preguntas frecuentes

1) ¿Debería ejecutar `ufw reset`?

Sólo si estás de acuerdo con perder toda tu política de firewall y reconstruirla. Es un instrumento contundente. Prefiere eliminar o sobreescribir la regla específica que bloquea SSH.

2) ¿Por qué mi sesión SSH existente siguió activa cuando UFW bloqueó SSH?

Filtrado stateful. Las conexiones establecidas pueden permanecer permitidas mientras las nuevas entrantes son denegadas. Es útil hasta que te desconectas y descubres que no puedes volver a entrar.

3) Permití `22/tcp` pero aún no puedo conectar. ¿Cuál es la razón habitual?

Desajuste IPv6, IP de origen equivocada, reglas de firewall del cloud aguas arriba, o sshd que no escucha en la interfaz que estás usando. Valida en ese orden.

4) ¿Cómo sé si los paquetes están llegando al servidor?

Revisa los logs del kernel en busca de UFW BLOCK. Si ves bloqueos, los paquetes están llegando y UFW los está descartando. Si no ves nada, sospecha filtrado aguas arriba o problemas de enrutamiento antes de UFW.

5) ¿Es seguro permitir SSH desde cualquier lugar temporalmente?

A veces es la única medida práctica, pero no es “seguro”. Si lo haces, compensa: solo autenticación por claves, sin login root, y elimina el allow amplio inmediatamente después de recuperar el control.

6) ¿Ubuntu 24.04 usa nftables o iptables con UFW?

UFW es una interfaz; el mecanismo subyacente puede variar. No asumas. Usa ufw show raw y las herramientas del sistema para entender qué se aplica realmente.

7) ¿Por qué UFW advierte que al habilitarlo puede interrumpir conexiones SSH existentes?

Porque puede hacerlo. Si la política incoming por defecto pasa a deny y no has permitido SSH correctamente, UFW bloqueará nuevas conexiones y potencialmente interrumpirá flujos existentes dependiendo de los cambios en las reglas.

8) ¿Cuál es la configuración permanente más segura para SSH en servidores accesibles desde Internet?

Un modelo de bastión o VPN con rangos allow listados, autenticación solo por claves y logging estricto. Si SSH debe ser público, trátalo como una API pública y móntoreala en consecuencia.

9) Arreglé IPv4 pero IPv6 todavía falla. ¿Es un problema?

Si tus usuarios o automatizaciones prefieren IPv6, sí. Muchos clientes intentarán IPv6 primero. O permite IPv6 correctamente o desactívalo intencionalmente con un plan probado.

Conclusión: próximos pasos que realmente debes hacer

Recuperaste SSH de la forma correcta: desde consola, con allowances estrechos y con evidencia de logs en lugar de intuiciones. Ahora termina el trabajo.

Elimina cualquier regla TEMP que añadiste durante la recuperación y reemplázala por la política que pretendes (VPN/bastión/subred de gestión).
Haz de IPv6 una decisión deliberada—o dale soporte correctamente o bloquéalo de forma consistente.
Escribe el runbook mínimo para tu equipo: el orden de diagnóstico rápido, los comandos UFW exactos y dónde reside el acceso por consola.
Haz despliegues de firewall por etapas en el futuro: añadir allow → verificar desde dos redes → eliminar reglas viejas. Lo aburrido funciona.