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

Qué significa realmente “inicio de sesión SSH lento” (síntomas que importan)

“SSH es lento” es impreciso. Necesitas saber en qué etapa es lento, porque diferentes etapas implican culpables distintos. SSH es una tubería: conexión TCP → intercambio de claves → autenticación → configuración de sesión. DNS y GSSAPI pueden bloquear distintas partes de esa tubería, y tienen huellas digitales muy diferentes.

Perfiles comunes de inicio de sesión lento

• Retraso antes del prompt de contraseña (o antes de que se ofrezca cualquier método de autenticación): a menudo búsqueda DNS inversa (el servidor intenta resolver la IP del cliente a un nombre) o negociación GSSAPI.
• Retraso después de la autenticación (contraseña aceptada, pero el prompt llega tarde): módulos PAM, directorio home/automount, scripts de inicio de shell, o DNS durante la configuración de la sesión PAM.
• Retraso solo desde ciertas redes (VPN de oficina mal, casa bien): DNS de horizonte dividido, firewall bloqueando UDP/TCP 53, o alcanzabilidad del realm de Kerberos desde un lado.
• Retraso solo al usar un nombre de host (la IP es rápida): resolución DNS del cliente o problemas con dominios de búsqueda.
• Retraso solo en la primera conexión (las siguientes son rápidas): caché DNS negativa, calentamiento del resolvedor, o comportamiento de reintento de GSSAPI.

Nos centramos en Debian 13 con OpenSSH, y en las dos correcciones “victoria instantánea” más rápidas cuando la lentitud es antes de que tengas un shell: DNS inverso (UseDNS) y negociación GSSAPI (Kerberos).

Broma #1: SSH es como un portero que insiste en verificar tu identificación contra una base de datos “temporalmente no disponible.” No te niegan—solo te dejan esperando afuera.

Guía de diagnóstico rápido (primera/segunda/tercera comprobación)

Este es el flujo de “estoy de guardia, son las 02:00 y los ejecutivos esperan”. Está diseñado para encontrar el cuello de botella en minutos, no para satisfacer tu curiosidad.

Primero: localiza el retraso (vista del cliente)

1. Ejecuta SSH con pistas de tiempo y salida detallada y observa qué línea se pausa.
2. Si se pausa alrededor de líneas de GSSAPI, sospecha de Kerberos/GSSAPI. Si se pausa alrededor de “Authentications that can continue” o antes del banner, sospecha de DNS inverso del lado del servidor.

Segundo: verifica el comportamiento de DNS (vista del servidor)

1. Prueba búsquedas directas e inversas para la IP del cliente desde el servidor usando el resolvedor del sistema.
2. Busca timeouts, largos recorridos por dominios de búsqueda o registros PTR que apunten a nombres sin sentido.

Tercero: confirma que sshd está esperando en eso (logs y sshd debug)

1. Aumenta temporalmente el registro de sshd durante una ventana de prueba o ejecuta un sshd de depuración en un puerto alternativo.
2. Correlaciona marcas de tiempo: si los logs de sshd muestran huecos alrededor de “reverse mapping checking” o GSSAPI, tienes tu respuesta.

Después de eso decides: ¿desactivar UseDNS (generalmente sí), desactivar GSSAPIAuthentication (a menudo sí salvo que uses Kerberos), o arreglar la ruta subyacente de DNS/Kerberos (lo mejor a largo plazo)?

Por qué DNS y GSSAPI bloquean SSH en Debian 13

OpenSSH es conservador: intenta recopilar información sobre el cliente que se conecta y prueba métodos de autenticación en un orden útil para entornos empresariales. Dos cosas importan:

• Búsquedas DNS inversas se usan para el registro y (a veces) para lógica de control de acceso. El servidor puede intentar mapear la IP del cliente a un nombre (registro PTR), y en ocasiones validar que ese nombre resuelva de nuevo a la misma IP (un check FCrDNS).
• GSSAPIAuthentication permite single sign-on basado en Kerberos. Si está activado y el cliente lo ofrece (o el servidor lo prioriza), sshd puede intentar negociarlo. Si Kerberos está mal configurado, inalcanzable, bloqueado por firewall o lento, SSH espera.

En Debian 13 verás el mismo comportamiento fundamental que en otras versiones modernas: OpenSSH se compila con valores por defecto razonables para compatibilidad general, y la pila de resolvedor puede incluir systemd-resolved o el resolvedor clásico de glibc según tu configuración. El dolor suele venir de entornos donde DNS no es consistentemente rápido y correcto.

DNS inverso: el asesino silencioso clásico

