Debian 13 : SSH lent à la connexion — DNS et GSSAPI qui accélèrent instantanément (cas n°5)

Playbook de diagnostic rapide

Si vous n’avez que cinq minutes (et vous en avez), n’« optimisez » pas SSH. Identifiez la pause. Puis corrigez le seul réglage qui correspond à la pause.

Première étape : chronométrez la connexion depuis le client (trouver la phase)

Exécutez SSH avec une verbosité maximale et regardez où ça se fige. Si ça bloque après « Authentications that can continue » ou autour des lignes GSSAPI, c’est une piste. Si ça bloque après l’authentification, avant le shell, ce sont souvent des recherches DNS ou des modules PAM de service de noms.

Deuxième étape : examinez les logs du serveur pendant la pause

Dans un autre terminal, taillez le journal du serveur pour sshd. Si vous voyez « reverse mapping checking getaddrinfo… » ou de longs blancs entre les lignes de log, c’est du DNS. Si vous voyez « GSSAPI » et des tentatives répétées, c’est la négociation Kerberos/GSSAPI.

Troisième étape : prouvez que le DNS est lent (forward + reverse)

Depuis le serveur, résolvez l’IP cliente en PTR, puis résolvez ce nom d’hôte en retour. Si l’une des requêtes prend des secondes ou expire, vous avez trouvé la source du délai.

Quatrième étape : appliquez le correctif minimal et sûr

• Pour les blocages dus aux recherches DNS inverses : définissez UseDNS no dans /etc/ssh/sshd_config (ou via un drop-in) et redémarrez sshd.
• Pour les blocages GSSAPI : définissez GSSAPIAuthentication no (côté client et/ou serveur) si Kerberos n’est pas requis.

Cinquième étape : retestez et revenez en arrière si vous avez modifié la mauvaise chose

La lenteur SSH est généralement déterministe. Si vous corrigez la bonne cause, ça devient instantanément rapide. Si ça devient « lent différemment », vous dépannez maintenant autre chose (PAM, LDAP, montages de répertoires home, scripts de profil du shell).

Ce que signifie « SSH lent »

Quand les gens disent « SSH est lent », ils veulent généralement dire l’un des quatre délais :

1. La connexion TCP est lente : impossible d’établir rapidement une connexion. C’est le routage, le pare-feu, des drops de SYN, ou la sélection de version IP.
2. L’échange de clés est lent : la négociation crypto bloque. Rare sur du matériel moderne à moins que l’entropie soit défaillante ou que le réseau altère les paquets.
3. L’authentification est lente : le serveur met des lustres à vérifier votre clé/mot de passe. Souvent PAM + LDAP/SSSD, ou GSSAPI.
4. Post-auth est lent : l’authentification réussit, puis vous attendez avant d’obtenir un shell. Fréquemment des recherches DNS inverses, des modules de session PAM, des automounts, ou des scripts d’initialisation du shell.

Cet article concerne les cas où la connexion est rapide, l’échange de clés est rapide, mais vous restez à attendre — habituellement parce que le serveur essaie poliment de connaître votre nom (DNS) ou votre identité d’entreprise (Kerberos), et attend qu’une infrastructure tierce réponde.

Un principe à garder : ne devinez pas. SSH vous donne assez d’observabilité pour identifier la pause exacte avec des horodatages et des logs. Servez-vous en.

L’ingénieur fiabilité John Allspaw a une idée paraphrasée que j’aime : « Les opérations réussissent quand vous comprenez le système que vous avez réellement, pas celui que vous imaginiez. » C’est tout le problème résumé en une phrase.

Faits et contexte intéressants (pourquoi ça revient)

