Debian 13: SSH tarda en iniciar sesión — DNS y GSSAPI que lo aceleran al instante (caso #5)

Guía rápida de diagnóstico

Si solo tienes cinco minutos (y los tienes), no “optimices SSH”. Identifica la pausa. Luego arregla la perilla única que corresponda a esa pausa.

Primero: mide el inicio desde el cliente (encuentra la fase)

Ejecuta SSH con la máxima verbosidad y observa dónde se detiene. Si se congela después de “Authentications that can continue” o alrededor de líneas de GSSAPI, ese es un camino. Si se congela después de la autenticación, antes del shell, suele ser DNS o búsquedas del servicio de nombres en PAM.

Segundo: revisa los registros del servidor durante la pausa

En otra terminal, haz tail del journal del servidor para sshd. Si ves “reverse mapping checking getaddrinfo…” o largos espacios entre líneas de registro, eso es DNS. Si ves “GSSAPI” y intentos repetidos, es negociación Kerberos/GSSAPI.

Tercero: demuestra que DNS es lento (forward + reverse)

Desde el servidor, resuelve la IP del cliente a un PTR y luego resuelve ese nombre de host de vuelta. Si alguna consulta tarda segundos o agota el tiempo, encontraste la demora.

Cuarto: aplica la solución mínima y segura

• Para pausas por búsquedas DNS inversas: establece UseDNS no en /etc/ssh/sshd_config (o en un drop-in) y reinicia sshd.
• Para pausas por GSSAPI: establece GSSAPIAuthentication no (cliente y/o servidor) donde Kerberos no sea necesario.

Quinto: vuelve a probar y revierte si cambiaste lo equivocado

La lentitud de SSH suele ser determinista. Si solucionas la causa correcta, se vuelve instantáneo. Si se vuelve “lentitud distinta”, ahora estás depurando otra cosa (PAM, LDAP, montajes de home, scripts de inicio de shell).

Qué significa realmente “SSH lento”

Cuando la gente dice “SSH es lento”, usualmente se refiere a una de cuatro demoras:

1. Conexión TCP lenta: no puedes establecer la conexión rápidamente. Eso es enrutamiento, firewall, drops de SYN o selección de versión IP.
2. Intercambio de claves lento: la negociación criptográfica se detiene. Raro en hardware moderno, salvo que la entropía esté rota o la red esté manipulando paquetes.
3. Autenticación lenta: el servidor se toma una eternidad para verificar tu clave/contraseña. A menudo PAM + LDAP/SSSD, o GSSAPI.
4. Post-autenticación lenta: la autenticación tiene éxito y luego esperas antes de obtener un shell. Comúnmente búsquedas DNS inversas, módulos de sesión PAM, automounts o scripts de inicio del shell.

Este artículo trata casos donde la conexión es rápida, el intercambio de claves es rápido, pero aún te quedas esperando: generalmente porque el servidor intenta cortésmente saber tu nombre (DNS) o tu identidad empresarial (Kerberos), y espera a que otra infraestructura responda.

Un principio a recordar: no adivines. SSH te da suficiente observabilidad para identificar la pausa exacta con marcas de tiempo y registros. Úsalos.

El ingeniero de fiabilidad John Allspaw tiene una idea que me gusta parafraseada: “La operación tiene éxito cuando entiendes el sistema que realmente tienes, no el que imaginaste.” Eso resume todo este problema en una frase.

Datos interesantes y contexto (por qué sigue ocurriendo)

• OpenSSH añadió soporte GSSAPI hace décadas para integrarse en redes empresariales centradas en Kerberos, donde “sin contraseña” significa tickets, no claves.
• Las comprobaciones de DNS inverso en sshd son más antiguas que muchas redes en la nube actuales; tenían sentido cuando la confianza basada en host y el registro por hostname eran comunes.
• Los timeouts de DNS suelen ser “lentos por diseño”: los resolutores reintentan múltiples servidores, por UDP y luego TCP, a través de dominios de búsqueda, con backoff.
• Un PTR faltante puede ser peor que un PTR equivocado: las respuestas incorrectas son rápidas; los timeouts son lentos.
• nsswitch controla mucho más de lo que la gente piensa: si hosts: incluye mdns, nis o un orden de files que no es el adecuado, una “búsqueda simple” se convierte en un tour por los arrepentimientos de tu red.
• systemd-resolved cambió la superficie de depuración: a menudo hablas con un resolved stub local, que luego habla con resolutores ascendentes con su propio cacheo y comportamientos de fallo.
• Los valores predeterminados del cliente SSH pueden provocar trabajo en el servidor: un cliente que ofrece GSSAPI puede hacer que el servidor lo intente, incluso si nunca tendrá éxito.
• IPv6 puede añadir segundos de retraso sin romper nada: búsquedas AAAA, resolutores v6 inalcanzables o rutas v6 rotas pueden crear “pausas misteriosas”.

Dos conclusiones: (1) la mayoría de los “problemas de rendimiento” de SSH son en realidad problemas de rendimiento del servicio de nombres, y (2) la solución correcta suele ser un cambio de configuración de una sola línea, una vez que demuestres la causa.

Tareas prácticas: comandos, salidas, decisiones

Estos no son comandos de laboratorio. Son los que ejecutas un martes a las 02:10 mientras alguien pregunta “¿prod está bien?” Cada tarea incluye qué significa su salida y qué decisión tomar a partir de ella.

Tarea 1: Mide dónde se pausa el cliente (SSH verboso)

cr0x@server:~$ ssh -vvv admin@debian13-prod
OpenSSH_9.9p1 Debian-1, OpenSSL 3.3.2 3 Sep 2025
debug1: Connecting to debian13-prod [10.20.30.40] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_ed25519 type 3
debug1: kex: algorithm: sntrup761x25519-sha512
debug1: SSH2_MSG_NEWKEYS sent
debug1: SSH2_MSG_NEWKEYS received
debug1: Authenticating to debian13-prod:22 as 'admin'
debug1: Offering public key: /home/admin/.ssh/id_ed25519
debug1: Server accepts key: /home/admin/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).
debug1: Entering interactive session.
debug1: pledge: filesystem
... (pause here for 6 seconds) ...
Linux debian13-prod 6.12.0-1-amd64 #1 SMP Debian 6.12.3-1 ...
admin@debian13-prod:~$