DNS inverso (registros PTR) es fácil de descuidar porque la mayoría de las aplicaciones no lo necesitan. SSH sí. No siempre, y no en toda configuración, pero lo suficiente como para convertirse en una causa raíz común de “SSH es lento”.

Los peores casos son:

• La IP del cliente no tiene registro PTR y tu resolvedor reintenta múltiples servidores con timeouts largos.
• Existe un PTR pero apunta a un nombre que no resuelve de vuelta (el chequeo FCrDNS falla y se realizan más búsquedas).
• Los servidores DNS son alcanzables pero lentos, o solo accesibles vía una ruta VPN con pérdida de paquetes.
• Tu resolvedor tiene dominios de búsqueda agresivos e intenta varios sufijos antes de fallar.

GSSAPI: excelente cuando funciona, engorroso cuando no

Kerberos es genial cuando lo gestionas correctamente. Cuando no, falla de formas que parecen “SSH atascado”. Si GSSAPIAuthentication está habilitado en sshd y el cliente lo intenta, ambos lados pueden intentar encontrar realms, contactar KDCs y validar tickets. Si cualquiera de eso requiere DNS (y lo hace), puedes recibir un doble golpe: GSSAPI espera DNS que a su vez espera una red rota.

Broma #2: GSSAPI es como ese colega que “solo necesita cinco minutos” para unirse a una llamada, pero primero tiene que instalar una actualización.

Una cita sobre confiabilidad (parafraseada)

Paráfrasis de la idea: “La esperanza no es una estrategia.” — atribuida en círculos SRE al General Gordon R. Sullivan. Operativamente, significa que mides y verificas, no que desees.

Datos e historia interesantes (para entender la rareza)

• Hecho 1: OpenSSH se convirtió en la implementación SSH de facto tras las restricciones de licencia del SSH original; OpenSSH priorizó valores seguros por defecto, aunque a veces fueran verbosos.
• Hecho 2: El DNS inverso (registros PTR) vive en una zona especial bajo in-addr.arpa (IPv4) y ip6.arpa (IPv6). Muchas organizaciones lo tratan como opcional—hasta que el registro y los controles dependen de él.
• Hecho 3: El concepto de “forward-confirmed reverse DNS” surgió por higiene anti-spoofing: no es identidad fuerte, pero reduce etiquetados casuales incorrectos.
• Hecho 4: Kerberos depende mucho de DNS en muchas implementaciones (registros SRV, mapeo de realms), así que “Kerberos es lento” a menudo significa “DNS es lento, al cuadrado”.
• Hecho 5: La verificación de la clave del host en SSH trata la identidad del servidor, no la del cliente; las búsquedas DNS inversas son mayormente para nombres en registros y comprobaciones de políticas.
• Hecho 6: systemd-resolved introdujo nuevo cacheo y comportamientos de stub-resolver en muchos entornos Linux; solucionó algunos problemas y también creó nuevas rutas de depuración “depende”.
• Hecho 7: IPv6 puede magnificar problemas de DNS: los clientes pueden preferir registros AAAA, y las búsquedas inversas IPv6 son más largas y pueden provocar más timeouts si están mal configuradas.
• Hecho 8: NSS (Name Service Switch) puede causar retrasos sorprendentes si consulta fuentes como LDAP/SSSD para búsquedas de hosts; DNS no siempre es el único servicio de nombres en juego.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son chequeos probados en campo. Cada tarea incluye: un comando, salida realista, qué significa y qué haces a continuación. Ejecútalas en Debian 13 salvo indicación contraria. Sustituye IPs/hostnames por los tuyos.

Tarea 1: Identificar dónde se pausa SSH (lado cliente, verbose)

cr0x@server:~$ ssh -vvv admin@db-01
OpenSSH_9.8p1 Debian-1, OpenSSL 3.3.2 3 Sep 2024
debug1: Connecting to db-01 [10.20.30.41] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_ed25519 type 3
debug1: Local version string SSH-2.0-OpenSSH_9.8p1 Debian-1
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.8p1 Debian-1
debug1: Authenticating to db-01:22 as 'admin'
debug1: Authentications that can continue: gssapi-with-mic,publickey,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: KEYRING:persistent:1000)
debug1: Next authentication method: publickey
debug1: Server accepts key: /home/admin/.ssh/id_ed25519
Authenticated to db-01 ([10.20.30.41]:22) using "publickey".
debug1: Entering interactive session.

Significado: El cliente intentó GSSAPI primero. Si ves una pausa de varios segundos entre “Next authentication method: gssapi-with-mic” y el fallo, la negociación GSSAPI te está costando tiempo.