• OpenSSH a ajouté le support GSSAPI il y a des décennies pour s’intégrer aux réseaux d’entreprise centrés sur Kerberos où « sans mot de passe » signifie billets, pas clés.
• Les vérifications DNS inverses dans sshd sont antérieures à la plupart des réseaux cloud ; elles avaient du sens quand la confiance basée sur l’hôte et la journalisation par nom d’hôte étaient courantes.
• Les timeout DNS sont souvent « lents par conception » : les résolveurs essaient plusieurs serveurs, d’abord en UDP puis TCP, à travers des domaines de recherche, avec backoff.
• Un enregistrement PTR manquant peut être pire qu’un PTR incorrect : les mauvaises réponses sont rapides ; les expirations sont lentes.
• nsswitch contrôle bien plus que ce que l’on pense : si hosts: inclut mdns, nis, ou un ordre de fichiers mal choisi, une « simple recherche » devient une tournée des regrets réseau.
• systemd-resolved a changé la surface de débogage : vous parlez souvent à un résolveur local stub, qui parle ensuite à des résolveurs en amont avec son propre cache et ses comportements de défaillance.
• Les paramètres par défaut du client SSH peuvent déclencher du travail côté serveur : un client proposant GSSAPI peut amener le serveur à tenter cette méthode, même si elle échouera toujours.
• IPv6 peut ajouter des secondes de délai sans rien casser : les recherches AAAA, des résolveurs v6 injoignables, ou des routes v6 cassées peuvent créer des pauses mystérieuses.

Deux conclusions : (1) la plupart des « problèmes de performance » SSH sont en réalité des problèmes de performance du service de noms, et (2) le bon correctif est généralement une modification d’une seule ligne, une fois que vous avez prouvé la cause.

Tâches pratiques : commandes, sorties, décisions

Ce ne sont pas des commandes de labo. Ce sont celles que vous exécutez un mardi à 02:10 tandis que quelqu’un demande « prod fonctionne ? » Chaque tâche inclut ce que signifie la sortie et la décision à prendre.

Tâche 1 : Mesurez où le client se fige (SSH verbeux)

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:~$

Sens : la crypto et l’authentification sont rapides ; la pause survient après « Entering interactive session ». Cela pointe vers les étapes post-auth : DNS inverse, modules PAM de session, automounts, ou initialisation du shell. DNS est un suspect principal.

Décision : Vérifiez les logs du serveur et la résolution DNS depuis le serveur ensuite.

Tâche 2 : Taillez les logs sshd en reproduisant le problème

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

Sens : Il y a un écart de six secondes entre l’ouverture de session et la ligne de log suivante. C’est la fenêtre de blocage.

Décision : Vérifiez si sshd effectue des recherches DNS ou des tentatives GSSAPI, et testez la latence de résolution de noms.

Tâche 3 : Identifiez l’IP cliente dans les logs, puis testez la recherche inverse sur le serveur

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

Sens : La recherche inverse expire. sshd peut attendre cela durant la connexion si UseDNS est activé ou si d’autres composants font des requêtes.

Décision : Réparez la reachabilité du résolveur ou désactivez l’usage du DNS inverse dans sshd (selon la politique). Poursuivez l’analyse : le DNS est-il cassé sur le serveur ou juste pour ce sous-réseau ?

Tâche 4 : Vérifiez quel résolveur le serveur utilise (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

Sens : Le serveur dépend de 10.20.0.53/54. Si ceux-ci sont injoignables depuis cet hôte/VRF, les requêtes DNS vont se bloquer.

Décision : Vérifiez la reachabilité des résolveurs et considérez le comportement de cache local et les timeouts.

Tâche 5 : Confirmez la reachabilité des serveurs DNS (ne supposez rien)

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

Sens : Votre résolveur est mort pour cet hôte. Ce n’est pas un problème SSH ; c’est un problème de dépendance.

Décision : Réparez le routage/pare-feu vers le DNS, ou pointez temporairement cet hôte vers un résolveur accessible ; puis réexaminez la politique UseDNS de sshd.

Tâche 6 : Vérifiez si sshd est configuré pour utiliser le DNS inverse

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

Sens : sshd effectue explicitement des vérifications DNS inverses et tentera aussi l’authentification GSSAPI.

Décision : Si vous n’avez pas besoin d’une journalisation par nom d’hôte ou d’une authentification basée sur l’hôte, définissez UseDNS no. Si vous n’utilisez pas Kerberos pour SSH, désactivez GSSAPI. Mais validez d’abord lequel provoque votre pause.

Tâche 7 : Chronométrez les recherches DNS directes et inverses (preuve rapide)

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

Sens : Un chemin de résolution basique prend ~6 secondes, ce qui correspond au blocage lors de la connexion. C’est votre crater fumant.

Décision : Soit réparez la reachabilité/les enregistrements DNS, soit dites à sshd de ne pas se bloquer sur cette recherche.

Tâche 8 : Vérifiez 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

Sens : Le PTR pointe vers un nom d’hôte qui ne résout pas vers la même IP. Ce décalage peut provoquer des recherches supplémentaires et de la confusion dans les logs, et certains systèmes le traitent comme suspect.

Décision : Corrigez le PTR ou l’enregistrement A si vous dépendez du DNS inverse pour la journalisation/audit. Si vous n’en avez pas besoin, désactivez UseDNS et cessez de payer cette taxe.

Tâche 9 : Désactivez UseDNS en toute sécurité en utilisant un fichier 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

Sens : La syntaxe de configuration est valide, le service a redémarré proprement.

Décision : Retestez la connexion SSH. Si elle devient instantanée, vous avez isolé le problème sur les recherches DNS inverses pendant la connexion.

Tâche 10 : Confirmez l’amélioration depuis le client

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:~$

Sens : La pause a disparu. Bien. Continuez quand même : le DNS est toujours cassé, vous avez juste empêché SSH d’attendre dessus.

Décision : Créez un ticket pour la reachabilité des résolveurs/hygiène des PTR. Vous ne voulez pas que d’autres services se bloquent.

Tâche 11 : Détectez les délais de négociation GSSAPI depuis le client

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).

