Debian 13: puerto SSH cambiado — arregla el orden firewall + sshd sin quedarte fuera (caso #27)

Caso #27: qué falló (y por qué es común)

El patrón se ve así: alguien cambia SSH del puerto 22 a otro número—digamos 2222—por “seguridad”.
Editan /etc/ssh/sshd_config, recargan el servicio y luego cierran el puerto 22 en el firewall.
El siguiente intento de inicio de sesión falla, y ahora el único camino de vuelta es consola fuera de banda, iLO/DRAC, consola serial en la nube, o un ticket a alguien que lo tenga.

En Debian 13, la superficie de riesgo es un poco mayor que en sistemas antiguos porque:
los directorios de include (sshd_config.d) son comunes, el comportamiento de las unidades de systemd importa más, y los firewalls son cada vez más basados en nftables incluso cuando el administrador piensa “iptables.”
El modo de fallo humano es consistente: haces dos cambios (sshd + firewall) y no pruebas ninguno en el orden correcto.

La solución no es “ten cuidado”. La solución es un procedimiento determinista: ejecuta un puerto paralelo temporalmente, abre el firewall primero, verifica el socket en escucha,
verifica que la autenticación funcione en el puerto nuevo y luego retira el puerto viejo. Preferiblemente manteniendo una segunda sesión abierta todo el tiempo.

Hechos y contexto: por qué los puertos SSH y los firewalls nos siguen mordiendo

• SSH no siempre dominó la administración remota. Antes de que fuese el predeterminado, los inicios remotos eran a menudo Telnet o rlogin—sin cifrar y trágicamente confiados.
• El puerto 22 es convención, no destino. Está asignado por IANA para SSH, pero sshd puede enlazarse a cualquier puerto TCP que le indiques.
• “Seguridad cambiando el puerto” es mayormente ruido. Reduce escaneos de fondo, no ataques dirigidos. Puede ser útil para higiene de logs, pero no lo confundas con control de acceso.
• OpenSSH popularizó valores sensatos por defecto. OpenSSH se convirtió en la implementación estándar en Linux/BSD, y la mayoría del “comportamiento SSH” que los administradores asumen es realmente comportamiento de OpenSSH.
• Debian se movió hacia snippets de include. El patrón de Include /etc/ssh/sshd_config.d/*.conf facilita la gestión de configuración—y hace los errores de override más sutiles.
• nftables reemplazó iptables en la ruta del kernel. Incluso si ejecutas comandos iptables, el conjunto de reglas subyacente puede ser nftables (o podrías estar editando la cosa equivocada por completo).
• systemd cambia el modo de fallo. Una recarga puede tener éxito mientras un reinicio posterior falla si la configuración tiene un problema latente; systemd también hace que “¿qué unidad está activa?” importe.
• Los firewalls de nube son separados de los firewalls del host. Puedes abrir nftables perfectamente y aun así estar bloqueado por un security group o firewall del proveedor.

Una cita para llevar en el bolsillo, porque es aburrida y correcta:
La esperanza no es una estrategia.
—idea parafraseada a menudo atribuida a operadores con mentalidad de confiabilidad

Tu modelo mental: sshd, systemd y “quién posee el puerto”

Cambiar el puerto SSH no es una sola configuración. Es una cadena:
cliente → ruta de red → firewall de la nube → firewall del host → escucha de sshd → autenticación.
Si algún eslabón se rompe, el usuario experimenta “SSH no funciona”. Tu trabajo es identificar qué eslabón falló, rápido, sin empeorar la situación.

Capas de configuración de sshd: el orden de archivos importa

Debian usa comúnmente /etc/ssh/sshd_config más uno o varios snippets bajo /etc/ssh/sshd_config.d/.
La configuración efectiva es el resultado de leer el archivo principal y luego aplicar los includes en orden léxico.
Eso significa que 00-foo.conf puede ser anulado por 99-bar.conf.
“Cambié Port en sshd_config” no significa nada si un include posterior lo vuelve a fijar.

Puertos múltiples: tu carta de escape

OpenSSH soporta múltiples directivas Port. Si especificas dos puertos, sshd escucha en ambos.
Esta es la forma más segura de migrar: mantiene 22 para la automatización existente, añade 2222 para el acceso nuevo y luego elimina 22 más tarde.

Orden del firewall: abrir primero, cerrar al final

Cada sistema de firewall tiene un concepto de orden de evaluación de reglas.
Pero la verdad operacional es más simple: si necesitas mantener el acceso, añades reglas allow para el puerto nuevo
antes de eliminar las reglas allow para el puerto viejo. Cada vez. Sin excepciones por “cambios rápidos”.

Chiste #1: Cambiar puertos SSH sin una segunda sesión es como actualizar firmware un viernes—puedes hacerlo, pero estás audicionando para consecuencias.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el flujo “Necesito respuestas en cinco minutos”. No improvises. Sigue la cadena.

Primero: ¿sshd está escuchando donde crees?

• Comprueba sockets en escucha (ss).
• Comprueba la configuración efectiva de sshd (sshd -T).
• Comprueba el estado del servicio y los logs recientes (systemctl, journalctl).

Segundo: ¿el firewall del host lo permite?

• Identifica el sistema de firewall realmente en uso: nftables, ufw o iptables legacy.
• Confirma que exista una regla allow para el puerto nuevo desde tus redes origen.
• Confirma que no haya una regla deny posterior que lo sombreé.

Tercero: ¿algo fuera del host te está bloqueando?

• Reglas de seguridad del cloud / firewall del proveedor.
• ACL de red, perímetro corporativo, políticas de VPN.
• Balanceador de carga o expectativa de bastión (desajuste de puerto).

Tareas prácticas: 14 comandos, salidas y decisiones

Estos no son “ejecuta comandos por diversión”. Cada uno responde a una pregunta específica y lleva a una decisión.
Ejecútalos desde una sesión SSH existente si aún la tienes, y mantén esa sesión abierta hasta el final.

Tarea 1 — Confirma la versión de Debian y supuestos del entorno

cr0x@server:~$ cat /etc/debian_version
13.0

Qué significa: Estás en Debian 13. Los valores por defecto y empaquetado (incluyendo el comportamiento de include de sshd) deberían coincidir con las expectativas actuales.
Decisión: Procede asumiendo OpenSSH + defaults de systemd; aun así verifica los includes.

Tarea 2 — Comprueba si sshd está ejecutándose y cómo lo ve systemd

cr0x@server:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 08:41:12 UTC; 2h 11min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 914 (sshd)
      Tasks: 1 (limit: 19190)
     Memory: 7.2M
        CPU: 1.184s
     CGroup: /system.slice/ssh.service
             └─914 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Qué significa: sshd está activo.
Decisión: Si no está activo, no toques firewalls aún—arregla sshd primero.

Tarea 3 — Ver en qué puertos está realmente escuchando 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=914,fd=3))
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=914,fd=4))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=914,fd=5))
LISTEN 0      128             [::]:2222         [::]:*    users:(("sshd",pid=914,fd=6))

Qué significa: Estás en el estado seguro: sshd escucha en ambos puertos, IPv4 e IPv6.
Decisión: Ahora puedes trabajar en las reglas de firewall para 2222 sin arriesgar el acceso.

Tarea 4 — Imprime la configuración efectiva de sshd (no lo que crees que configuraste)

cr0x@server:~$ sudo sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication)\b'
port 22
port 2222
listenaddress 0.0.0.0
listenaddress ::
passwordauthentication no
pubkeyauthentication yes

Qué significa: La configuración efectiva incluye ambos puertos; la autenticación por contraseña está deshabilitada (bien).
Decisión: Si el puerto que quieres falta aquí, detente y corrige el orden de includes/sintaxis antes de tocar el firewall.

Tarea 5 — Inspecciona el orden de includes y detecta overrides

cr0x@server:~$ grep -nE '^(Include|Port)\b' /etc/ssh/sshd_config
12:Include /etc/ssh/sshd_config.d/*.conf
18:Port 22

cr0x@server:~$ ls -la /etc/ssh/sshd_config.d/
total 16
drwxr-xr-x 2 root root 4096 Dec 30 08:40 .
drwxr-xr-x 4 root root 4096 Dec 30 08:10 ..
-rw-r--r-- 1 root root   26 Dec 30 08:40 10-ports.conf
-rw-r--r-- 1 root root  124 Dec 30 08:10 50-hardening.conf

cr0x@server:~$ cat /etc/ssh/sshd_config.d/10-ports.conf
Port 22
Port 2222

Qué significa: El cambio de puerto está en un snippet. Eso es mantenible y se lleva mejor con la gestión de configuración.
Decisión: Prefiere un archivo snippet dedicado para puertos; evita editar defaults gestionados por el proveedor a menos que los controles.

Tarea 6 — Valida la sintaxis de la configuración de sshd antes de recargar/reiniciar

cr0x@server:~$ sudo sshd -t

Qué significa: No hay salida significa que la sintaxis está OK.
Decisión: Si obtienes errores, no reinicies. Corrige la configuración hasta que sshd -t quede limpia.

Tarea 7 — Identifica la herramienta de firewall a cargo (no adivines)

cr0x@server:~$ sudo systemctl is-active nftables
inactive

cr0x@server:~$ sudo systemctl is-active ufw
active

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

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    10.20.0.0/16

Qué significa: UFW está imponiendo la política entrante; el servicio nftables no está activo por separado.
Decisión: Gestiona los cambios de puerto SSH a través de UFW, no con comandos nft ad-hoc que puedan no persistir bajo UFW.

Tarea 8 — Añade una regla allow del firewall para el nuevo puerto, acotada a tu origen

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 2222 proto tcp
Rule added

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

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    10.20.0.0/16
[ 2] 2222/tcp                   ALLOW IN    10.20.0.0/16

Qué significa: Nuevo puerto permitido desde la misma red que el anterior.
Decisión: No permitas 2222 desde “Anywhere” a menos que tengas una razón. Si lo haces, registra y aplica limitación de tasa al menos.

Tarea 9 — Confirma que el kernel ve la autorización de tráfico (vista nft bajo UFW)

cr0x@server:~$ sudo nft list ruleset | grep -nE 'tcp dport (22|2222)' | head
187: tcp dport 22 ct state new counter accept
190: tcp dport 2222 ct state new counter accept

Qué significa: Bajo el capó, UFW pobló reglas nftables permitiendo ambos puertos.
Decisión: Si no ves 2222 aquí, tus cambios en UFW no se aplicaron o otra capa de firewall está sobrescribiendo.

Tarea 10 — Prueba el puerto nuevo desde dentro del host (chequeo de cordura)

cr0x@server:~$ ssh -p 2222 -o BatchMode=yes -o ConnectTimeout=3 localhost 'echo ok'
ok

Qué significa: El listener sshd en 2222 acepta conexiones y tu autenticación basada en claves funciona.
Decisión: Si localhost falla, el acceso externo también fallará. Arregla sshd/auth antes de cambiar cualquier perímetro.

Tarea 11 — Prueba el puerto nuevo desde una máquina remota antes de cerrar el 22

cr0x@server:~$ sudo journalctl -u ssh -n 5 --no-pager
Dec 30 10:51:07 server sshd[3842]: Accepted publickey for cr0x from 10.20.14.9 port 51788 ssh2: ED25519 SHA256:3kz...
Dec 30 10:51:07 server sshd[3842]: pam_unix(sshd:session): session opened for user cr0x(uid=1000) by (uid=0)
Dec 30 10:51:10 server sshd[3842]: pam_unix(sshd:session): session closed for user cr0x

Qué significa: Alguien (esperemos que tú) se conectó con éxito recientemente. Los logs confirman la aceptación, la IP origen y el método de autenticación.
Decisión: No cierres el puerto 22 hasta ver un login exitoso en 2222 desde la red que realmente usas.

Tarea 12 — Comprueba supuestos del firewall del proveedor (Linux no puede arreglar esto)

cr0x@server:~$ sudo ss -ltnp | grep ':2222 '
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=914,fd=4))

Qué significa: El host está escuchando. Si las conexiones remotas aún hacen timeout, sospecha controles aguas arriba.
Decisión: Revisa firewall del proveedor/grupo de seguridad/equivalentes NACL y abre TCP/2222 desde tus rangos origen. No asumas que el firewall del host es la única puerta.

Tarea 13 — Recarga sshd de forma segura; evita reiniciar cuando no sea necesario

cr0x@server:~$ sudo systemctl reload ssh

cr0x@server:~$ systemctl show -p ActiveState,SubState,ExecMainStatus ssh
ActiveState=active
SubState=running
ExecMainStatus=0

Qué significa: La recarga no mató tu listener.
Decisión: Prefiere reload para cambios de configuración. Restart es más ruidoso y más propenso a fallos si algo está mal.

Tarea 14 — Retira el puerto 22 solo después de verificar el éxito, luego confirma sockets en escucha

cr0x@server:~$ sudo sed -i 's/^Port 22$/# Port 22/' /etc/ssh/sshd_config.d/10-ports.conf

cr0x@server:~$ sudo sshd -t

cr0x@server:~$ sudo systemctl reload ssh

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

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

Qué significa: sshd ya no se enlaza a 22, y el firewall ya no lo permite.
Decisión: Haz esto solo después de haber probado que 2222 funciona desde fuera de la máquina. Mantén tu sesión actual abierta de todos modos, porque te gusta dormir.

Listas de verificación / plan paso a paso: cambia el puerto sin pánico

Checklist pre-vuelo (antes de tocar nada)

• Tener dos rutas de acceso: dos sesiones SSH, o SSH + acceso por consola (consola serial en la nube, IPMI, etc.). Si tienes solo un camino, detente.
• Conocer las capas de firewall: firewall del proveedor + firewall del host + ACLs de red corporativa. Anota dónde debes abrir el puerto.
• Confirmar modo de autenticación: si deshabilitas auth por contraseña, verifica que la autenticación por clave funcione ahora. No combines “cambio de puerto” con “endurecimiento de auth” en una sola operación.
• Decidir el alcance: “permitir desde subnet VPN solamente” es mejor que “permitir desde cualquier lugar” a menos que estés construyendo un bastión público intencionalmente.
• Elegir un puerto con intención: no 2222 porque todos lo usan, a menos que disfrutes de logs ruidosos. Escoge un puerto que encaje con tu modelo de operaciones.

Plan de ejecución (el orden que previene quedar bloqueado)

1. Añade el nuevo puerto en sshd como listener adicional. No retires 22 todavía.
2. Valida la configuración: sshd -t y sshd -T | grep ^port.
3. Recarga sshd (no reinicies) y verifica que ss muestre ambos puertos en escucha.
4. Abre el nuevo puerto en el firewall del host. Verifica reglas a nivel kernel (vista nft/iptables) para evitar situaciones donde “UFW dice sí pero el kernel dice no”.
5. Abre el nuevo puerto en firewalls aguas arriba (cloud SG, firewall del proveedor, ACLs corporativas) antes de probar de forma remota.
6. Prueba desde la red que realmente usas. Confirma que los logs muestren una conexión aceptada en el puerto nuevo.
7. Actualiza la automatización y herramientas: inventario de Ansible, configs de bastión, comprobaciones de monitorización, hosts de salto y cualquier runbook humano.
8. Solo entonces elimina el puerto 22 de sshd y del firewall, en ese orden: sshd deja de escuchar y luego el firewall deja de permitirlo.
9. Verificación postcambio: inicio de sesión remoto en el puerto nuevo, confirma que 22 está cerrado (connection refused o filtered), y vigila logs por fallos.

Plan de reversión (lo necesitarás en algún momento)

• Si el puerto nuevo falla pero aún tienes una sesión existente: vuelve a añadir Port 22, recarga sshd, vuelve a añadir la regla allow para 22 y vuelve a probar.
• Si estás bloqueado: usa acceso por consola, revierte el snippet de sshd, recarga y luego arregla el firewall. Si no tienes acceso por consola, felicitaciones—descubriste por qué el acceso por consola es un requisito.

Chiste #2: Los firewalls son como la política de oficina—todos se olvidan de que existen hasta que te impiden hacer tu trabajo.

Tres mini-historias corporativas (cómo los equipos realmente se queman)

Incidente: la suposición equivocada (“abrimos el puerto”)

Un equipo de plataforma rotó SSH de 22 a 22022 en una flota. Tenían un estándar: modificar sshd y luego actualizar UFW.
El cambio se veía limpio en su herramienta de configuración. La ventana de despliegue fue tranquila. Entonces el soporte empezó a reportar que un subconjunto de hosts eran inalcanzables.

El ingeniero on-call revisó una de las máquinas “muertas” por consola fuera de banda y encontró sshd escuchando en 22022 exactamente como se pretendía.
UFW también mostraba una regla allow para 22022. Ese fue el momento en que subió la confianza de todos—y no debería haber sido así.

El eslabón que faltaba era aguas arriba: esas máquinas vivían en un proyecto de nube distinto con una línea base de firewall del proveedor más estricta.
El puerto 22 tenía una regla explícita allow desde la VPN corporativa, mientras que todos los demás puertos requerían un proceso de excepción separado.
La herramienta de configuración no tenía visibilidad de esa capa, así que “abrimos el puerto” solo era verdad dentro de la VM.

La solución fue mundana: coordinar cambios en el firewall del proveedor y hacer el despliegue por segmento de red.
La lección permanente fue más aguda: trata cada cambio de puerto como una solicitud de cambio intercapas, no como un ajuste local.

Optimización que salió mal: “reiniciar es más limpio que recargar”

Otro equipo detestaba la deriva de configuración. Su guía interna insistía en reiniciar servicios tras cualquier cambio de config.
Para sshd, usaban systemctl restart ssh como regla rígida. Sonaba disciplinado.

Durante una migración de puerto, un typo inocente se coló en un snippet de include—una opción inválida colocada bajo el bloque Match equivocado.
El error de sintaxis no entró en efecto hasta el reinicio. La recarga también habría fallado, pero el reinicio causó un problema mayor: sshd se detuvo,
y como systemd lo consideró un inicio fallido, hubo un pequeño retraso mientras reintentaba. Suficiente para que las sesiones existentes se mantuvieran, pero las nuevas quedaron bloqueadas.

En aislamiento, eso es un fallo normal. En producción, coincidió con otro incidente que forzó a los operadores a abrir sesiones nuevas rápidamente.
Chocaron contra el muro en el peor momento posible: el reinicio convirtió un cambio manejable en un incidente de acceso.

Después, no abandonaron por completo los reinicios. Se volvieron más listos: validar configs con sshd -t, preferir reload cuando sea posible,
y ejecutar reinicios escalonados solo cuando puedas tolerar el riesgo. “Más limpio” no es un SLO.

Práctica aburrida pero correcta: puertos paralelos + firewall en fases salvaron el día

Una compañía vinculada a finanzas tenía un mandato de cumplimiento: “mover SSH fuera del 22 en todas partes”. El equipo de seguridad quería hacerlo rápido.
El responsable de operaciones se negó. No porque amara el puerto 22, sino porque amaba más la continuidad.

Implementaron un plan en dos fases. Fase 1: añadir un segundo puerto en sshd en todos los hosts, abrirlo solo desde las CIDR de la VPN,
y actualizar bastiones y automatización para preferir el puerto nuevo. No se quitó nada. Cada máquina terminó la fase 1 con dos puertas funcionando.

Esperaron un ciclo completo de cambios. Durante ese tiempo vigilaron logs para cualquier cliente que siguiera usando 22—scripts viejos, jump boxes olvidados,
appliances de proveedores y el “temporal” cron que había sobrevivido tres trimestres.

La Fase 2 fue anticlimática: eliminar el puerto 22 en sshd, luego quitar el allow del firewall. Sin bloqueos, sin drama.
Fue casi decepcionante, que es la respuesta emocional correcta a un cambio de infraestructura.

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

1) Síntoma: “Connection refused” en el puerto nuevo

Causa raíz: sshd no está escuchando en ese puerto (la configuración no se aplicó, override en includes, o recarga/reinicio falló).

Solución: Comprueba ss -ltnp y sshd -T | grep ^port. Corrige el orden de config en sshd_config.d. Ejecuta sshd -t, luego systemctl reload ssh.

2) Síntoma: “Connection timed out” en el puerto nuevo

Causa raíz: drop de firewall aguas arriba (security group de la nube, firewall del host, o ACL) o problema de enrutamiento.

Solución: Confirma que el host está escuchando; luego confirma que existe la regla del firewall del host; luego confirma que el firewall del proveedor lo permite. Los timeouts suelen ser “drop”, no “reject”.

3) Síntoma: UFW muestra allow, pero el tráfico sigue bloqueado

Causa raíz: realmente no estás usando las reglas de UFW (otro gestor de firewall está activo), o una regla posterior la sombra.

Solución: Valida con nft list ruleset y revisa los estados de servicio. Si nftables usa un ruleset separado, decide un único propietario y deshabilita el otro.

4) Síntoma: sshd escucha en IPv4 pero no en IPv6 (o viceversa)

Causa raíz: ajustes de AddressFamily o ListenAddress, o IPv6 del sistema/red deshabilitada.

Solución: Revisa ss -ltnp buscando [::]:PORT. Confirma sshd -T | grep listenaddress. Ajusta la config intencionalmente; no confíes en defaults si te importa.

5) Síntoma: puedes SSH desde dentro del host pero no desde fuera

Causa raíz: firewall o ruta de red aguas arriba bloquea; la prueba localhost evita esas capas.

Solución: Prueba desde un par en la misma subred/VPN. Valida reglas del proveedor. No te felicites solo porque localhost funcione.

6) Síntoma: las sesiones existentes siguen vivas, pero no puedes abrir nuevas después del cambio

Causa raíz: reinicio de sshd falló o los puertos de escucha cambiaron inesperadamente; las conexiones TCP establecidas sobreviven hasta cerrarse.

Solución: Revisa systemctl status ssh y journalctl -u ssh. Restaura puertos de escucha y recarga. Mantén una sesión abierta hasta validar nuevos inicios de sesión.

7) Síntoma: la automatización falla (Ansible, scripts, monitorización)

Causa raíz: los clientes hardcodean el puerto 22, o dependen de ~/.ssh/config que no está desplegado en todas partes.

Solución: Actualiza inventarios y configuraciones SSH, o usa bastiones basados en DNS con configuración centralizada. Ejecuta una auditoría basada en logs antes de quitar 22.

8) Síntoma: el puerto parece abierto, pero la autenticación falla solo en el puerto nuevo

Causa raíz: bloques Match se aplican de forma distinta (por LocalPort, Address o User), o una regla PAM/AllowUsers no coincide.

Solución: Revisa la salida de sshd -T y la lógica Match. Comprueba logs por razones de rechazo de auth; corrige los bloques Match para que ambos puertos compartan la política prevista.

Preguntas frecuentes

1) ¿Cambiar el puerto SSH realmente mejora la seguridad?

Reduce el ruido oportunista (escaneos de commodity golpeando el 22), lo que puede mejorar la relación señal/ruido en los logs.
No reemplaza controles reales: auth basada en claves, deshabilitar contraseñas cuando sea factible, MFA en bastiones y listas estrictas de IP origen.

2) ¿Debería ejecutar SSH en dos puertos permanentemente?

Temporalmente, sí—durante la migración es el enfoque más seguro. Permanentemente, usualmente no: estás ampliando la superficie expuesta sin ganancia operacional.
Mantén dos puertos solo si tienes una razón clara (ruta de bastión separada vs ruta interna) y lo documentas.

3) ¿Dónde debo poner la directiva Port en Debian 13?

Colócala en un snippet dedicado como /etc/ssh/sshd_config.d/10-ports.conf.
Es más fácil de gestionar, auditar y menos probable que sea sobrescrito por actualizaciones de paquete u otras herramientas.

4) ¿Cuál es la diferencia entre “connection refused” y “timed out”?

Refused suele significar que algo rechazó activamente la conexión—nadie está escuchando, o un firewall la rechazó.
Timed out suele significar que los paquetes están siendo descartados—a menudo un firewall aguas arriba o un problema de enrutamiento.
Diagnósticalos de forma distinta.

5) ¿Recargar o reiniciar sshd?

Prefiere recargar para cambios de configuración. Es menos disruptivo. Aun así valida con sshd -t primero.
Reiniciar es para cuando debes hacerlo, no por reflejo.

6) ¿Cómo confirmo qué puerto está usando realmente sshd?

Usa ss -ltnp para ver sockets de escucha en vivo y sshd -T para ver la configuración efectiva.
No confíes en “edité un archivo”. Confía en lo que el proceso está haciendo.

7) Abrí el puerto en el firewall de la VM. ¿Por qué no puedo conectar?

Porque tu VM no es el único firewall. Los security groups del cloud/firewalls del proveedor y las ACLs corporativas pueden bloquearte.
Si el host está escuchando y el firewall del host lo permite, sospecha capas aguas arriba a continuación.

8) ¿Qué número de puerto debería elegir?

Elige algo que no colisione con servicios locales y que sea fácil de estandarizar para tu equipo.
Evita “alternativas populares” si te importa reducir el ruido. Pero no elijas algo tan raro que nadie lo recuerde.
La estandarización vence a la creatividad.

9) ¿Puedo cambiar el puerto SSH sin tiempo de inactividad?

Usualmente sí: añade un puerto adicional, recarga, abre el firewall, prueba y luego elimina el puerto viejo más tarde.
Las sesiones existentes permanecen; las nuevas pueden migrar de forma progresiva.

Siguientes pasos que te mantienen empleado

Trata los cambios de puerto SSH como cualquier otro cambio de producción: escalonado, validado y reversible.
El orden correcto no es opcional: sshd escucha en ambos → firewall permite ambos → prueba el puerto nuevo → actualiza clientes → elimina el puerto viejo.
Todo lo demás es apostar el acceso.

Pasos prácticos siguientes:

• Adopta un archivo snippet estándar para puertos SSH bajo /etc/ssh/sshd_config.d/.
• Codifica una regla de dos sesiones para cambios de acceso remoto.
• Haz explícita la propiedad del firewall (UFW vs nftables vs gestión por configuración) y elimina el problema de “dos capitanes”.
• Audita logs por uso residual del puerto 22 antes de cerrarlo, especialmente desde automatización y herramientas de proveedores.
• Documenta la ruta de reversión y asegúrate de que exista acceso por consola antes de empezar.