Significado: la criptografía y la autenticación son rápidas; la pausa está después de “Entering interactive session.” Eso apunta a pasos post-auth: DNS inverso, módulos de sesión PAM, automounts o init de shell. DNS es un sospechoso principal.

Decisión: Revisa los registros del servidor y la resolución DNS desde el servidor a continuación.

Tarea 2: Haz tail de los logs de sshd mientras reproduces el problema

cr0x@server:~$ sudo journalctl -u ssh -f
Dec 30 11:18:02 debian13-prod sshd[23144]: Accepted publickey for admin from 10.20.99.17 port 51244 ssh2: ED25519 SHA256:...
Dec 30 11:18:02 debian13-prod sshd[23144]: pam_unix(sshd:session): session opened for user admin(uid=1000) by (uid=0)
Dec 30 11:18:08 debian13-prod sshd[23144]: pam_env(sshd:session): deprecated reading of user environment enabled

Significado: hay un hueco de seis segundos entre session opened y la siguiente línea de log. Esa es la ventana de la pausa.

Decisión: Comprueba si sshd está haciendo búsquedas DNS o intentos GSSAPI, y prueba la latencia de resolución de nombres.

Tarea 3: Identifica la IP del cliente en los logs, luego prueba DNS inverso en el servidor

cr0x@server:~$ dig +tries=1 +time=2 -x 10.20.99.17
;; communications error to 10.20.0.53#53: timed out
;; communications error to 10.20.0.54#53: timed out
;; no servers could be reached

Significado: la búsqueda inversa está agotando el tiempo. sshd puede estar esperando esto durante el inicio si UseDNS está habilitado o si otros componentes realizan búsquedas.

Decisión: Arregla la accesibilidad del resolutor o desactiva el uso de DNS inverso en sshd (según la política). Sigue investigando: ¿está roto el DNS en el servidor o solo para esa subred?

Tarea 4: Comprueba qué resolutor usa el servidor (systemd-resolved)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
       DNS Domain: corp.example

Significado: el servidor depende de 10.20.0.53/54. Si esos son inalcanzables desde este host/VRF, las consultas DNS se bloquearán.

Decisión: Verifica la alcanzabilidad de los resolutores y considera el comportamiento de cache local y los timeouts.

Tarea 5: Confirma la alcanzabilidad a los servidores DNS (no supongas)

cr0x@server:~$ ping -c 2 10.20.0.53
PING 10.20.0.53 (10.20.0.53) 56(84) bytes of data.

--- 10.20.0.53 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms

Significado: tu resolutor está muerto para este host. Eso no es un problema de SSH; es un problema de dependencia.