Sens : Le client tente d’abord GSSAPI, échoue, et perd du temps avec cette tentative. Même si publickey est rapide, vous payez la pénalité de tentative GSSAPI.

Décision : Désactivez GSSAPI côté client pour cet hôte (préféré) ou côté serveur si votre environnement n’utilise pas Kerberos pour SSH.

Tâche 12 : Désactivez GSSAPI sur le client (par hôte) sans changer le serveur

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).

Sens : Aucune tentative GSSAPI ; le chemin d’authentification est plus court.

Décision : Si cela corrige systématiquement le délai pour les utilisateurs, envisagez une politique côté serveur — après avoir confirmé que personne ne dépend de Kerberos SSH.

Tâche 13 : Désactivez GSSAPI côté serveur (uniquement si vous n’utilisez pas 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

Sens : Le serveur n’offrira plus GSSAPI. Cela peut réduire sensiblement le « churn » des premières méthodes d’authentification.

Décision : Déployez ceci seulement après avoir vérifié que votre parc n’utilise pas Kerberos pour SSO SSH.

Tâche 14 : Vérifiez l’ordre de recherche des hôtes (nsswitch) quand « DNS fonctionne mais getent est lent »

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

Sens : mDNS est interrogé avant DNS. En environnement serveur, mDNS est généralement superflu et peut introduire des délais, surtout avec des configurations réseau étranges.

Décision : Envisagez de simplifier la résolution des hôtes sur les serveurs (souvent files dns), mais coordonnez-vous avec ce qui a installé mdns initialement.

Tâche 15 : Prouvez si systemd-resolved est le goulot (cache vs amont)

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

Sens : resolved ne peut pas atteindre le DNS configuré pour cette requête. Ce n’est pas une « requête lente », c’est un « pas de route vers le DNS », qui se manifeste souvent par des timeouts ailleurs.

Décision : Réparez le réseau vers le DNS ou ajustez les serveurs DNS pour cette interface/VLAN.

Tâche 16 : Confirmez que la pause ne vient pas de PAM/SSSD/LDAP (leurre courant)

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

Sens : Rien d’évident ici, mais le point est : vérifiez si des modules PAM effectuent des appels externes. (Sur beaucoup de systèmes, inspectez /etc/pam.d/sshd et les logs SSSD.)

Décision : Si la désactivation de UseDNS et GSSAPI ne règle rien, pivotez vers PAM/session et les services d’annuaire.

Retards de recherche DNS inverses : le classique « pourquoi SSH est poli »

Le DNS inverse est la raison n°1 pour laquelle SSH « fonctionne mais semble lent ». sshd reçoit une IP cliente et — selon la configuration — essaie de la résoudre en nom d’hôte, puis parfois vérifie que ce nom résout de nouveau vers la même IP. Si le DNS est lent ou cassé, sshd attend.

Voici la vérité qui fâche : dans beaucoup d’environnements, le DNS inverse n’est pas maintenu avec la même rigueur que le DNS direct. Les gens ajoutent des enregistrements A/AAAA parce que sinon les choses ne fonctionnent pas. Les PTR sont considérés comme « agréables à avoir » jusqu’à ce que quelque chose en dépende et bloque. sshd est une de ces choses.

Ce que fait réellement UseDNS (et ce qu’il ne fait pas)

UseDNS contrôle si sshd utilise le DNS pour mapper l’IP distante en un nom d’hôte pour la journalisation et les décisions de contrôle d’accès impliquant des noms d’hôtes. Si vous le désactivez, sshd journalisera et opérera typiquement en se basant sur l’adresse IP au lieu d’attendre la résolution inverse.

Désactiver UseDNS n’empêche pas tout de faire des recherches DNS. Les modules PAM, les outils d’audit et votre invite de shell peuvent encore résoudre des noms. Mais cela supprime un délai synchrone courant juste dans le chemin de connexion.

Pourquoi cela empire dans les réseaux modernes

Le cloud et les réseaux d’entreprise adorent l’indirection : overlays, DNS à horizon partagé, multiples résolveurs par interface, et appliances de sécurité qui interceptent le DNS. Chaque couche ajoute des modes de défaillance qui ressemblent à « c’est seulement lent parfois ». SSH rend ces modes de défaillance douloureusement visibles parce qu’il est interactif et que vous remarquez chaque seconde.

Et oui, IPv6 mérite une mention spéciale. Les mauvaises configurations dual-stack provoquent souvent « tentative v6 d’abord, échec lent, puis réussite v4 ». Parfois vous ne le verrez même pas dans les logs sauf si vous regardez.

Stratégie de correction : décidez si vous avez besoin du DNS inverse dans sshd

Posez-vous la question adulte : avez-vous réellement besoin des recherches DNS inverses durant la connexion SSH ?

• Si vous utilisez des règles d’accès basées sur l’hôte avec des noms dans AllowUsers/DenyUsers ou des blocs Match, le DNS inverse peut être important. En pratique, c’est rare et souvent fragile.
• Si vous comptez sur la journalisation par nom pour la réponse aux incidents, vous pourriez penser en avoir besoin. Mais les adresses IP sont généralement plus fiables que les PTR dans des réseaux désordonnés. Vous pouvez toujours faire des recherches inverses hors ligne quand le DNS est sain.
• Si vous n’avez pas une gestion rigoureuse des PTR, activer UseDNS est une taxe que vous payez indéfiniment.

Mon biais : sur les serveurs, désactivez UseDNS sauf si vous avez une raison spécifique et testée de ne pas le faire. Raccourcissez la chaîne de dépendances.

Blague n°1 : Le DNS, c’est comme la politique de bureau — quand il est sain, vous ne le remarquez pas ; quand il est cassé, tout devient une réunion.

Et si vous devez garder UseDNS activé ?

Dans ce cas, traitez les enregistrements PTR comme des données de production. Maintenez-les. Surveillez-les. Testez-les depuis les sous-réseaux serveur qui comptent. Et assurez-vous que les serveurs peuvent joindre leurs résolveurs rapidement et de façon cohérente.

Également : définissez des timeouts de résolveur réalistes. Certains environnements tolèrent de longs timeouts DNS « parce que ça finit par marcher ». Les connexions interactives n’ont pas cette patience.

GSSAPI/Kerberos : la taxe d’entreprise que vous n’êtes peut‑être pas obligé de payer

GSSAPI dans SSH existe pour que vous puissiez vous authentifier avec des tickets Kerberos. Dans le bon environnement, c’est excellent : single sign-on, politique centralisée, moins d’éparpillement de clés SSH. Dans le mauvais environnement, c’est un pré-vol de vérification lent qui s’exécute à chaque connexion.

Quand GSSAPI est activé, un client et un serveur peuvent tenter une ou plusieurs échanges Kerberos avant de retomber sur la clé publique ou le mot de passe. Si le client n’a pas de tickets, si le KDC est injoignable, si le DNS SRV pour les KDC est cassé, ou si la synchronisation temporelle est fausse, vous pouvez obtenir des secondes de délai par tentative.

Comment reconnaître la lenteur GSSAPI

La sortie verbeuse du client le montre généralement clairement : il essaie gssapi-with-mic, échoue avec « No Kerberos credentials » ou similaire, puis n’offre la clé qu’après. Parfois il réessaye. Parfois il attend des recherches DNS SRV pour les KDC. Parfois il attend des timeouts réseau vers le KDC.

Contrairement à UseDNS, la lenteur GSSAPI est souvent visible dans la phase d’authentification, avant « Entering interactive session ». C’est ainsi que vous les distinguez rapidement.

Stratégie de correction : désactivez quand c’est approprié, ne cassez pas SSO

Il existe deux schémas sûrs :

1. Désactivation côté client par hôte (~/.ssh/config) pour les hôtes où Kerberos n’est pas utilisé. Cela évite de casser d’autres hôtes où Kerberos SSH est souhaité.
2. Désactivation côté serveur quand vous êtes certain que l’environnement n’utilise pas Kerberos pour SSH du tout. Cela empêche les clients de tenter la méthode.

Faites attention aux changements globaux dans des environnements d’entreprise partagés. Quelqu’un, quelque part, utilise probablement cette fonctionnalité que vous avez oubliée. C’est souvent un directeur avec un agenda chargé.

Blague n°2 : Kerberos est merveilleux jusqu’à ce qu’il ne le soit plus, moment où il devient un système distribué avec des sentiments.

Nettoyage GSSAPI et transfert de credentials

Des options comme GSSAPICleanupCredentials et le forwarding de credentials côté client peuvent compter pour la sécurité et l’expérience utilisateur, mais elles ne sont généralement pas la cause principale d’un « login lent ». Si votre délai survient durant l’authentification et que GSSAPI est activé, commencez par déterminer si ça échoue avec timeout ou si ça réussit rapidement.

Si vous utilisez Kerberos, traitez le chemin KDC comme une dépendance : DNS, synchronisation temporelle, règles de pare-feu et configuration de royaume doivent être ennuyeusement corrects. SSH n’est que le messager.

Trois mini‑histoires d’entreprise du terrain

1) L’incident causé par une fausse hypothèse : « le DNS est toujours là »

