Debian 13 : SSH lent à la connexion — DNS et GSSAPI accélèrent instantanément (cas #65)

Ce que signifie réellement « SSH lent » (symptômes importants)

« SSH est lent » est imprécis. Il faut savoir à quel stade cela ralentit, car chaque étape implique des coupables différents. SSH est une chaîne : connexion TCP → échange de clés → authentification → mise en place de la session. DNS et GSSAPI peuvent bloquer différentes parties de cette chaîne, et ils laissent des empreintes bien distinctes.

Empreintes courantes de lenteur de connexion

• Délai avant l’invite de mot de passe (ou avant qu’une méthode d’authentification soit proposée) : souvent une recherche DNS inverse (le serveur tente de résoudre l’IP du client en nom d’hôte) ou une négociation GSSAPI.
• Délai après une authentification réussie (mot de passe accepté, mais invite retardée) : modules PAM, création de répertoire personnel/automount, scripts de démarrage du shell, ou DNS durant la mise en place de la session PAM.
• Délai seulement depuis certains réseaux (VPN du bureau lent, domicile rapide) : DNS à voiles divisées, pare-feu bloquant UDP/TCP 53, ou atteignabilité du royaume Kerberos depuis un côté.
• Délai seulement en utilisant un nom d’hôte (l’IP est rapide) : résolution DNS côté client ou recherches de suffixes de domaine problématiques.
• Délai seulement lors de la première connexion (les suivantes sont rapides) : cache DNS négatif, réchauffement du résolveur, ou comportement de nouvelle tentative de GSSAPI.

Nous nous concentrons sur Debian 13 avec OpenSSH, et sur les deux corrections les plus rapides « gains instantanés » quand la lenteur survient avant que vous obteniez un shell : DNS inverse (UseDNS) et négociation GSSAPI (Kerberos).

Blague #1 : SSH est comme un videur qui insiste pour vérifier votre pièce d’identité dans une base de données « temporairement indisponible ». Vous n’êtes pas refusé — simplement coincé dehors.

Recette de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Ceci est le flux « je suis de garde, il est 02:00 et les dirigeants attendent ». Il est conçu pour trouver le goulot d’étranglement en quelques minutes, pas pour satisfaire votre curiosité.

Premier : localiser le délai (vue client)

1. Exécutez SSH avec des indices temporels et une sortie verbeuse et voyez quelle ligne marque une pause.
2. Si la pause se produit autour des lignes GSSAPI, suspectez Kerberos/GSSAPI. Si la pause se produit autour de « Authentications that can continue » ou avant le banner, suspectez une DNS inverse côté serveur.

Deuxième : vérifier le comportement DNS (vue serveur)

1. Testez les résolutions directe et inverse pour l’IP du client depuis le serveur en utilisant le résolveur système.
2. Recherchez des timeouts, des parcours longs de suffixes de recherche, ou des enregistrements PTR pointant vers des incongruités.

Troisième : confirmer que sshd attend ces éléments (journaux et debug sshd)

1. Augmentez temporairement la journalisation de sshd pour une fenêtre de test unique ou lancez un sshd en mode debug sur un port alternatif.
2. Corrélez les horodatages : si les journaux sshd montrent des gaps autour de « reverse mapping checking » ou GSSAPI, vous avez votre réponse.

Après cela, vous décidez : désactiver UseDNS (généralement oui), désactiver GSSAPIAuthentication (souvent oui sauf si vous utilisez Kerberos), ou réparer le chemin DNS/Kerberos sous-jacent (meilleur à long terme).

Pourquoi DNS et GSSAPI bloquent SSH sur Debian 13

OpenSSH est conservateur : il essaie de collecter des informations sur le client connecté et il tente des méthodes d’authentification dans un ordre utile aux environnements d’entreprise. Deux choses importent :

• Les recherches DNS inverses sont utilisées pour la journalisation et (parfois) la logique de contrôle d’accès. Le serveur peut tenter de mapper l’IP du client en un nom d’hôte (enregistrement PTR), et parfois valider que ce nom résout de nouveau vers la même IP (vérification forward-confirmed reverse DNS, ou FCrDNS).
• GSSAPIAuthentication permet le single sign-on basé sur Kerberos. Si activé et que le client le propose (ou que le serveur le priorise), sshd peut tenter de le négocier. Si Kerberos est mal configuré, injoignable, bloqué par un pare-feu ou lent, SSH attend.

Sur Debian 13, vous verrez le même comportement fondamental que sur d’autres versions modernes : OpenSSH est construit avec des valeurs par défaut raisonnables pour la compatibilité générale, et la pile de résolveur peut inclure systemd-resolved ou le résolveur glibc classique selon votre configuration. La douleur vient généralement d’environnements où le DNS n’est pas constamment rapide et correct.

DNS inverse : le tueur silencieux classique

La DNS inverse (enregistrements PTR) est facile à négliger parce que la plupart des applications s’en moquent. SSH, lui, s’en préoccupe. Pas toujours, et pas dans toutes les configurations, mais suffisamment pour devenir une cause fréquente de « SSH lent ».

Les pires cas sont :

• L’IP du client n’a pas d’enregistrement PTR et votre résolveur réessaie plusieurs serveurs avec de longs timeouts.
• Le PTR existe mais pointe vers un nom d’hôte qui ne résout pas en retour (la vérification FCrDNS échoue, d’autres recherches ont lieu).
• Les serveurs DNS sont joignables mais lents, ou seulement joignables via un chemin VPN avec perte de paquets.
• Votre résolveur a des search domains agressifs et tente plusieurs suffixes avant d’échouer.

GSSAPI : excellent quand ça marche, collant quand ça ne marche pas

Kerberos est excellent quand il est correctement déployé. Quand ce n’est pas le cas, il échoue d’une manière qui ressemble à « SSH est bloqué ». Si GSSAPIAuthentication est activé dans sshd et que le client l’essaie, les deux côtés peuvent tenter de trouver des realms, contacter des KDC, et valider des tickets. Si l’un de ces éléments dépend de DNS (et c’est le cas), vous pouvez obtenir un double effet : GSSAPI attend DNS qui attend un réseau défaillant.

Blague #2 : GSSAPI est comme ce collègue qui « a juste besoin de cinq minutes » pour rejoindre un appel, mais qui doit d’abord installer une mise à jour.

Une citation sur la fiabilité (paraphrasée)

Idée paraphrasée : « L’espoir n’est pas une stratégie. » — citée dans les cercles SRE, attribuée à General Gordon R. Sullivan. Opérationnellement, cela signifie mesurer et vérifier, pas espérer.

Faits intéressants et historique (pour comprendre l’étrangeté)

• Fait 1 : OpenSSH est devenu l’implémentation SSH de facto après que l’original ait eu des restrictions de licence ; OpenSSH a privilégié des valeurs par défaut sécurisées, même si elles étaient parfois bavardes.
• Fait 2 : La DNS inverse (enregistrements PTR) vit dans une zone spéciale sous in-addr.arpa (IPv4) et ip6.arpa (IPv6). Beaucoup d’organisations la traitent comme optionnelle — jusqu’à ce que la journalisation et les contrôles d’accès en dépendent.
• Fait 3 : Le concept de « forward-confirmed reverse DNS » est né de l’hygiène anti-usurpation : ce n’est pas une identité forte, mais cela réduit les erreurs de labellisation occasionnelles.
• Fait 4 : Kerberos s’appuie beaucoup sur le DNS dans de nombreux déploiements (enregistrements SRV, mapping de realms), donc « Kerberos lent » signifie souvent « DNS lent, en double ».
• Fait 5 : La vérification de la clé d’hôte SSH concerne l’identité du serveur, pas celle du client ; les recherches DNS inverses servent surtout à enrichir les journaux et à appliquer des politiques.
• Fait 6 : systemd-resolved a introduit de nouveaux comportements de cache et de stub-resolver dans de nombreux environnements Linux ; il a résolu certains problèmes et a aussi créé de nouveaux chemins de débogage « ça dépend ».
• Fait 7 : IPv6 peut amplifier les problèmes DNS : les clients peuvent préférer les enregistrements AAAA, et les recherches inverses IPv6 sont plus longues et peuvent déclencher davantage de timeouts si mal configurées.
• Fait 8 : NSS (Name Service Switch) peut provoquer des délais surprenants s’il consulte des sources comme LDAP/SSSD pour les recherches d’hôtes ; DNS n’est pas toujours le seul service de noms en jeu.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des vérifications éprouvées sur le terrain. Chaque tâche inclut : une commande, une sortie réaliste, ce que cela signifie, et quoi faire ensuite. Exécutez-les sur Debian 13 sauf mention contraire. Remplacez les IP/hostnames par les vôtres.

Task 1: Identify where SSH pauses (client-side 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.

Signification : Le client a essayé GSSAPI en premier. Si vous voyez une pause de plusieurs secondes entre « Next authentication method: gssapi-with-mic » et l’échec, la négociation GSSAPI vous coûte du temps.

Décision : Si vous n’utilisez pas Kerberos SSO pour SSH, désactivez GSSAPI côté client et/ou serveur. Si vous l’utilisez, vérifiez l’atteignabilité des KDC et le DNS pour SRV/mapping de realms.

Task 2: Time the SSH connection precisely

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

Signification : Avec GSSAPI désactivé et une IP directe, c’est rapide. Cela implique fortement GSSAPI et/ou DNS quand vous utilisez des noms d’hôtes.

Décision : Si ceci est rapide mais que SSH normal est lent, vous avez un problème de configuration/chemin plutôt que CPU, crypto ou réseau de base.

Task 3: Compare hostname vs IP performance

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

Signification : La connexion par nom est lente ; cela signifie souvent un problème de DNS côté client (search domains, préférence IPv6, ou résolveur cassé).

Décision : Enquêter sur la résolution DNS sur le client : getent hosts, configuration du résolveur, et vérifier si les requêtes AAAA expirent.

Task 4: Watch DNS resolution through glibc/NSS (client or server)

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

Signification : getent utilise NSS (pas seulement DNS brut). S’il est lent, SSH utilisant des noms d’hôtes sera lent aussi.

Décision : Si getent marque une pause, inspectez /etc/nsswitch.conf et les services de noms (DNS, files, ldap, mdns). Vous pouvez être bloqué sur LDAP ou un résolveur mort.

Task 5: Verify reverse DNS lookup speed for a client IP (server-side)

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

Signification : C’est la même recherche que sshd peut faire pour la journalisation et la politique. Si cela prend des secondes ou timeout, sshd attendra.

Décision : Si c’est lent ou vide, soit corrigez les enregistrements PTR et la joignabilité du résolveur, soit désactivez UseDNS dans sshd pour arrêter d’attendre la DNS inverse.

Task 6: Confirm forward-confirmation (PTR maps back)

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

Signification : La recherche directe renvoie l’IP d’origine. C’est un mapping propre et cela réduit les comportements étranges de sshd lorsqu’il tente une vérification forward-confirmed.

Décision : Si la recherche directe pointe ailleurs, corrigez le DNS. Si vous ne pouvez pas (réseaux tiers), désactivez UseDNS et évitez les contrôles d’accès basés sur le nom d’hôte.

Task 7: Check resolver configuration quickly

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

Signification : Le stub resolver 127.0.0.53 indique généralement que systemd-resolved est dans la chaîne. Les search domains peuvent provoquer plusieurs tentatives de requêtes.

Décision : Si les search domains sont nombreux ou incorrects, réduisez-les. Si systemd-resolved est malade, réparez-le ou pointez resolv.conf vers de vrais serveurs DNS.

Task 8: Inspect systemd-resolved status and upstream servers

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

Signification : Confirme quels serveurs DNS sont réellement utilisés. Si ces serveurs ne sont joignables que depuis certains VLAN, vous avez trouvé pourquoi SSH est lent depuis « cet endroit ».

Décision : Réparez le routage/pare-feu vers les serveurs DNS, ou configurez le DNS par lien correctement. Ne laissez pas les clients deviner.

Task 9: Test raw DNS query latency (server-side) with 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

Signification : 18 ms, c’est correct. Si vous voyez 2000 ms ou des timeouts, c’est votre délai SSH. SSH n’est pas spécial ; il attend juste DNS.

Décision : Si le temps de requête est élevé, corrigez la latence DNS ou désactivez UseDNS. Si c’est un timeout, vérifiez les ACL réseau et si TCP/UDP 53 est bloqué.

Task 10: Find sshd’s current effective settings

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

Signification : C’est la vérité, y compris les valeurs par défaut et les fragments inclus. Si usedns yes et que la DNS inverse est lente, sshd va probablement se bloquer.

Décision : Si vous n’avez pas besoin du contrôle d’accès basé sur le nom d’hôte et que la DNS inverse est instable, mettez UseDNS no. Si vous n’utilisez pas Kerberos SSO, mettez GSSAPIAuthentication no.

Task 11: Observe sshd logs for timing gaps

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)

Signification : Huit secondes entre « Connection from … » et « Accepted publickey … » indique souvent un délai pré-auth : DNS inverse ou tentative GSSAPI avant l’auth par clé.

Décision : Corrélez avec la sortie client -vvv. Si la pause est avant « Accepted publickey », ajustez UseDNS/GSSAPI ; si elle est après, regardez du côté de PAM et du démarrage du shell.

Task 12: Run a debug sshd on an alternate port (safe, temporary)

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]