Decisión: Arregla el enrutamiento/firewall hacia DNS, o temporalmente apunta este host a un resolutor accesible; luego revisa la política UseDNS de sshd.

Tarea 6: Comprueba si sshd está configurado para usar DNS inverso

cr0x@server:~$ sudo sshd -T | egrep 'usedns|gssapiauthentication|gssapicleanupcredentials|gssapikexalgorithms'
usedns yes
gssapiauthentication yes
gssapicleanupcredentials yes

Significado: sshd está explícitamente haciendo comprobaciones DNS inversas y también intentará GSSAPI.

Decisión: Si no requieres registro por hostname basado en DNS inverso o autenticación basada en host, establece UseDNS no. Si no usas Kerberos para SSH, deshabilita GSSAPI. Pero valida primero cuál está causando tu pausa.

Tarea 7: Cronometra búsquedas DNS forward y reverse (prueba rápido/lento)

cr0x@server:~$ time getent hosts 10.20.99.17
10.20.99.17     laptop17.corp.example

real    0m5.912s
user    0m0.003s
sys     0m0.003s

Significado: una ruta de resolución básica está tomando ~6 segundos, coincidiendo con la pausa en el inicio. Ese es tu cráter humeante.

Decisión: Arregla la alcanzabilidad/los registros DNS, o dile a sshd que no bloquee en esa búsqueda.

Tarea 8: Verifica PTR → A/AAAA (forward-confirmed reverse DNS)

cr0x@server:~$ host 10.20.99.17
17.99.20.10.in-addr.arpa domain name pointer laptop17.corp.example.
cr0x@server:~$ host laptop17.corp.example
laptop17.corp.example has address 10.20.99.18

Significado: el PTR apunta a un hostname que no resuelve de vuelta a la misma IP. Esta inconsistencia puede causar búsquedas adicionales y confusión en los registros, y algunos sistemas lo tratan con suspicacia.

Decisión: Corrige el PTR o el registro A si dependes de DNS inverso para registro/auditoría. Si no, desactiva UseDNS y deja de pagar ese impuesto.

Tarea 9: Desactiva UseDNS de forma segura usando un drop-in

cr0x@server:~$ sudo install -d -m 0755 /etc/ssh/sshd_config.d
cr0x@server:~$ printf "UseDNS no\n" | sudo tee /etc/ssh/sshd_config.d/10-fast-login.conf
UseDNS no
cr0x@server:~$ sudo sshd -t
cr0x@server:~$ sudo systemctl restart ssh
cr0x@server:~$ sudo systemctl is-active ssh
active

Significado: la sintaxis de la configuración es válida, el servicio se reinició correctamente.

Decisión: Vuelve a probar el tiempo de SSH. Si se vuelve instantáneo, has aislado el problema a búsquedas DNS inversas durante el inicio.

Tarea 10: Confirma la mejora desde el cliente

cr0x@server:~$ ssh -vv admin@debian13-prod
debug1: Authentication succeeded (publickey).
debug1: Entering interactive session.
Linux debian13-prod 6.12.0-1-amd64 #1 SMP Debian 6.12.3-1 ...
admin@debian13-prod:~$

Significado: la pausa desapareció. Bien. Aun así sigue adelante: DNS sigue roto, solo dejaste de hacer que SSH espere por él.

Decisión: Crea un ticket sobre la alcanzabilidad de resolutores y la higiene de PTR. No quieres que otros servicios queden colgados.

Tarea 11: Detecta demoras de negociación GSSAPI desde el cliente

cr0x@server:~$ ssh -vvv user@debian13-prod
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
... (pause and retries) ...
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).

Significado: el cliente está intentando GSSAPI primero, falla y pierde tiempo haciéndolo. Incluso si publickey es rápido, pagas la penalidad del intento GSSAPI.

Decisión: Desactiva GSSAPI en el cliente para este host (preferido) o en el servidor si tu entorno no usa Kerberos para SSH.

Tarea 12: Desactiva GSSAPI en el cliente (por host) sin cambiar el servidor

cr0x@server:~$ cat >> ~/.ssh/config <<'EOF'
Host debian13-prod
  GSSAPIAuthentication no
  PreferredAuthentications publickey
EOF
cr0x@server:~$ ssh -vv user@debian13-prod
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).

Significado: sin intento GSSAPI; la ruta de autenticación es más corta.

Decisión: Si esto corrige consistentemente la demora para los usuarios, considera una política a nivel de servidor también—tras confirmar que nadie depende de Kerberos para SSH.