Decisión: Si no usas Kerberos SSO para SSH, desactiva GSSAPI en cliente y/o servidor. Si lo usas, verifica la alcanzabilidad del KDC y el DNS para SRV/mapeo de realms.

Tarea 2: Cronometra la conexión SSH con precisión

cr0x@server:~$ /usr/bin/time -p ssh -o PreferredAuthentications=publickey -o GSSAPIAuthentication=no admin@10.20.30.41 true
real 0.32
user 0.06
sys 0.03

Significado: Con GSSAPI desactivado y usando IP directa, es rápido. Eso implica fuertemente a GSSAPI y/o DNS cuando usas nombres.

Decisión: Si esto es rápido pero el SSH normal es lento, tienes un problema de configuración/ruta en lugar de CPU, criptografía o la red base.

Tarea 3: Compara rendimiento por hostname vs IP

cr0x@server:~$ /usr/bin/time -p ssh admin@db-01 true
real 8.74
user 0.07
sys 0.03

Significado: La conexión por nombre es lenta; esto suele indicar DNS del cliente (dominios de búsqueda, preferencia por IPv6 o resolvedor roto).

Decisión: Investiga la resolución DNS en el cliente: getent hosts, configuración del resolvedor y si las búsquedas AAAA caducan.

Tarea 4: Observa la resolución DNS a través de glibc/NSS (cliente o servidor)

cr0x@server:~$ getent hosts db-01
10.20.30.41     db-01.corp.example db-01

Significado: getent usa NSS (no solo DNS crudo). Si es lento, SSH que use nombres será lento también.

Decisión: Si getent se pausa, inspecciona /etc/nsswitch.conf y servicios de nombres (DNS, files, ldap, mdns). Podrías quedarte atascado en LDAP o en un resolvedor muerto.

Tarea 5: Verifica la velocidad de DNS inverso para una IP cliente (lado servidor)

cr0x@server:~$ getent hosts 10.20.99.17
10.20.99.17     laptop-17.vpn.example

Significado: Esta es la misma búsqueda que sshd podría hacer para registro y política. Si tarda segundos o caduca, sshd esperará.

Decisión: Si es lento o vacío, arregla los registros PTR y la alcanzabilidad del resolvedor, o desactiva UseDNS en sshd para dejar de esperar DNS inverso.

Tarea 6: Confirma la forward-confirmation (PTR apunta de vuelta)

cr0x@server:~$ getent hosts laptop-17.vpn.example
10.20.99.17     laptop-17.vpn.example

Significado: La búsqueda directa devuelve la IP original. Eso es un mapeo limpio y reduce el comportamiento extraño de sshd cuando intenta una comprobación forward-confirmed.

Decisión: Si el forward apunta a otro lado, corrige DNS. Si no puedes (redes de terceros), desactiva UseDNS y evita controles de acceso basados en nombres.

Tarea 7: Revisa rápidamente la configuración del resolvedor

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example vpn.example

Significado: El stub resolver en 127.0.0.53 suele indicar que systemd-resolved está en la ruta. Los dominios de búsqueda pueden provocar múltiples intentos de consulta.

Decisión: Si los dominios de búsqueda son largos o incorrectos, recórtalos. Si systemd-resolved está enfermo, arréglalo o apunta resolv.conf a servidores DNS reales.

Tarea 8: Inspecciona el estado de systemd-resolved y servidores ascendentes

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

Significado: Confirma qué servidores DNS se usan. Si esos servidores solo son alcanzables desde algunas VLANs, ya sabes por qué SSH es lento desde “ese lugar”.

Decisión: Arregla el enrutamiento/firewall hacia los servidores DNS, o configura DNS por enlace correctamente. No dejes clientes adivinando.

Tarea 9: Prueba la latencia de consulta DNS cruda (lado servidor) con dig

cr0x@server:~$ dig +tries=1 +time=2 -x 10.20.99.17 @10.20.1.10

; <<>> DiG 9.20.0-1-Debian <<>> +tries=1 +time=2 -x 10.20.99.17 @10.20.1.10
;; global options: +cmd
;; Got answer:
;; ->HEADER<- opcode: QUERY, status: NOERROR, id: 11421
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
17.99.20.10.in-addr.arpa. 300 IN PTR laptop-17.vpn.example.

;; Query time: 18 msec
;; SERVER: 10.20.1.10#53(10.20.1.10) (UDP)
;; WHEN: Mon Dec 30 10:11:25 UTC 2025
;; MSG SIZE  rcvd: 92