Signification : -ddd est bruyant mais montre quelle méthode est tentée et où ça marque une pause. Si la sortie gèle après une ligne de DNS inverse ou GSSAPI, vous avez isolé le coupable sans toucher au processus sshd de production.

Décision : N’utilisez ceci que brièvement et sur un hôte protégé. Une fois confirmé, arrêtez-le et appliquez les modifications de configuration au service réel.

Task 13: Validate Kerberos basics (only if you actually use it)

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

Signification : Aucun ticket n’existe, donc l’auth GSSAPI échouera et peut être lent si la découverte de realm est lente.

Décision : Si vous voulez Kerberos SSO, obtenez un ticket (kinit) et corrigez le mapping realm/KDC. Si vous n’en avez pas besoin, désactivez GSSAPI pour SSH afin d’éviter des tentatives inutiles.

Task 14: Check whether ssh is offering GSSAPI (client config)

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

Signification : Le client va essayer GSSAPI en premier. Même si le serveur est correct, le client peut perdre du temps à l’essayer.

Décision : Désactivez GSSAPI côté client pour les hôtes affectés, ou globalement si vous ne l’utilisez nulle part.

Task 15: Confirm SSHD config fragments (Debian includes)

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

Signification : Vos paramètres « réels » peuvent provenir d’un drop-in. Les gens éditent /etc/ssh/sshd_config, redémarrent ssh, et se demandent pourquoi rien n’a changé.