Tarea 13: Desactiva GSSAPI en el servidor (solo si no usas Kerberos SSH)

cr0x@server:~$ printf "GSSAPIAuthentication no\n" | sudo tee /etc/ssh/sshd_config.d/20-no-gssapi.conf
GSSAPIAuthentication no
cr0x@server:~$ sudo sshd -t
cr0x@server:~$ sudo systemctl restart ssh
cr0x@server:~$ sudo sshd -T | egrep 'gssapiauthentication|usedns'
usedns no
gssapiauthentication no

Significado: el servidor no ofrecerá GSSAPI. Esto puede reducir materialmente el “cambio del primer método de autenticación”.

Decisión: Despliega esto solo después de verificar que tu flota no usa tickets Kerberos para SSO de SSH.

Tarea 14: Comprueba el orden de búsqueda de hosts (nsswitch) cuando “DNS está bien pero getent es lento”

cr0x@server:~$ grep '^hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Significado: mDNS se consulta antes que DNS. En entornos de servidor, mDNS suele ser carga inútil y puede introducir demoras, especialmente con configuraciones de red extrañas.

Decisión: Considera simplificar la resolución de hosts en servidores (a menudo files dns), pero coordina con lo que instaló mdns originalmente.

Tarea 15: Demuestra si systemd-resolved es el cuello de botella (cache vs upstream)

cr0x@server:~$ resolvectl query -t PTR 10.20.99.17
10.20.99.17: resolve call failed: No appropriate name servers or networks for name found

Significado: resolved no puede alcanzar el DNS configurado para esa consulta. No es una “consulta lenta”, es un “no hay ruta a DNS”, que a menudo se manifiesta como timeouts en otras partes.

Decisión: Arregla la red hacia DNS o ajusta los servidores DNS para esa interfaz/VLAN.

Tarea 16: Confirma que la pausa no proviene de PAM/SSSD/LDAP (un señuelo común)

cr0x@server:~$ sudo pam_tally2 --user admin
Login           Failures Latest failure     From
admin               0

Significado: Nada obvio aquí, pero el punto es: comprueba si los módulos PAM hacen llamadas externas. (En muchos sistemas en su lugar inspeccionarías /etc/pam.d/sshd y logs de SSSD.)

Decisión: Si deshabilitar UseDNS y GSSAPI no lo arregla, pivota a PAM/sesión y servicios de directorio.

Retrasos por búsquedas DNS inversas: el clásico fallo “¿por qué SSH es cortés?”

El DNS inverso es la razón número 1 por la que SSH “funciona pero se siente lento”. sshd recibe una IP de cliente y—dependiendo de la configuración—intenta resolverla a un hostname y luego a veces verificar que ese hostname resuelva de vuelta a la misma IP. Si DNS es lento o está roto, sshd espera.

Aquí está la verdad incómoda: en muchos entornos, el DNS inverso no se mantiene con la misma disciplina que el DNS directo. La gente añade registros A/AAAA porque si no, las cosas no funcionan. Los PTR se tratan como “agradable de tener” hasta que algo depende de ellos. sshd es una de esas cosas.

Qué hace realmente UseDNS (y qué no hace)

UseDNS controla si sshd usa DNS para mapear la IP remota a un hostname para registros y decisiones de control de acceso que involucren nombres de host. Si lo desactivas, sshd normalmente registrará y operará basado en la IP en lugar de esperar al DNS inverso.

Desactivar UseDNS no evita que todo haga búsquedas DNS. Módulos PAM, herramientas de auditoría y tu prompt del shell aún pueden resolver nombres. Pero elimina una demora sincrónica común justo en el camino de inicio de sesión.

Por qué esto empeora en redes modernas

La nube y las redes corporativas adoran la indirección: redes overlay, DNS con split-horizon, múltiples resolutores por interfaz y appliances de seguridad que interceptan DNS. Cada capa añade modos de falla que parecen “solo a veces lento”. SSH hace esos modos de falla dolorosamente visibles porque es interactivo y notas cada segundo.

Y sí, IPv6 merece mención especial. Las malas configuraciones dual-stack a menudo causan “intentar v6 primero, fallar lentamente y luego tener éxito en v4.” A veces no lo verás en tus logs a menos que estés mirando.

Estrategia de arreglo: decide si necesitas DNS inverso en sshd

Haz una pregunta adulta: ¿realmente necesitas búsquedas DNS inversas durante el inicio de sesión SSH?