Significado: 18 ms está bien. Si ves 2000 ms o timeouts, ese es tu retraso de SSH. SSH no es especial; solo está esperando DNS.

Decisión: Si el tiempo de consulta es alto, arregla la latencia de DNS o desactiva UseDNS. Si caduca, revisa ACLs de red y si TCP/UDP 53 está bloqueado.

Tarea 10: Encuentra las opciones efectivas actuales de sshd

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

Significado: Esto es la verdad, incluyendo valores por defecto y fragmentos incluidos. Si usedns yes y DNS inverso es lento, sshd probablemente se detendrá.

Decisión: Si no requieres control de acceso basado en nombres y tienes DNS inverso inestable, establece UseDNS no. Si no usas Kerberos SSO, establece GSSAPIAuthentication no.

Tarea 11: Observa los logs de sshd para huecos temporales

cr0x@server:~$ sudo journalctl -u ssh -S -5m --no-pager
Dec 30 10:12:04 db-01 sshd[28192]: Connection from 10.20.99.17 port 51844 on 10.20.30.41 port 22 rdomain ""
Dec 30 10:12:12 db-01 sshd[28192]: Accepted publickey for admin from 10.20.99.17 port 51844 ssh2: ED25519 SHA256:Qq5pZx...
Dec 30 10:12:12 db-01 sshd[28192]: pam_unix(sshd:session): session opened for user admin(uid=1000) by (uid=0)

Significado: Ocho segundos entre “Connection from …” y “Accepted publickey …” a menudo indica retraso pre-auth: DNS inverso o intento GSSAPI antes de la autenticación por clave.

Decisión: Correlaciona con la salida del cliente -vvv. Si la pausa es antes de “Accepted publickey”, ajusta UseDNS/GSSAPI; si es después, revisa PAM y el inicio del shell.

Tarea 12: Ejecuta un sshd de depuración en un puerto alternativo (temporal y seguro)

cr0x@server:~$ sudo /usr/sbin/sshd -D -ddd -p 2222
debug3: sshd version OpenSSH_9.8p1 Debian-1
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug1: Connection from 10.20.99.17 port 51852 on 10.20.30.41 port 2222 rdomain ""
debug2: fd 4 setting O_NONBLOCK
debug3: mm_getpwnamallow: entering
debug3: mm_answer_pwnamallow: entering
debug1: userauth-request for user admin service ssh-connection method gssapi-with-mic [preauth]

Significado: -ddd muestra mucho ruido pero enseña qué método se intenta y dónde se queda. Si la salida se congela después de una línea de DNS inverso o GSSAPI, aislaste el culpable sin tocar el proceso sshd de producción.

Decisión: Usa esto solo brevemente y en un host protegido. Una vez confirmado, deténlo y aplica cambios de configuración al servicio real.

Tarea 13: Valida fundamentos de Kerberos (solo si realmente lo usas)

cr0x@server:~$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_1000)

Significado: No existe ticket, así que la autenticación GSSAPI fallará y puede ser lenta si el descubrimiento de realms es lento.

Decisión: Si quieres SSO Kerberos, obtén un ticket (kinit) y arregla el descubrimiento de realm/KDC. Si no, desactiva GSSAPI para SSH para evitar intentos inútiles.

Tarea 14: Comprueba si ssh ofrece GSSAPI (configuración cliente)

cr0x@server:~$ ssh -G admin@db-01 | egrep 'gssapiauthentication|preferredauthentications'
gssapiauthentication yes
preferredauthentications gssapi-with-mic,publickey,password

Significado: El cliente intentará GSSAPI primero. Incluso si el servidor está bien, el cliente puede desperdiciar tiempo intentando GSSAPI.

Decisión: Desactiva GSSAPI en el cliente para hosts afectados, o globalmente si no lo usas en ningún sitio.

Tarea 15: Confirma fragmentos de configuración de SSHD (includes de Debian)