Décision : Modifiez le bon fichier (préférez un nouveau drop-in avec une priorité plus élevée, par ex. 99-local.conf), puis vérifiez avec sshd -T.

Task 16: Validate SSH configuration before reload

cr0x@server:~$ sudo sshd -t

Signification : Pas de sortie signifie que la syntaxe est OK. S’il y a une erreur, sshd l’imprime et sort avec un code non nul.

Décision : Ne redémarrez jamais sshd sans sshd -t d’abord sur un système distant. Vous n’avez droit à planter votre accès qu’une seule fois avant que ça devienne un trait de personnalité.

Corrections qui font vraiment la différence (UseDNS, GSSAPI et alliés)

Fix 1: Disable reverse DNS lookups in sshd (most common win)

Si votre organisation ne dépend pas des contrôles d’accès SSH basés sur les noms d’hôtes (par ex. vous n’utilisez pas des motifs AllowUsers/DenyUsers basés sur les noms, et vous n’utilisez pas l’authentification basée sur l’hôte liée au DNS), désactivez la DNS inverse.

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

Ce que cela fait : Empêche sshd d’effectuer des recherches DNS inverses de l’IP client pendant la gestion de la connexion. Vos journaux utiliseront les IP plus régulièrement. Vos connexions ne dépendront plus des timeouts PTR.