• Si usas reglas de acceso basadas en host con hostnames en AllowUsers/DenyUsers o bloques match, el DNS inverso puede importar. En la práctica, esto es raro y suele ser frágil.
• Si dependes del registro por hostname para respuesta a incidentes, puede que pienses que lo quieres. Pero las IPs suelen ser más fiables que los PTR en redes desordenadas. Siempre puedes hacer búsquedas inversas offline cuando el DNS esté sano.
• Si no tienes gestión disciplinada de PTR, habilitar UseDNS es un impuesto que pagas para siempre.

Mi sesgo: en servidores, desactiva UseDNS a menos que tengas una razón específica y probada para no hacerlo. Mantén la cadena de dependencias corta.

Broma #1: El DNS es como la política de oficina: cuando está sano, no lo notas; cuando está roto, todo se convierte en una reunión.

¿Y si debes mantener UseDNS habilitado?

Entonces trata los registros PTR como datos de producción. Mantenlos. Monitórealos. Pruébalos desde las subredes del servidor que importan. Y asegúrate de que los servidores puedan alcanzar sus resolutores rápida y consistentemente.

Además: establece timeouts realistas para resolutores. Algunos entornos aceptan timeouts largos de DNS “porque eventualmente funciona”. Los inicios interactivos no.

GSSAPI/Kerberos: el impuesto empresarial que quizá no debas pagar

GSSAPI en SSH existe para que puedas autenticarte usando tickets Kerberos. En el entorno correcto es fantástico: single sign-on, políticas centralizadas, menos proliferación de claves SSH. En el entorno equivocado es una comprobación previa lenta que falla en cada inicio.

Cuando GSSAPI está habilitado, un cliente y servidor pueden intentar uno o más intercambios Kerberos antes de volver a publickey o password. Si el cliente no tiene tickets, si el KDC es inalcanzable, si el DNS inverso de los realms está roto, o si la sincronización horaria está mal, puedes obtener segundos de retraso por intento.

Cómo reconocer la lentitud por GSSAPI

La salida verbosa del cliente lo muestra normalmente con claridad: intenta gssapi-with-mic, falla con “No Kerberos credentials” o similar y solo entonces ofrece una clave. A veces reintenta. A veces espera búsquedas SRV DNS para los KDC. A veces espera timeouts de red hacia el KDC.

A diferencia de UseDNS, la lentitud de GSSAPI suele ser visible en la fase de autenticación, antes de “Entering interactive session.” Así es como los distingues rápidamente.

Estrategia de arreglo: deshabilita donde sea apropiado, no sabotees SSO accidentalmente

Hay dos patrones seguros:

1. Deshabilitación por host en el cliente (~/.ssh/config) para hosts donde Kerberos no se usa. Esto evita romper otros hosts donde Kerberos SSH sí se desea.
2. Deshabilitación en el servidor cuando estás seguro de que el entorno no usa Kerberos para SSH en absoluto. Esto evita que los clientes siquiera lo intenten.

Sé cauto con cambios globales en entornos corporativos compartidos. Alguien, en algún lugar, está usando esa función que olvidaste que existía. Suelen ser directorios con agendas apretadas.

Broma #2: Kerberos es maravilloso hasta que no lo es, y entonces se convierte en un sistema distribuido con sentimientos.

Limpieza GSSAPI y reenvío de credenciales

Opciones como GSSAPICleanupCredentials y el reenvío de credenciales en el cliente pueden importar para seguridad y experiencia de usuario, pero normalmente no son la causa principal de “inicio lento”. Si tu demora ocurre durante la autenticación y GSSAPI está habilitado, empieza por determinar si falla y agota tiempo o si tiene éxito rápidamente.

Si usas Kerberos, trata la ruta al KDC como una dependencia: DNS, sincronización horaria, reglas de firewall y configuración de realm deben estar aburridamente correctas. SSH solo es el mensajero.

Tres microhistorias corporativas desde el campo

1) El incidente causado por una suposición errónea: “DNS siempre está ahí”

Una compañía mediana migró un lote de hosts Debian a un segmento de red “restringido”. El segmento tenía reglas de egress estrictas: solo puertos de aplicación, nada de “infraestructura aleatoria”. Alguien supuso que el DNS sería gestionado “por la plataforma”, porque siempre había sido cierto en otros segmentos. Los hosts arrancaron con resolutores apuntando al DNS corporativo, pero el firewall no permitía el puerto 53 a esas IPs desde esa VLAN.