Une entreprise de taille moyenne a migré un lot d’hôtes Debian dans un segment réseau « restreint ». Le segment avait des règles d’egress strictes : seuls les ports applicatifs, pas « l’infra aléatoire ». Quelqu’un a supposé que le DNS serait pris en charge « par la plateforme », parce que ça avait toujours été le cas dans d’autres segments. Les hôtes sont arrivés avec des résolveurs pointant vers le DNS corporate, mais le pare-feu n’autorisait pas le port 53 depuis ce VLAN vers ces IPs.

Tout avait l’air correct dans les tableaux de bord. CPU inactif. Services en marche. Mais les ingénieurs ont remarqué des connexions SSH prenant 5–15 secondes. Ils ont attribué ça à une « lenteur VPN », jusqu’à ce qu’un on-call essaie de déboguer un incident prod et passe l’intégralité de l’incident à attendre des shells.

Le vrai dommage n’était pas le délai lui-même ; c’était le comportement qu’il a provoqué. Les gens ouvraient plus de sessions « parce que la première gelait ». Les bastions ont été surchargés. Le suivi des connexions SSH a augmenté. La réponse à l’incident a paru chaotique parce que les outils étaient lents.

La correction a été douloureusement simple : autoriser l’egress DNS vers les résolveurs ou placer un résolveur dans le segment. Désactiver UseDNS a rendu SSH instantané immédiatement, mais l’équipe a dû quand même réparer le DNS parce que d’autres composants (installations de paquets, validation TLS, découverte de services) étaient aussi sur une corde raide. La leçon n’était pas « désactivez UseDNS ». La leçon était « validez les dépendances depuis le réseau où vit réellement le serveur ».