Compromis : Vous perdez la résolution automatique des noms d’hôte dans les journaux sshd (vous verrez des IP). Pour la réponse aux incidents, les IP sont souvent préférables car elles sont plus difficiles à « renommer ».

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

Point de décision : Si le reload fonctionne et que sshd -T affiche usedns no, retestez SSH depuis le réseau client problématique. Si la lenteur disparaît, votre chemin PTR/DNS est la cause racine. Ensuite, corrigez DNS correctement si vous voulez des journaux plus lisibles ; vous n’êtes plus bloqué.

Fix 2: Disable GSSAPIAuthentication in sshd (when you don’t use Kerberos SSH)

Beaucoup d’environnements n’utilisent pas Kerberos pour SSH, mais héritent de configurations qui l’activent. C’est du temps perdu et des modes d’échec supplémentaires. Désactivez-le sauf si vous pouvez expliquer pourquoi il doit être activé.

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

Point de décision : Si vous dépendez de Kerberos pour le SSO SSH, ne faites pas cela globalement. Utilisez des blocs Match ou la config client par hôte pour le conserver là où il est nécessaire et le désactiver ailleurs.

Fix 3: Disable GSSAPI on the client side (fast containment)

Si vous ne pouvez pas changer le serveur (appliance gérée, friction politique, ou gel des changements), désactivez GSSAPI côté client. Utile pour les jump hosts et les portables des opérateurs.

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