Todo parecía bien en los dashboards. La CPU estaba inactiva. Los servicios corrían. Pero los ingenieros notaron inicios SSH de 5–15 segundos. Lo descartaron como “lentitud de VPN”, hasta que un on-call intentó depurar un incidente de producción y pasó todo el incidente esperando shells.

El daño real no fue la demora en sí; fue el comportamiento que creó. La gente abría más sesiones “porque la primera colgó”. Los bastiones se vieron saturados. El tracking de conexiones SSH creció. La respuesta al incidente se sintió caótica porque las herramientas estaban lentas.

La solución fue dolorosamente simple: permitir egress DNS hacia los resolutores o colocar un resolutor dentro del segmento. Desactivar UseDNS hizo SSH instantáneo de inmediato, pero el equipo aún tuvo que arreglar DNS porque otros componentes (instalación de paquetes, validación TLS, descubrimiento de servicios) también dependían. La lección no fue “apaga UseDNS”. La lección fue “valida dependencias desde la red donde el servidor realmente vive”.

2) La optimización que salió mal: “Hagamos DNS más seguro”

Un equipo de seguridad desplegó una nueva política DNS: todos los hosts debían usar un par de “resolutores seguros” que realizaban filtrado y registro. Lo empujaron vía gestión de configuración. Los resolutores eran correctos—hasta que no lo fueron. Bajo ciertos modos de fallo, la capa de filtrado aceptaba paquetes pero demoraba respuestas mientras intentaba validación ascendente.

SSH se convirtió en el canario. Los ingenieros reportaron que iniciar sesión en hosts de producción a veces tomaba diez segundos, pero solo durante horas laborales. La reacción inmediata fue culpar la encriptación: “Quizá la nueva build de OpenSSH es más lenta.” Alguien sugirió cambiar cifrados. Alguien más propuso desactivar compresión. Nada ayudó, porque la criptografía no era el problema.

Un SRE cuidadoso comparó los tiempos verbosos de ssh con los tiempos de consulta DNS y encontró que las búsquedas inversas se atascaban exactamente cuando los resolutores seguros estaban bajo carga. Peor aún, la carga se correlacionaba con ventanas de escaneo de seguridad que generaban un alud de dominios desconocidos—exactamente lo que el servicio de filtrado tenía que analizar. El sistema hacía su trabajo; solo que lo hacía de forma síncrona para inicios interactivos.

La solución fue doble: (1) desactivar UseDNS a nivel de flota para servidores, y (2) afinar la ruta de resolución segura para que los timeouts fallen rápido y los caches tengan tamaño apropiado. Seguridad obtuvo sus logs. SRE recuperó sus shells. El fallo no fue “seguridad es mala”. Fue “los sistemas interactivos no pueden esperar por tu pipeline de cumplimiento”.

3) La práctica aburrida pero correcta que salvó el día: configuración SSH en fases con despliegues medibles

Otra compañía gestionaba una gran flota Debian con control de cambios estricto, lo que suena molesto hasta que te salva. Tenían una norma: cada cambio en sshd debía (a) aplicarse mediante drop-ins, (b) validarse con sshd -t, y (c) desplegarse primero en un conjunto canario antes de expandirlo.

Cuando un nuevo entorno empezó a reportar SSH lento, el equipo no “arregló SSH” inmediatamente. Reunieron evidencia: logs cliente -vvv, huecos en el journal del servidor y tiempos DNS con getent. Confirmaron que las búsquedas inversas tardaban varios segundos debido a PTR faltantes para una nueva pool de direcciones VPN.

La práctica aburrida fue que ya tenían un drop-in aprobado para hosts sensibles al rendimiento: /etc/ssh/sshd_config.d/10-fast-login.conf con UseDNS no. Estaba revisado, probado y documentado. Lo desplegaron primero en el segmento afectado, verificaron la mejora, y luego abrieron la tarea de PTR como una pista separada.

No ocurrió nada dramático. Nadie recibió dos pageros. Eso es lo que “salvar el día” parece en operaciones reales: menos sorpresas, menos heroísmos nocturnos, más sistemas que se comportan como esperas.

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

Esta es la sección que quieres cuando estás cansado y un poco enfadado con las computadoras.

1) Síntoma: larga pausa después de “Authentication succeeded”

Causa raíz: búsqueda DNS inversa durante la configuración de sesión (UseDNS yes) agotando o con resolutor lento.

Solución: establece UseDNS no en sshd; además arregla la alcanzabilidad de resolutores y la higiene de PTR.

2) Síntoma: larga pausa antes de ofrecer la clave; verbose muestra intentos “gssapi-with-mic”