2) L’optimisation qui a mal tourné : « Rendons le DNS plus sûr »

Une équipe sécurité a déployé une nouvelle politique DNS : tous les hôtes devaient utiliser une paire de résolveurs « sécurisés » qui filtraient et loguaient. Ils ont poussé le changement via la gestion de configuration. Les résolveurs fonctionnaient — jusqu’à ce qu’ils ne fonctionnent plus. Dans certains modes de défaillance, la couche de filtrage acceptait les paquets mais retardait les réponses en tentant une validation en amont.

SSH est devenu le canari. Les ingénieurs ont signalé que la connexion aux hôtes prod prenait parfois dix secondes, mais seulement pendant les heures de bureau. La réaction immédiate a été de blâmer la crypto : « Peut-être que la nouvelle build OpenSSH est plus lente. » Quelqu’un a suggéré de changer les chiffrements. Quelqu’un d’autre a suggéré de désactiver la compression. Rien n’a aidé, parce que la crypto n’était pas le problème.

Un SRE prudent a comparé les timings verbeux SSH aux temps de requête DNS et a constaté que les recherches inverses se bloquaient exactement quand les résolveurs sécurisés étaient sous charge. Pire, la charge corrélait avec des fenêtres de scans de sécurité qui généraient un flux de domaines inconnus — exactement ce que le service de filtrage devait analyser. Le système faisait son travail ; il le faisait juste de façon synchrone pour des connexions interactives.