Signification : Vous arrêtez d’essayer GSSAPI en premier, et vous ne payez plus le coût de la négociation.

Décision : Déployez cela aux groupes d’utilisateurs affectés. Si vous gérez les dotfiles de façon centralisée, tenez-le ciblé ; ne cassez pas l’équipe qui utilise réellement Kerberos.

Fix 4: Make DNS fast and boring (the real fix)

Désactiver UseDNS est une mitigation valable. Corriger le DNS est la cure. En production, faites les deux : arrêter l’hémorragie maintenant, puis éliminer le risque sous-jacent.

Améliorations DNS concrètes qui comptent pour la latence SSH :

• Assurez-vous que tous les sous-réseaux clients qui atteignent les serveurs ont aussi des zones inverse fonctionnelles (enregistrements PTR) ou au moins des réponses non time-out.
• Assurez-vous que les serveurs DNS sont joignables depuis chaque chemin réseau d’origine SSH (VPN, bastions, Wi‑Fi bureau, runners CI).
• Réduisez les timeouts et les retries du résolveur seulement si vous comprenez l’impact. Sur-tuner les timeouts transforme un DNS intermittent en « tout échoue vite ».
• Élaguez les search domains inutiles. Chaque suffixe supplémentaire = des requêtes supplémentaires en cas d’échec.

Fix 5: Avoid hostname-based access controls if DNS is not trustworthy

Si vous avez des logiques AllowUsers *@somehost basées sur les noms d’hôtes clients, vous faites du DNS une partie de votre périmètre de sécurité. Cela peut marcher, mais seulement si le DNS est correct, rapide et contrôlé. Dans de nombreux réseaux, il n’est aucun de ces trois.

Préférez des contrôles basés sur l’IP (règles de pare‑feu, security groups) ou des contrôles d’identité basés sur des clés (authorized_keys, certificats). Utilisez les noms d’hôtes pour la commodité, pas pour l’application, à moins d’être prêt à opérer le DNS comme un système critique — parce que c’est le cas.

Fix 6: If slowness is after authentication, don’t scapegoat DNS

Cet article traite de DNS et GSSAPI parce qu’ils apportent des améliorations « instantanées » dans le cas le plus courant de lenteur de connexion. Mais si votre délai survient après une authentification réussie, vérifiez :

• pam_mkhomedir créant des répertoires personnels lors de la première connexion
• Des répertoires personnels réseau (NFS/Autofs) qui attendent des montages
• SSSD/LDAP qui ralentissent dans PAM account/session
• Scripts de démarrage du shell lents (.bashrc, .profile) appelant des commandes réseau

Étape différente de la chaîne, correctif différent. Diagnostiquez avant de changer.

Trois mini-récits d’entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « La DNS inverse est optionnelle »

L’entreprise était en pleine migration vers un nouveau fournisseur VPN. Le plan de projet couvrait les routes, le MFA et le déploiement client. La DNS inverse n’était pas dans la liste parce que, historiquement, personne ne « l’utilisait ». Cette hypothèse était vraie dans le sens étroit où personne n’avait ouvert un ticket intitulé « PTR records ».