Causa raíz: GSSAPI habilitado; el cliente intenta Kerberos primero, espera KDC/DNS/timeouts.

Solución: deshabilita GSSAPIAuthentication en el cliente por host o global en el servidor si no usas Kerberos SSH.

3) Síntoma: rápido en LAN, lento desde VPN

Causa raíz: la pool de VPN carece de PTR, o los clientes VPN resuelven vía una ruta DNS diferente; las búsquedas inversas agotan.

Solución: añade PTR para la pool VPN o desactiva UseDNS; verifica la alcanzabilidad DNS desde el servidor hacia los resolutores que manejan esa zona inversa.

4) Síntoma: solo algunos servidores son lentos, otros bien

Causa raíz: ACLs DNS por subred, resolutores distintos por interfaz o zonas split-horizon faltantes en una vista.

Solución: compara resolvectl status y la alcanzabilidad de resolutores entre hosts; alinea la configuración DNS por segmento de red.

5) Síntoma: SSH lento solo para algunos nombres de usuario

Causa raíz: módulos PAM llamando a LDAP/SSSD/automount para esos usuarios; no es principalmente DNS/GSSAPI.

Solución: inspecciona /etc/pam.d/sshd, logs de SSSD y el comportamiento de montado de home; prueba con un usuario local.

6) Síntoma: “ssh es lento” pero ssh -vvv muestra retraso antes de “Connection established”

Causa raíz: latencia en la ruta de red, límites de tasa SYN del firewall o resolución del nombre del destino (DNS del cliente), no pasos de login del servidor.

Solución: haz SSH a la IP directamente, prueba con nc -vz y verifica DNS del cliente vs DNS del servidor.

7) Síntoma: SSH lento después de iniciar sesión (aparece el prompt y luego los comandos van lentos)

Causa raíz: scripts de inicio del shell haciendo llamadas de red (git prompt, kubectl context, consultas LDAP), o directorios home en red.

Solución: perfila la ruta de init del shell; prueba temporalmente con ssh user@host /bin/bash --noprofile --norc.

8) Síntoma: desactivar UseDNS ayudó, pero ahora los logs son “menos bonitos”

Causa raíz: antes dependías de registros por hostname derivados de PTR.

Solución: actualiza el logging/alerting para basarse en IP; haz búsquedas inversas de forma asíncrona en pipelines de logs si lo necesitas.

Listas de verificación / plan paso a paso

Plan A: necesitas SSH rápido ahora (seguro y reversible)

1. Desde tu cliente, captura la salida de ssh -vvv y apunta dónde se detiene (auth vs post-auth).
2. En el servidor, haz tail de journalctl -u ssh -f mientras reproduces el inicio.
3. En el servidor, ejecuta sshd -T | grep usedns y sshd -T | grep gssapiauthentication.
4. Si la pausa es post-auth y DNS es sospechoso: establece UseDNS no vía /etc/ssh/sshd_config.d/.
5. Si la pausa es durante auth y GSSAPI aparece en la salida verbosa: deshabilita GSSAPI por host en ~/.ssh/config.
6. Valida configuración: sshd -t.
7. Reinicia SSH: systemctl restart ssh.
8. Vuelve a probar desde la misma red cliente que estaba lenta (LAN vs VPN importa).
9. Si se arregla, abre un seguimiento para infraestructura DNS/Kerberos para que otro servicio no cuelgue.

Plan B: debes mantener DNS inverso y/o Kerberos (hazlo como adulto)

1. Asegura que el servidor pueda alcanzar sus resolutores de forma fiable (ICMP no basta; prueba UDP/TCP 53 vía herramientas de política si están disponibles).
2. Asegura registros PTR para todas las subredes cliente (oficina, VPN, bastiones, runners CI).
3. Asegura forward-confirmed reverse DNS para subredes críticas (PTR apunta al nombre; el nombre apunta de vuelta a la misma IP).
4. Para GSSAPI: verifica la alcanzabilidad del KDC, la configuración de realm y la sincronización horaria; un NTP roto arruina el día silenciosamente.
5. Mantén timeouts/reintentos razonables en la cadena de resolución para que los inicios interactivos fallen rápido cuando dependencias estén caídas.
6. Mide periódicamente: guarda métricas de “tiempo de inicio SSH” desde redes representativas.

Plan C: mantiene los cambios mínimos y auditable

1. Usa drop-ins bajo /etc/ssh/sshd_config.d/ en lugar de editar el archivo principal.
2. Un cambio por archivo (más fácil revertir).
3. Siempre ejecuta sshd -t antes de reiniciar.
4. Mantén una sesión de consola abierta durante el reinicio si estás remoto, para no dejarte fuera.