La correction finale a été double : (1) désactiver UseDNS à l’échelle des serveurs, et (2) ajuster le chemin du résolveur sécurisé pour que les timeouts échouent rapidement et que les caches soient dimensionnés correctement. La sécurité a gardé ses logs. SRE a retrouvé ses shells. Le retour de bâton n’était pas « la sécurité est mauvaise ». C’était « les systèmes interactifs ne peuvent pas attendre votre pipeline de conformité ».

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : configurations SSH par étapes

Une autre entreprise gérait un grand parc Debian avec un contrôle de changement strict, ce qui semble pénible jusqu’à ce que ça vous sauve. Ils avaient une norme : tout changement sshd devait être (a) appliqué via des drop-ins, (b) validé avec sshd -t, et (c) déployé d’abord sur un petit canari avant d’être étendu.

Quand un nouvel environnement a commencé à signaler des SSH lents, l’équipe n’a pas immédiatement « réparé SSH ». Ils ont collecté des preuves : logs client avec -vvv, blancs dans le journal serveur, et timings DNS depuis getent. Ils ont confirmé que les recherches DNS inverses prenaient plusieurs secondes à cause de PTR manquants pour un nouveau pool d’adresses VPN.

La pratique ennuyeuse a été qu’ils avaient déjà un drop-in approuvé pour les hôtes sensibles à la performance : /etc/ssh/sshd_config.d/10-fast-login.conf avec UseDNS no. Il avait été revu, testé et documenté. Ils l’ont déployé d’abord sur le segment impacté, vérifié l’amélioration, puis ouvert le travail DNS PTR en parallèle.

Rien de dramatique ne s’est produit. Personne n’a reçu deux pages. C’est ce que « sauver la mise » ressemble en opérations réelles : moins de surprises, moins d’exploits de dernière minute, plus de systèmes qui se comportent comme prévu.

Erreurs courantes : symptômes → cause → correctif

C’est la section que vous voulez quand vous êtes fatigué et légèrement en colère contre les ordinateurs.

1) Symptom : longue pause après « Authentication succeeded »

Cause : recherche DNS inverse pendant la configuration de session (UseDNS yes) qui expire ou résolveur lent.

Fix : mettre UseDNS no dans sshd ; aussi réparer la reachabilité des résolveurs et l’hygiène des PTR.

2) Symptom : longue pause avant que la clé soit proposée ; verbeux montre des tentatives « gssapi-with-mic »

Cause : GSSAPI activé ; le client tente Kerberos en premier et attend KDC/DNS/timeouts.

Fix : désactiver GSSAPIAuthentication côté client par hôte ou côté serveur si Kerberos SSH n’est pas utilisé.

3) Symptom : rapide sur le LAN, lent via VPN

Cause : le pool d’adresses VPN n’a pas de PTR, ou les clients VPN résolvent via un chemin DNS différent ; les recherches inverses expirent.

Fix : ajouter des PTR pour le pool VPN ou désactiver UseDNS ; vérifier la reachabilité DNS depuis le serveur vers les résolveurs responsables de cette zone inverse.

4) Symptom : seulement certains serveurs sont lents, d’autres non

Cause : ACLs DNS par sous-réseau, résolveurs différents par interface, ou zones split-horizon manquantes sur une vue.

Fix : comparer resolvectl status et la reachabilité des résolveurs entre hôtes ; aligner la configuration DNS par segment réseau.

5) Symptom : SSH lent uniquement pour certains noms d’utilisateur

Cause : modules PAM appelant LDAP/SSSD/automount pour ces utilisateurs ; pas principalement DNS/GSSAPI.