Le premier jour, les ingénieurs ont commencé à signaler que les SSH vers les hôtes de production prenaient 20–30 secondes avant une invite de mot de passe. Certaines sessions allaient bien ; d’autres non. Le facteur commun s’est avéré être la nouvelle plage d’adresses VPN. Elle vivait dans un nouveau sous‑réseau sans zone inverse déléguée, et les serveurs DNS pour cette plage n’étaient accessibles que depuis le datacenter — pas depuis le segment où sshd tournait.

L’équipe de garde a d’abord cherché du côté du CPU et de l’entropie. Ils ont regardé les moyennes de charge, vérifié la génération de nombres aléatoires, et même basculé quelques ciphers « pour voir ». Rien. Pendant ce temps, le helpdesk recevait des incidents « SSH peu fiable » et les escaladait comme « régression de performance serveur ».

La correction fut ennuyeuse : soit ajouter des PTR (et rendre le DNS joignable depuis les serveurs), soit empêcher sshd d’attendre la DNS inverse. Ils ont choisi une approche en deux étapes : mitigation immédiate avec UseDNS no. Ensuite, l’équipe réseau a implémenté des zones inverses pour les pools VPN et a validé la joignabilité depuis chaque VLAN serveur acceptant SSH. La seconde étape a compté car d’autres systèmes — enrichissement des logs et corrélation SIEM — en ont également bénéficié. Mais SSH a retrouvé son invite en quelques minutes, ce qui leur a acheté du temps.

2) L’optimisation qui s’est retournée contre eux : « Raccourcir les timeouts du résolveur »

Une autre organisation a eu marre des longues suspensions d’applications lors d’urgences DNS. Quelqu’un, avec de bonnes intentions et un peu trop de confiance, a changé le comportement du résolveur globalement : moins de retries, timeouts plus courts. Cela rendait les échecs plus rapides, ce qui semblait une amélioration.

Puis ils ont eu un nouveau type d’incident : pas « DNS down », mais « DNS flaky ». Avec une légère perte de paquets, l’ancienne configuration récupérait parfois après une nouvelle tentative. La nouvelle échouait rapidement et systématiquement. SSH fut l’un des premiers canaris : les tentatives de connexion échouaient ou prenaient des chemins étranges (tentatives IPv6 échouant, basculement vers IPv4, puis tentative GSSAPI, puis timeout).

Le résultat opérationnel était pire qu’avant. Plutôt que des sessions lentes mais fonctionnelles, les ingénieurs subissaient des verrous intermittents sur les jump hosts. Cela a augmenté les enjeux parce que le dépannage nécessitait un accès qui était lui-même dégradé.

La leçon n’était pas « ne jamais tuner les timeouts ». C’était : tunez avec mesure et périmètre. Ils sont revenus en arrière sur les tweaks globaux, puis ont appliqué des politiques plus étroites pour des services spécifiques avec une logique de retry appropriée. SSH est redevenu ennuyeux. En production, l’ennui est une fonctionnalité.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Toujours garder un chemin hors bande et recharger, ne pas redémarrer »

Une équipe d’infra a prévu de désactiver UseDNS et GSSAPIAuthentication sur une flotte de serveurs Debian 13 après des plaintes répétées sur des connexions lentes depuis un réseau partenaire. Ils ont fait la bonne chose : écrit un drop-in, validé la syntaxe avec sshd -t, et utilisé systemctl reload au lieu d’un restart.

Pendant le déploiement, un hôte s’est comporté différemment. Un fragment de config legacy avait une faute de frappe dans une directive non liée. Elle n’avait jamais été remarquée parce que sshd tournait déjà et personne n’avait déclenché récemment un parse complet de la config. Le reload aurait échoué s’ils avaient utilisé un restart. Pire : un restart aurait pu tuer leur unique chemin d’accès distant.

Parce qu’ils ont utilisé la validation et le reload, ils l’ont attrapé en toute sécurité. Ils ont corrigé la faute, rechargé de nouveau, et ont continué. Pas d’héroïsme, pas d’accès console en urgence, pas de panique « quelqu’un peut‑il aller brancher un écran au datacenter ».

Ils disposaient aussi d’un second chemin d’accès via un bastion avec un mécanisme d’auth différent. Il n’a jamais été utilisé, mais c’est bien le but. La redondance est une assurance : coûteuse jusqu’à ce qu’elle devienne bon marché au moment critique.