cr0x@server:~$ sudo grep -R --line-number -E 'UseDNS|GSSAPIAuthentication|Include' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf
/etc/ssh/sshd_config:5:Include /etc/ssh/sshd_config.d/*.conf
/etc/ssh/sshd_config.d/50-cloud-init.conf:2:UseDNS yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:3:GSSAPIAuthentication yes

Significado: Tus ajustes “reales” podrían venir de un drop-in. La gente edita /etc/ssh/sshd_config, reinicia ssh y se pregunta por qué nada cambió.

Decisión: Cambia el archivo correcto (prefiere un nuevo drop-in con mayor precedencia, p. ej., 99-local.conf), y verifica con sshd -T.

Tarea 16: Valida la configuración de SSH antes de recargar

cr0x@server:~$ sudo sshd -t

Significado: Sin salida significa que la sintaxis está OK. Si hay un error, sshd lo imprime y sale con código distinto de cero.

Decisión: Nunca reinicies sshd sin sshd -t primero en un sistema remoto. Solo tienes una oportunidad de romper tu acceso antes de que se vuelva un rasgo de personalidad.

Arreglos que realmente funcionan (UseDNS, GSSAPI y aliados)

Arreglo 1: Desactivar búsquedas DNS inversas en sshd (la victoria más común)

Si tu organización no depende de controles de acceso SSH basados en nombres de host (por ejemplo, no estás emparejando hostnames en AllowUsers/DenyUsers ni usas autenticación basada en host ligada a DNS), desactívalo.

cr0x@server:~$ sudo tee /etc/ssh/sshd_config.d/99-local.conf >/dev/null <<'EOF'
UseDNS no
EOF

Qué hace: Evita que sshd haga búsquedas DNS inversas de la IP del cliente durante el manejo de la conexión. Tus logs mostrarán IPs de forma consistente. Tu inicio de sesión dejará de esperar timeouts de PTR.

Compensación: Pierdes la resolución automática de nombres en los logs de sshd (verás IPs). Para respuesta a incidentes, las IPs suelen ser mejores porque son más difíciles de “renombrar”.

cr0x@server:~$ sudo sshd -t
cr0x@server:~$ sudo systemctl reload ssh
cr0x@server:~$ sudo sshd -T | egrep 'usedns'
usedns no

Punto de decisión: Si la recarga funciona y sshd -T muestra usedns no, vuelve a probar SSH desde la red cliente problemática. Si la lentitud desaparece, tu ruta PTR/DNS era la causa. Luego arregla DNS correctamente si quieres logs más bonitos; ya no estás bloqueado.

Arreglo 2: Desactivar GSSAPIAuthentication en sshd (cuando no usas Kerberos SSH)

Muchos entornos no usan Kerberos SSH, pero heredan configuraciones que lo habilitan. Eso es tiempo desperdiciado y más modos de fallo. Desactívalo a menos que puedas decir claramente por qué debe estar activado.

cr0x@server:~$ sudo tee /etc/ssh/sshd_config.d/99-local.conf >/dev/null <<'EOF'
UseDNS no
GSSAPIAuthentication no
EOF

cr0x@server:~$ sudo sshd -t
cr0x@server:~$ sudo systemctl reload ssh
cr0x@server:~$ sudo sshd -T | egrep 'gssapiauthentication|usedns'
gssapiauthentication no
usedns no

Punto de decisión: Si dependes de Kerberos para SSO SSH, no hagas esto globalmente. En su lugar usa bloques Match o configuración por host para mantenerlo donde se necesita y desactivarlo donde no.

Arreglo 3: Desactivar GSSAPI en el lado cliente (contención rápida)

Si no puedes cambiar el servidor (appliance gestionado, fricción política o freeze de cambios), desactiva GSSAPI en el cliente. Esto es útil para hosts de salto y laptops de operadores.

cr0x@server:~$ tee -a ~/.ssh/config >/dev/null <<'EOF'
Host *.corp.example
  GSSAPIAuthentication no
  PreferredAuthentications publickey,password
EOF

Qué significa: Dejas de intentar GSSAPI primero y no pagas el coste de negociación.

Decisión: Despliega esto a grupos de usuarios afectados. Si tienes gestión centralizada de dotfiles, mantenlo focalizado; no rompas al único equipo que realmente usa Kerberos.

Arreglo 4: Hacer que DNS sea rápido y aburrido (la solución real)

Desactivar UseDNS es una mitigación válida. Arreglar DNS es la cura. En sistemas de producción quieres ambas cosas: detener la hemorragia ahora y luego eliminar el riesgo subyacente.

Mejoras concretas en DNS que importan para la latencia de SSH:

• Asegura que todas las subredes de clientes que llegan a servidores también tengan zonas de reverse funcionando (registros PTR) o al menos respuestas que no hagan timeouts.
• Asegura que los servidores DNS sean alcanzables desde cada ruta de red desde donde se origina SSH (VPN, bastiones, Wi-Fi de oficina, runners de CI).
• Reduce timeouts y reintentos del resolvedor solo si comprendes el radio de impacto. Afinar en exceso convierte DNS intermitente en “todo falla rápido”.
• Recorta dominios de búsqueda inútiles. Cada sufijo extra son consultas extra durante un fallo.

Arreglo 5: Evita controles de acceso basados en hostnames si DNS no es confiable

Si tienes lógica AllowUsers *@somehost basada en hostnames del cliente, estás haciendo de DNS parte de tu perímetro de seguridad. Eso puede funcionar, pero solo si DNS es correcto, rápido y controlado. En muchas redes no es ninguno de esos.

Prefiere controles basados en IP (reglas de firewall, security groups) o controles basados en identidad por clave (authorized_keys, certificados). Usa hostnames por conveniencia, no por enforcement, a menos que estés listo para operar DNS como un sistema crítico—porque lo es.

Arreglo 6: Si la lentitud es después de la autenticación, no culpes a DNS

Este artículo trata DNS y GSSAPI porque causan mejoras “instantáneas” en el caso más común de inicio de sesión lento. Pero si tu retraso es después de la autenticación exitosa, revisa:

• pam_mkhomedir creando home en el primer login
• Directorios home en red (NFS/Autofs) esperando montajes
• SSSD/LDAP retrasos en PAM account/session
• Scripts de inicio de shell lentos (.bashrc, .profile) que llaman a comandos de red

Etapa distinta de la tubería, arreglo distinto. Diagnostica antes de cambiar.

Tres micro-historias corporativas desde el campo

1) El incidente causado por una suposición errónea: “El DNS inverso es opcional”

La compañía migraba a un nuevo proveedor de VPN. El plan del proyecto cubría rutas, MFA y despliegue de clientes. El DNS inverso no entró en la lista porque, históricamente, nadie “lo usaba”. Esa suposición era cierta en el sentido estrecho de que nadie había abierto un ticket titulado “PTR records”.

En el primer día, los ingenieros empezaron a reportar que SSH a hosts de producción tardaba 20–30 segundos antes del prompt de contraseña. Algunas sesiones iban bien; otras no. El factor común resultó ser el nuevo pool de direcciones de la VPN. Estaba en una subred nueva sin zona de reverse delegada, y los servidores DNS para esa subred eran accesibles solo desde dentro del datacenter—no desde el segmento donde corría sshd.

El equipo on-call inicialmente persiguió CPU y entropía. Miraron promedios de carga, comprobaron la generación de números aleatorios e incluso cambiaron algunos cifrados “por ver”. Nada funcionó. Mientras, el helpdesk registró incidentes “SSH poco fiable” y los escaló como “regresiones de rendimiento del servidor”.

La solución fue aburrida: o añadir registros PTR (y hacer DNS alcanzable desde los servidores) o evitar que sshd esperara DNS inverso. Eligieron un enfoque en dos pasos: mitigación inmediata con UseDNS no. Luego el equipo de red implementó zonas reversas para los pools VPN y validó la alcanzabilidad desde cada VLAN de servidores que aceptaba SSH. El segundo paso importó porque otros sistemas—enriquecimiento de logs y correlación SIEM—también se beneficiaron. Pero SSH recuperó su prompt en minutos, y eso les dio tiempo.

2) La optimización que salió mal: “Afinemos timeouts del resolvedor”

Otra organización se cansó de grandes esperas de aplicaciones durante caídas de DNS. Alguien, con buenas intenciones y un poco de confianza, cambió el comportamiento del resolvedor globalmente: menos reintentos, timeouts más cortos. Hizo que los fallos fueran más rápidos, lo que sonaba como una victoria.

Luego tuvieron un nuevo tipo de outage: no “DNS caído”, sino “DNS inestable”. Con pérdida ligera de paquetes, la configuración antigua podía recuperarse con un reintento. La nueva fallaba rápido y consistentemente. SSH fue uno de los primeros canarios: intentos de login fallaban o tomaban rutas extrañas (intentos de IPv6 fallando, caída a IPv4, luego intento GSSAPI, luego timeout).

El resultado operativo fue peor que antes. En vez de sesiones lentas pero finalmente funcionales, los ingenieros obtuvieron bloqueos intermitentes desde jump hosts. Eso elevó las apuestas porque ahora el troubleshooting requería acceso que también estaba degradado.

La lección no fue “nunca afines timeouts”. Fue: afínalos con medición y alcance. Revirtieron los ajustes globales del resolvedor, luego aplicaron políticas más estrechas para servicios específicos con lógica de reintento adecuada. SSH volvió a ser aburrido. En producción, aburrido es una característica.

3) La práctica correcta y aburrida que salvó el día: “Siempre tener un camino fuera de banda y recargar, no reiniciar”

Un equipo de infraestructura planeó desactivar UseDNS y GSSAPIAuthentication en una flota de servidores Debian 13 tras quejas repetidas sobre inicios lentos desde una red partner. Hicieron lo correcto: escribieron un drop-in, validaron la sintaxis con sshd -t y usaron systemctl reload en vez de restart.

Durante el despliegue, un host se comportó distinto. Un fragmento de configuración legado tenía un typo en una directiva no relacionada. Nunca se había notado porque sshd ya estaba corriendo y nadie había forzado un parseo completo recientemente. La recarga habría fallado si hubieran usado restart. Peor: un restart podría haber matado su único acceso remoto.

Porque usaron validación y reload, lo detectaron con seguridad. Arreglaron el typo, recargaron de nuevo y siguieron adelante. Sin heroísmos, sin acceso de emergencia a consola, sin pánico “¿alguien en el datacenter puede enchufar un monitor?”.

También tenían una segunda vía de acceso vía un bastión con un mecanismo de autenticación distinto. Nunca se usó, pero ese es el punto. La redundancia es un seguro: caro hasta que resulta barato.

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

1) Síntoma: pausa de 10–30s antes del prompt de contraseña

Causa raíz: sshd esperando DNS inverso (PTR) para la IP del cliente; reintentos/timeouts del resolvedor.

Solución: Poner UseDNS no en sshd, y/o arreglar registros PTR y alcanzabilidad de DNS. Verifica con sshd -T y getent hosts <client-ip>.

2) Síntoma: pausa en “Next authentication method: gssapi-with-mic”

Causa raíz: Intento de negociación GSSAPI/Kerberos primero; descubrimiento de realm/KDC lento o fallando.

Solución: Desactiva GSSAPIAuthentication en cliente/servidor si no se usa. Si se usa, arregla configuración Kerberos, alcanzabilidad de KDCs y DNS SRV/mapeo de realms.

3) Síntoma: SSH por IP es instantáneo, por hostname es lento

Causa raíz: Problemas de resolución DNS del cliente (dominios de búsqueda, timeouts AAAA IPv6, resolvedor malo).

Solución: Usa getent hosts y resolvectl status para encontrar dónde se pausa la resolución. Corrige servidores resolv y dominios de búsqueda; considera AddressFamily inet como diagnóstico (no solución permanente).

4) Síntoma: retraso después de “Authenticated” pero antes del prompt

Causa raíz: Módulos PAM de sesión, montajes de home en red, SSSD/LDAP o scripts de inicio de shell lentos.

Solución: Revisa journalctl -u ssh para tiempos de sesión, luego inspecciona la configuración PAM y la inicialización del shell del usuario. No pierdas tiempo cambiando UseDNS si el retraso es post-auth.

5) Síntoma: solo usuarios VPN ven inicios lentos

Causa raíz: Falta de zona reverse para el pool VPN o servidores DNS inalcanzables desde la ruta de red del servidor. A veces problemas de MTU/fragmentación hacen que DNS “más o menos” funcione.

Solución: Implementa PTR para pools VPN y asegura que DNS sea alcanzable; en paralelo, desactiva UseDNS para eliminar la dependencia.

6) Síntoma: cambiar /etc/ssh/sshd_config no hizo nada

Causa raíz: Fragmentos de configuración en Debian en /etc/ssh/sshd_config.d/; un fragmento sobreescribe tu ajuste.

Solución: Usa sshd -T para confirmar la configuración efectiva y busca fragmentos con grep -R. Pon tu override en 99-local.conf.

Listas de verificación / plan paso a paso (despliegue seguro)

Paso a paso: acelerar inicios de sesión de forma segura en un único servidor Debian 13

1. Confirma el cuello de botella. Desde un cliente, ejecuta ssh -vvv y anota dónde se pausa.
2. Prueba DNS inverso desde el servidor. Ejecuta getent hosts <client-ip>; si es lento, tienes la probable causa.
3. Revisa ajustes efectivos de sshd. Ejecuta sudo sshd -T | egrep 'usedns|gssapiauthentication'.
4. Crea un override local. Usa /etc/ssh/sshd_config.d/99-local.conf para no pelear con fragmentos del proveedor.
5. Valida la configuración. Ejecuta sudo sshd -t. Sin salida significa OK.
6. Recarga, no reinicies. sudo systemctl reload ssh mantiene sesiones existentes y reduce “ups”.
7. Verifica la configuración efectiva nueva. sudo sshd -T otra vez.
8. Vuelve a probar desde la red afectada. Cronométralo con /usr/bin/time -p ssh ... true.
9. Observa logs. Revisa journalctl -u ssh -S -5m para tiempos mejorados.
10. Luego arregla DNS correctamente. Si UseDNS enmascaraba PTR/DNS roto, agenda la remediación. La deuda operativa acumula intereses.

Checklist de gestión de cambios: despliegue en flota sin drama

• Elige 2–3 hosts representativos (diferentes subredes, roles, patrones de autenticación).
• Captura tiempos base (hostname e IP, con y sin GSSAPI).
• Implementa la configuración vía automatización (un drop-in consistente por host).
• Recarga sshd por lotes; monitoriza anomalías de autenticación.
• Confirma que ningún equipo depende de Kerberos SSH antes de desactivar GSSAPI a nivel servidor.
• Asegura una vía de acceso alternativa (bastion, consola, fuera de banda) antes de tocar SSH a escala.
• Tras el despliegue, verifica: configuración efectiva de sshd, latencia de login y claridad de logs.

Preguntas frecuentes

1) ¿Debería siempre poner UseDNS no en los servidores?

En la mayoría de entornos: sí. Si no usas controles de acceso basados en nombres de host en sshd, desactivarlo elimina una dependencia frágil y acelera logins cuando DNS falla.

2) ¿Desactivar UseDNS reduce la seguridad?

Puede reducir una “seguridad mal planteada”. Si confiabas en hostnames de clientes para control de acceso, eso ya era frágil. Prefiere controles basados en IP y en identidad por clave/certificado.

3) Usamos Kerberos. ¿Podemos arreglar SSH lento sin desactivar GSSAPI?

Sí. Arregla la ruta Kerberos/DNS subyacente: asegura que los KDC sean alcanzables, que el mapeo de realms esté correcto y que los registros SRV de DNS resuelvan rápido desde servidor y cliente.

4) ¿Por qué SSH es lento solo desde una oficina o VPN?

Porque la alcanzabilidad de DNS y las zonas inversas suelen variar por red. Esa oficina puede consultar un resolvedor distinto, o el pool VPN puede no tener registros PTR.

5) Desactivé GSSAPI en el servidor, pero los clientes siguen lentos. ¿Por qué?

Los clientes aún pueden tardar resolviendo el hostname del servidor (DNS del cliente), o el retraso puede ser post-auth (PAM, montajes, scripts). Usa ssh -vvv y logs del servidor para localizar la etapa.

6) ¿Cuál es la forma más segura de probar cambios en sshd de forma remota?

Usa sshd -t antes de aplicar cambios, luego systemctl reload ssh. Para depuración más profunda, ejecuta un sshd de depuración en el puerto 2222 temporalmente.

7) ¿IPv6 puede causar inicios lentos incluso si “no usamos IPv6”?

Sí. Los clientes pueden intentar búsquedas AAAA y conexiones IPv6 primero. Si IPv6 está medio habilitado (rutas faltantes, firewalls bloqueando), obtendrás timeouts. Diagnostica con timing por hostname vs IP y pruebas de resolvedor.

8) ¿Desactivar UseDNS romperá otras cosas?

Principalmente cambia cómo sshd resuelve y registra nombres de clientes. Si tienes procesamiento de logs que espera hostnames, ajústalo. Operativamente, registrar IPs suele ser suficiente.

9) Mi retraso es después de “session opened” en los logs. ¿Sigue siendo DNS/GSSAPI?

Menos probable. Eso apunta a trabajo de sesión PAM, directorios home en red o inicio del shell. La solución está en PAM, SSSD/LDAP, automount o dotfiles del usuario—no en UseDNS de sshd.

10) ¿Cuál es la diferencia entre arreglar DNS y simplemente desactivar UseDNS?

Desactivar UseDNS evita que sshd espere búsquedas reversas. Arreglar DNS mejora todo el entorno: enriquecimiento de logs, Kerberos, discovery de servicios y cualquier otra cosa que haga lookups. Haz ambas si puedes.

Conclusión: qué hacer a continuación

Si los inicios de sesión SSH en Debian 13 son lentos, no adivines. Localiza la pausa con ssh -vvv, confirma el comportamiento de DNS con getent/dig, y verifica las opciones efectivas de sshd con sshd -T. Luego haz lo práctico:

• Poner UseDNS no salvo que tengas una razón específica y probada para no hacerlo.
• Poner GSSAPIAuthentication no salvo que ejecutes Kerberos SSH SSO y puedas probar que está sano.
• Recargar sshd con seguridad (valida la config, recarga en vez de reiniciar).
• Arreglar DNS correctamente después: zonas reversas para subredes cliente, resolvers alcanzables y menos “dominios de búsqueda creativos”.

Tu recompensa es inmediata: SSH deja de comportarse como si pensara profundamente sobre tu petición y vuelve a actuar como una herramienta.