Fix : inspecter /etc/pam.d/sshd, les logs SSSD, et le comportement de montage des répertoires home ; tester avec un utilisateur local.

6) Symptom : « ssh est lent » mais ssh -vvv montre un délai avant « Connection established »

Cause : latence du chemin réseau, limites de taux SYN du pare-feu, ou résolution du nom de la cible (DNS côté client), pas les étapes de login côté serveur.

Fix : SSH vers l’IP directement, tester avec nc -vz, et vérifier DNS côté client vs côté serveur.

7) Symptom : SSH lent après la connexion (l’invite apparaît puis les commandes sont lentes)

Cause : scripts d’initialisation du shell effectuant des appels réseau (invite git, contexte kubectl, requêtes LDAP), ou répertoires home réseau.

Fix : profilez le chemin d’initialisation du shell ; testez temporairement avec ssh user@host /bin/bash --noprofile --norc.

8) Symptom : désactiver UseDNS a aidé, mais les logs sont maintenant « moins jolis »

Cause : vous dépendiez auparavant des noms d’hôte dérivés des PTR.

Fix : mettez à jour la journalisation/alerting pour vous baser sur l’IP ; faites des recherches inverses asynchrones dans les pipelines de logs si nécessaire.

Checklists / plan étape par étape

Plan A : vous avez besoin que SSH soit rapide maintenant (sûr et réversible)

1. Depuis votre client, capturez ssh -vvv et notez où ça se bloque (auth vs post-auth).
2. Sur le serveur, taillez journalctl -u ssh -f pendant que vous reproduisez la connexion.
3. Sur le serveur, exécutez sshd -T | grep usedns et sshd -T | grep gssapiauthentication.
4. Si la pause est post-auth et que le DNS est suspect : définissez UseDNS no via /etc/ssh/sshd_config.d/.
5. Si la pause est durant l’auth et que GSSAPI apparaît dans la sortie verbeuse : désactivez GSSAPI par hôte dans ~/.ssh/config.
6. Validez la config : sshd -t.
7. Redémarrez SSH : systemctl restart ssh.
8. Retestez depuis le même réseau client qui était lent (LAN vs VPN importe).
9. Si corrigé, ouvrez un ticket pour l’infrastructure DNS/Kerberos afin que le prochain service n’accroche pas.

Plan B : vous devez garder le DNS inverse et/ou Kerberos (faites‑le proprement)

1. Assurez-vous que le serveur peut joindre ses résolveurs de manière fiable (ICMP n’est pas suffisant ; testez UDP/TCP 53 via des outils de politique si disponibles).
2. Assurez-vous que des enregistrements PTR existent pour tous les sous-réseaux clients (bureau, VPN, bastions, runners CI).
3. Assurez la forward-confirmed reverse DNS pour les sous-réseaux critiques (PTR pointe vers un nom ; le nom pointe vers la même IP).
4. Pour GSSAPI : vérifiez la reachabilité du KDC, la configuration du royaume et la synchronisation temporelle ; un NTP cassé ruinera votre journée silencieusement.
5. Gardez des timeouts/essais raisonnables dans la chaîne de résolveurs pour que les connexions interactives échouent rapidement quand les dépendances sont down.
6. Mettez des mesures en place : stockez des métriques « temps de connexion SSH » depuis des réseaux représentatifs.

Plan C : gardez les changements minimes et auditables

1. Utilisez des drop-ins sous /etc/ssh/sshd_config.d/ plutôt que d’éditer le fichier principal.
2. Une modification par fichier (plus facile à rollback).
3. Exécutez toujours sshd -t avant de redémarrer.
4. Gardez une session console ouverte pendant le redémarrage si vous êtes à distance, pour ne pas vous verrouiller hors du système.

FAQ

1) Dois‑je toujours mettre UseDNS no sur les serveurs Debian 13 ?

Presque toujours, oui. À moins d’avoir une dépendance spécifique et testée à des décisions basées sur le DNS inverse dans sshd. La plupart des environnements n’en ont pas besoin, et le coût est réel quand le DNS est instable.

2) Désactiver UseDNS réduit‑t‑il la sécurité ?