Erreurs courantes : symptôme → cause première → correctif

1) Symptom: 10–30s pause before password prompt

Root cause : sshd attend la DNS inverse (PTR) pour l’IP client ; retries/timeouts du résolveur.

Fix : Mettre UseDNS no dans sshd, et/ou corriger les PTR et la joignabilité DNS. Vérifiez avec sshd -T et getent hosts <client-ip>.

2) Symptom: pause on “Next authentication method: gssapi-with-mic”

Root cause : Négociation GSSAPI/Kerberos tentée en premier ; découverte realm/KDC lente ou échouant.

Fix : Désactiver GSSAPIAuthentication sur client/serveur si inutilisé. Si utilisé, réparer la config Kerberos, l’atteignabilité KDC, et le DNS SRV/mapping de realms.

3) Symptom: SSH by IP is instant, by hostname is slow

Root cause : Problèmes de résolution DNS côté client (search domains, timeouts AAAA IPv6, mauvais résolveur).

Fix : Utiliser getent hosts et resolvectl status pour trouver où la résolution bloque. Corriger les serveurs résolveurs et les search domains ; envisagez AddressFamily inet comme diagnostic (pas une solution permanente).

4) Symptom: delay after “Authenticated” but before prompt

Root cause : Modules de session PAM, montages de répertoires personnels réseau, SSSD/LDAP, ou scripts de démarrage du shell.

Fix : Vérifier journalctl -u ssh pour le timing de session, puis inspecter la config PAM et l’initialisation du shell utilisateur. Ne perdez pas de temps à basculer UseDNS si le délai est post‑auth.

5) Symptom: only VPN users see slow logins

Root cause : Zone DNS inverse manquante pour le pool VPN ou serveurs DNS inaccessibles depuis le chemin réseau du serveur. Parfois des problèmes MTU/fragmentation rendent le DNS « partiellement » fonctionnel.

Fix : Implémenter des PTR pour les pools VPN et assurer la joignabilité DNS ; en parallèle, désactiver UseDNS pour retirer la dépendance.

6) Symptom: changing /etc/ssh/sshd_config did nothing

Root cause : Les includes Debian dans /etc/ssh/sshd_config.d/ ; un fragment écrase votre réglage.

Fix : Utiliser sshd -T pour confirmer la config effective et chercher les fragments avec grep -R. Placez votre override dans 99-local.conf.

Listes de contrôle / plan étape par étape (déploiement sûr)

Step-by-step: speed up logins safely on a single Debian 13 server

1. Confirmer le goulot. Depuis un client, exécutez ssh -vvv et notez où ça marque une pause.
2. Tester la DNS inverse depuis le serveur. Lancez getent hosts <client-ip> ; si c’est lent, vous avez probablement la cause.
3. Vérifier les réglages effectifs de sshd. Exécutez sudo sshd -T | egrep 'usedns|gssapiauthentication'.
4. Créer un override local. Utilisez /etc/ssh/sshd_config.d/99-local.conf pour ne pas lutter contre les fragments du fournisseur.
5. Valider la config. Exécutez sudo sshd -t. Pas de sortie signifie OK.
6. Reload, pas restart. sudo systemctl reload ssh préserve les sessions existantes et réduit les risques d’« oups ».
7. Vérifier la config effective. sudo sshd -T à nouveau.
8. Retester depuis le réseau affecté. Chronométrez avec /usr/bin/time -p ssh ... true.
9. Surveiller les journaux. Vérifiez journalctl -u ssh -S -5m pour l’amélioration des timings.
10. Puis réparer le DNS correctement. Si UseDNS masquait des PTR/DNS cassés, planifiez la remédiation DNS. La dette opérationnelle accumule des intérêts.

Change-management checklist: fleet rollout without drama