Preguntas frecuentes

1) ¿Debo siempre poner UseDNS no en servidores Debian 13?

Casi siempre, sí. A menos que tengas una dependencia específica y probada en decisiones de hostname basadas en DNS inverso en sshd. La mayoría de los entornos no la tienen, y el coste es real cuando DNS es inestable.

2) ¿Desactivar UseDNS reduce la seguridad?

Elimina una clase de comprobaciones basadas en hostname, pero las comprobaciones basadas en hostname suelen ser más débiles que los controles basados en IP y clave. No uses PTR como señal de autenticación. Usa claves, MFA, ACLs de red y listas explícitas.

3) ¿Por qué SSH hace DNS inverso en absoluto?

Por legado y conveniencia de registro. Los patrones operativos antiguos confiaban más en hostnames y los usaban en controles de acceso. Hoy las redes cambian más rápido que los PTR. Las IPs suelen ser el identificador más honesto.

4) Si desactivo GSSAPI, ¿romperé inicios de sesión de dominio?

No necesariamente. Los usuarios de dominio aún pueden autenticarse vía claves públicas o contraseñas según tu configuración PAM. Pero romperás SSO Kerberos de SSH si alguien lo usa. Por eso deshabilitar por host en el cliente es el punto de partida más seguro.

5) SSH es lento solo en la primera conexión, luego rápido. ¿Por qué?

El cacheo DNS (cliente, servidor o systemd-resolved) puede hacer que búsquedas posteriores sean rápidas. Es una pista de que la resolución de nombres está involucrada. Mide con getent hosts y compara comportamiento con cache frío vs caliente.

6) Puse UseDNS no, pero sigue siendo lento después de la autenticación. ¿Qué sigue?

Pivota a PAM/sesión y entorno de usuario: latencia LDAP/SSSD, directorios home automontados, scripts de inicio de shell lentos o fallos en sistemas de archivos en red. Prueba con un usuario local y un shell mínimo para aislar.

7) ¿IPv6 puede causar inicios SSH lentos aunque IPv4 funcione?

Sí. Problemas de resolución dual-stack y de alcanzabilidad pueden añadir demoras en DNS y en contacto con servicios de identidad. Busca patrones de “v6 primero y luego fallback” en logs verbosos y en el estado del resolutor.

8) ¿Debo “arreglar” cambiando cifrados o algoritmos KEX?

No, no para este síntoma. Si tu pausa dura segundos y ocurre después de auth o durante GSSAPI, afinar criptografía es cargo cult. Mide primero; arregla la dependencia que realmente es lenta.

9) ¿Esto es específico de Debian 13?

El comportamiento es general en OpenSSH en muchas distribuciones Linux. Debian 13 solo significa que es probable que tengas OpenSSH moderno y systemd-resolved, lo que cambia dónde mirar los problemas DNS.

10) ¿Cuál es el cambio más pequeño que da la mayor ganancia?

UseDNS no suele ser la solución inmediata e “instantánea” para pausas post-auth. Para pausas durante auth, deshabilitar GSSAPI en el cliente para ese host es lo más pequeño y seguro.

Conclusión: siguientes pasos que perduran

Si los inicios SSH en Debian 13 se sienten lentos, trátalo como cualquier otra latencia en producción: identifica la fase, demuestra la dependencia, aplica la solución más pequeña y luego repara la infraestructura subyacente para que el siguiente servicio no herede el dolor.

Haz lo siguiente:

1. Captura una sesión ssh -vvv que muestre la pausa y guárdala con la marca de tiempo y la red del cliente (LAN/VPN/bastión).
2. En el servidor, mide time getent hosts <client-ip>. Si coincide con la pausa, terminaste de diagnosticar.
3. Establece UseDNS no vía un drop-in, valida con sshd -t, reinicia y vuelve a probar.
4. Si la salida verbosa muestra churn GSSAPI, desactívalo por host en el cliente primero; solo desactívalo en el servidor si estás seguro de que no se usa Kerberos SSH.
5. Abre la corrección real: alcanzabilidad de resolutores, higiene de PTR y (si aplica) fiabilidad del KDC. SSH solo expuso la verdad.

El estado final que quieres es aburrido: SSH inicia al instante, DNS funciona de forma fiable, Kerberos funciona cuando realmente lo usas, y nadie aprende por las malas que “infraestructura” es una dependencia, no una sugerencia.