Ça supprime une classe de vérifications basées sur le nom d’hôte, mais ces contrôles sont généralement plus faibles que les contrôles basés sur l’IP et les clés. N’utilisez pas les PTR comme signal d’authentification. Préférez les clés, MFA, ACL réseau et allowlists explicites.

3) Pourquoi SSH fait‑il des recherches DNS inverses du tout ?

Par habitude et commodité pour la journalisation. Les anciens schémas opérationnels faisaient confiance aux noms d’hôte et les utilisaient dans les contrôles d’accès. Aujourd’hui, les réseaux évoluent plus vite que les PTR. Les IPs sont souvent l’identifiant le plus honnête.

4) Si je désactive GSSAPI, vais‑je casser les connexions de domaine ?

Pas nécessairement. Les utilisateurs de domaine peuvent toujours s’authentifier via clés publiques ou mots de passe selon votre configuration PAM. Mais vous couperez le SSO Kerberos pour SSH si quelqu’un l’utilise. C’est pourquoi la désactivation côté client par hôte est le point de départ le plus sûr.

5) SSH est lent uniquement à la première connexion, puis c’est rapide. Pourquoi ?

Le cache DNS (côté client, côté serveur ou dans systemd-resolved) peut rendre les recherches suivantes rapides. C’est un indice que la résolution de noms est en cause. Chronométrez avec getent hosts et comparez comportement cold vs warm cache.

6) J’ai mis UseDNS no, mais c’est encore lent après l’auth. Et après ?

Pivotez vers PAM/session et l’environnement utilisateur : latence LDAP/SSSD, automounts de home, scripts d’initialisation du shell lents, ou problèmes de systèmes de fichiers réseau. Testez un utilisateur local avec un shell minimal pour isoler.

7) IPv6 peut‑il provoquer des connexions SSH lentes même si IPv4 fonctionne ?

Oui. Les problèmes de résolution et de reachabilité dual‑stack peuvent ajouter des délais dans le DNS et dans l’accès aux services d’identité. Cherchez des motifs « v6 d’abord puis fallback » dans les logs verbeux et le statut des résolveurs.

8) Dois‑je « corriger » en changeant les chiffrements ou les KEX ?

Non, pas pour ce symptôme. Si votre blocage dure des secondes et intervient après l’auth ou pendant GSSAPI, l’optimisation crypto est du cargo cult. Mesurez d’abord ; corrigez la dépendance réellement lente.

9) Est‑ce spécifique à Debian 13 ?

Le comportement est commun à OpenSSH sur beaucoup de distributions Linux. Debian 13 signifie juste que vous avez probablement OpenSSH moderne et systemd-resolved, ce qui change l’endroit où regarder les problèmes DNS.

10) Quel est le plus petit changement qui apporte le plus de bénéfice ?

UseDNS no est souvent le correctif immédiat « amélioration instantanée » pour les blocages post-auth. Pour les blocages pendant l’auth, désactiver GSSAPI côté client pour cet hôte est le plus petit et le plus sûr.

Conclusion : prochaines étapes durables

Si les connexions SSH sur Debian 13 semblent lentes, traitez cela comme toute autre latence en production : identifiez la phase, prouvez la dépendance, appliquez le plus petit correctif, puis réparez l’infrastructure sous‑jacente pour que le prochain service n’hérite pas de la douleur.

Faites ceci ensuite :

1. Capturez une session ssh -vvv montrant la pause et sauvegardez‑la avec l’horodatage et le réseau client (LAN/VPN/bastion).
2. Sur le serveur, mesurez time getent hosts <client-ip>. Si ça correspond à la pause, vous avez fini le diagnostic.
3. Définissez UseDNS no via un drop-in, validez avec sshd -t, redémarrez, retestez.
4. Si la sortie verbeuse montre du churn GSSAPI, désactivez‑le par hôte côté client d’abord ; ne le désactivez côté serveur que lorsque vous êtes certain que Kerberos SSH n’est pas utilisé.
5. Ouvrez le vrai correctif : reachabilité des résolveurs, hygiène des PTR, et (si pertinent) fiabilité des KDC. SSH n’a fait qu’exposer la vérité.

L’état final souhaité est ennuyeux : SSH se connecte instantanément, le DNS fonctionne de façon fiable, Kerberos marche quand vous l’utilisez réellement, et personne n’a à apprendre à la dure que « l’infrastructure » est une dépendance, pas une suggestion.