• Choisir 2–3 hôtes représentatifs (différents subnets, rôles, patterns d’authentification).
• Capturer des timings de base (nom d’hôte et IP, avec et sans GSSAPI).
• Implémenter la config via automatisation (un fichier drop-in, cohérent sur les hôtes).
• Recharger sshd par lots ; surveiller les anomalies d’authentification.
• Confirmer qu’aucune équipe ne dépend de Kerberos SSH avant de désactiver GSSAPI globalement.
• Assurer un chemin d’accès alternatif (bastion, console, hors bande) avant de toucher SSH à grande échelle.
• Après déploiement, vérifier : config effective de sshd, latence de connexion, et clarté des logs.

FAQ

1) Should I always set UseDNS no on servers?

Dans la plupart des environnements : oui. Si vous n’utilisez pas de contrôles d’accès basés sur le nom d’hôte dans sshd, le désactiver supprime une dépendance fragile et accélère les connexions en cas de problèmes DNS.

2) Does disabling UseDNS reduce security?

Cela peut réduire une sécurité « mal placée ». Si vous vous basiez sur les noms d’hôtes clients pour l’accès, c’était déjà fragile. Préférez des contrôles réseau basés sur l’IP et des identités basées sur clés/certificats.

3) We use Kerberos. Can we still fix slow SSH without disabling GSSAPI?

Oui. Réparez le chemin Kerberos/DNS sous-jacent : assurez-vous que les KDC sont joignables, le mapping des realms est correct, et les enregistrements SRV DNS se résolvent rapidement depuis les réseaux serveur et client.

4) Why is SSH slow only from one office or VPN?

Parce que la joignabilité DNS et les zones inverses diffèrent souvent par réseau. Ce bureau peut interroger un résolveur différent, ou le pool VPN peut manquer de PTR.

5) I disabled GSSAPI on the server, but clients are still slow. Why?

Les clients peuvent encore être lents à résoudre le nom du serveur (DNS côté client), ou le délai peut être post‑auth (PAM, montages, scripts shell). Utilisez ssh -vvv plus les logs serveur pour localiser l’étape.

6) What’s the safest way to test sshd changes remotely?

Utilisez sshd -t avant d’appliquer des changements, puis systemctl reload ssh. Pour du debug plus profond, lancez un sshd de debug séparé sur le port 2222 temporairement.

7) Can IPv6 cause slow SSH logins even if we “don’t use IPv6”?

Oui. Les clients peuvent tenter des recherches AAAA et des connexions IPv6 en premier. Si IPv6 est partiellement activé (routes manquantes, pare‑feu bloquant), vous obtenez des timeouts. Diagnostiquez avec des tests nom d’hôte vs IP et des tests de résolveur.

8) Will disabling UseDNS break anything else?

Cela change principalement la façon dont sshd résout et journalise les noms clients. Si vous avez un traitement de logs qui attend des noms d’hôte, ajustez‑le. Opérationnellement, journaliser des IP est généralement suffisant.

9) My delay is after “session opened” in logs. Is this still DNS/GSSAPI?

Peu probable. Cela indique plutôt du travail de session PAM, des répertoires personnels réseau, ou l’initialisation du shell. Le correctif se trouve dans PAM, SSSD/LDAP, automount, ou les dotfiles utilisateur — pas dans UseDNS de sshd.

10) What’s the difference between fixing DNS and just disabling UseDNS?

Désactiver UseDNS empêche sshd d’attendre les recherches inverses. Corriger le DNS améliore tout l’environnement : enrichissement des logs, Kerberos, découverte de services, et tout autre système qui effectue des recherches. Faites les deux si possible.

Conclusion : quelles sont les prochaines étapes

Si les connexions SSH sur Debian 13 sont lentes, ne devinez pas. Localisez la pause avec ssh -vvv, confirmez le comportement DNS avec getent/dig, et vérifiez les réglages effectifs de sshd avec sshd -T. Ensuite, faites la chose pratique :

• Mettre UseDNS no sauf si vous avez une raison spécifique et testée de ne pas le faire.
• Mettre GSSAPIAuthentication no sauf si vous utilisez Kerberos SSH SSO et pouvez prouver que c’est sain.
• Recharger sshd en sécurité (valider la config, reload pas restart).
• Corriger le DNS correctement ensuite : zones inverses pour les sous‑réseaux clients, résolveurs joignables, et moins de search domains « créatifs ».

Votre récompense est immédiate : SSH cesse de donner l’impression de réfléchir profondément à votre requête, et redevient un outil efficace.