Ubuntu 24.04 : Hostname/hosts mismatch casse sudo/ssh — la correction ennuyeuse qui fait gagner des heures

Ce qui casse réellement (et pourquoi ça ressemble au DNS)

L’essentiel : sudo et sshd ne « font pas du DNS » par ennui. Ils appellent des fonctions de la bibliothèque système
qui résolvent souvent des noms d’hôte dans le cadre du logging, des contrôles de politique et des mécanismes de sécurité. Quand le hostname de votre machine ne se résout pas
rapidement en une adresse (ou ne se résout pas du tout), vous payez ce retard en timeouts.

Sur Ubuntu, la résolution de nom est régie par Name Service Switch (NSS), configuré dans /etc/nsswitch.conf.
La plupart des valeurs par défaut consultent files (c’est-à-dire /etc/hosts) avant DNS. C’est bien : cela rend les recherches locales rapides et prévisibles.
Mais si /etc/hosts ne contient pas votre hostname actuel, ou s’il contient le mauvais, la résolution tombe sur le DNS.
Dans un réseau de laboratoire à DNS capricieux — ou dans un VPC cloud où la résolution inverse est lente — vous obtenez ce comportement bloquant.

Le message d’erreur classique est :
sudo: unable to resolve host somehost: Name or service not known
Mais vous ne le verrez pas toujours, car selon votre terminal, la configuration de logging et le chemin d’appel exact, cela peut juste donner l’impression que « sudo est lent ».

La raison pour laquelle SSH est touché : le serveur fait souvent une résolution DNS inverse pour l’IP du client, et votre hôte peut aussi faire des recherches directes.
Si UseDNS yes est activé (ou si les valeurs par défaut diffèrent selon les builds), le serveur peut passer du temps à attendre le DNS. Ajoutez une discordance locale du hostname
et vous pouvez cumuler les retards — invites d’authentification lentes, mise en place de session lente, logs lents.

Ce n’est pas une panne glamour. C’est du sable dans les engrenages. Ce sont ces pannes qui vous volent tout un après-midi.

Une citation utile en opérabilité : Espérer n’est pas une stratégie. (idée paraphrasée souvent attribuée aux cadres en fiabilité)
La correction ennuyeuse est la stratégie. Faites la correction ennuyeuse.

Blague n°1 : le DNS est le seul système où « c’est probablement juste une ligne » est à la fois vrai et capable de gâcher votre journée.

Faits intéressants et contexte historique (ce qui explique la bizarrerie)

• /etc/hosts existe avant la généralisation du DNS. Les fichiers hôtes locaux étaient le service d’annuaire originel sur les systèmes de l’ère ARPANET. DNS est arrivé plus tard pour monter en charge.
• Le schéma « 127.0.1.1 » est une culture spécifique Debian/Ubuntu. Debian utilisait historiquement 127.0.1.1 pour mapper le hostname système sans lier ce nom à une adresse d’interface réseau spécifique.
• glibc NSS est modulaire par conception. La ligne hosts: dans /etc/nsswitch.conf contrôle non seulement DNS vs files, mais aussi mDNS et les hooks du résolveur systemd.
• Les délais de résolution inverse existent comme nuisance SSH depuis des décennies. Le serveur SSH peut faire des recherches PTR pour les IP clients ; si le DNS est lent, SSH semble « lent ».
• systemd a changé la gestion du « hostname ». Avec systemd, hostnamectl est la porte d’entrée, et le hostname est persisté dans /etc/hostname (et parfois influencé par cloud-init).
• Les images cloud adorent se renommer. cloud-init et les métadonnées du fournisseur peuvent définir des hostnames au démarrage, parfois sans mettre à jour /etc/hosts comme on s’y attendrait.
• sudo essaie d’être sûr, pas rapide. Il journalise, vérifie les politiques, et lance parfois des recherches de hostname pour l’audit et l’affichage. Le délai est une propriété émergente, pas une fonctionnalité.
• « localhost » n’est pas qu’une ambiance. 127.0.0.1 localhost (et IPv6 ::1) sont attendus par beaucoup de logiciels ; rompre ces mappings cause des chaos subtils.

Playbook de diagnostic rapide (vérifier dans cet ordre)

Quand sudo se fige ou que les connexions SSH s’enrayent, vous voulez du signal vite. Voici l’ordre qui minimise les allers-retours et maximise la clarté.

1) Confirmer que le symptôme est une latence de résolution de nom, pas CPU, disque ou entropie

Si le délai est de l’ordre de ~5s, ~10s, ~30s, ça sent le timeout. Les pics CPU et les blocages disque sont plus irréguliers.

2) Vérifier immédiatement hostname vs /etc/hosts

C’est la vérification de 30 secondes qui vous fait gagner trois heures. Si le hostname système n’apparaît pas sur une ligne loopback dans /etc/hosts, corrigez-le.

3) Valider l’ordre NSS et l’état de systemd-resolved

Si /etc/nsswitch.conf tente DNS avant files (ou a été modifié), vous pouvez provoquer de la latence même avec un fichier hosts correct.

4) Pour la lenteur SSH : vérifier le comportement DNS côté serveur

Si le serveur attend la résolution inverse des clients, vous pouvez le corriger via la configuration (UseDNS no) ou via des enregistrements PTR corrects.
Préférez le DNS réel dans des environnements d’entreprise stables ; préférez UseDNS no dans des environnements jetables.

5) Ensuite seulement, poursuivre DNS en amont, firewalls, split-horizon, clients VPN et métadonnées cloud

Ce sont des problèmes réels — mais ce sont les branches coûteuses de l’arbre de décisions. Gagnez le droit d’y aller.

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

Ce sont les vérifications exactes que je lance en astreinte. Chaque tâche contient : commande, sortie plausible, ce que ça signifie, et la décision qu’elle entraîne.
Exécutez-les en tant qu’utilisateur normal sauf indication contraire.

Task 1: Measure how bad the delay is (sudo)

cr0x@server:~$ time sudo -n true

real    0m12.184s
user    0m0.014s
sys     0m0.010s

Ce que ça signifie : sudo a mis 12 secondes pour faire essentiellement rien. Ce n’est presque jamais du « CPU ».
C’est du territoire classique de timeout de résolution.

Décision : Basculez vers les vérifications de résolution de hostname avant de toucher aux paquets, disques ou paramètres kernel.

Task 2: See the current hostname (and whether it looks like a cloud rename)

cr0x@server:~$ hostname
ip-10-24-3-17

Ce que ça signifie : Ce motif ressemble à un nom attribué par un provider. Il a peut-être été défini par cloud-init ou les métadonnées.

Décision : Vérifiez que /etc/hosts contient ce nom. Sinon, corrigez localement d’abord.

Task 3: Check the “official” hostname source via systemd

cr0x@server:~$ hostnamectl
 Static hostname: ip-10-24-3-17
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 3b9f6a0c6f2847b7a62c1234c77d9a1e
         Boot ID: 1bd3b7d21f7f48f1bdf7c7fcb43b17a2
  Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-41-generic
    Architecture: x86-64

Ce que ça signifie : Le hostname que le système pense avoir est ip-10-24-3-17. Ce sera le nom que les services tenteront de résoudre.

Décision : Assurez-vous que ce nom se résout rapidement via files (hosts), pas via DNS.

Task 4: Inspect /etc/hosts for the mismatch

cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ubuntu-template

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Ce que ça signifie : Le hostname est ip-10-24-3-17, mais /etc/hosts contient encore ubuntu-template.
Donc quand quelque chose tente de résoudre le hostname actuel, la résolution tombe sur DNS.

Décision : Mettez à jour la ligne 127.0.1.1 (ou ajoutez-en une) pour inclure le hostname courant et éventuellement le FQDN.

Task 5: Prove resolution is slow (getent is your friend)

cr0x@server:~$ time getent hosts "$(hostname)"
10.24.3.17      ip-10-24-3-17

real    0m10.008s
user    0m0.000s
sys     0m0.004s

Ce que ça signifie : Même une recherche simple prend 10 secondes. C’est un chemin NSS qui attend quelque chose (souvent le DNS).

Décision : Corrigez /etc/hosts pour que cette recherche devienne instantanée. Si elle reste lente, inspectez nsswitch.conf et le DNS.

Task 6: Check NSS order (the actual resolution policy)

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

Ce que ça signifie : Le système doit consulter files en premier. Bien. Donc une entrée correcte dans /etc/hosts court-circuitera le problème.

Décision : Si files n’est pas en premier, mettez-le en premier sauf si vous avez une raison très spécifique de ne pas le faire (et vous n’en avez probablement pas).

Task 7: See what sudo is waiting on (strace, fast and surgical)

cr0x@server:~$ sudo strace -f -tt -o /tmp/sudo.strace sudo -n true
sudo: unable to resolve host ip-10-24-3-17: Name or service not known

Ce que ça signifie : Vous avez obtenu l’erreur explicite. Le fichier de trace montrera des appels comme getaddrinfo() et le temps passé.

Décision : Arrêtez de deviner. Corrigez la résolution du hostname localement. Si la politique exige la cohérence DNS, corrigez le DNS ensuite — mais ne sautez pas la correspondance locale.

Task 8: Confirm what /etc/hostname contains (persistence across boots)

cr0x@server:~$ cat /etc/hostname
ip-10-24-3-17

Ce que ça signifie : Le hostname persistant correspond à hostnamectl. Bien. La discordance se trouve spécifiquement dans /etc/hosts.

Décision : Éditez /etc/hosts, pas /etc/hostname, sauf si vous voulez vraiment renommer la machine.

Task 9: Check systemd-resolved status (are you even using it?)

cr0x@server:~$ systemctl is-active systemd-resolved
active

Ce que ça signifie : Resolved est actif, donc la configuration DNS peut être gérée via /run/systemd/resolve et /etc/resolv.conf peut être un stub.

Décision : N’éditez pas /etc/resolv.conf à l’aveugle ; vérifiez d’abord ce vers quoi il pointe.

Task 10: Confirm whether /etc/resolv.conf is a stub symlink

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Oct 12 09:14 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Ce que ça signifie : Le DNS est médié par systemd-resolved. Votre « DNS est lent » peut venir de l’amont, mais la discordance de hostname peut toujours être corrigée localement.

Décision : Traitez le DNS comme une question séparée. D’abord, assurez-vous que le hostname local se résout sans DNS.

Task 11: Check the local hosts mapping quickly (what does localhost resolve to?)

cr0x@server:~$ getent hosts localhost
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback

Ce que ça signifie : Localhost est sain. Votre problème n’est pas « quelqu’un a supprimé localhost ». Bonne nouvelle.

Décision : Concentrez-vous sur le mapping de votre hostname réel, pas sur la reconstruction complète du fichier.

Task 12: Fix /etc/hosts (safely) and verify lookup speed

cr0x@server:~$ sudo cp -a /etc/hosts /etc/hosts.bak.$(date +%F-%H%M%S)
cr0x@server:~$ sudo sed -i 's/^127\.0\.1\.1\s\+.*/127.0.1.1 ip-10-24-3-17/' /etc/hosts
cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ip-10-24-3-17

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Ce que ça signifie : Vous avez remplacé le hostname obsolète du template par le vrai. Changement minimal, effet maximal.

Décision : Relancez les commandes lentes. Si elles sont maintenant instantanées, arrêtez. Ne « touchez pas au DNS » par superstition.

Task 13: Validate the fix with getent and sudo timing

cr0x@server:~$ time getent hosts "$(hostname)"
127.0.1.1       ip-10-24-3-17

real    0m0.003s
user    0m0.000s
sys     0m0.003s
cr0x@server:~$ time sudo -n true

real    0m0.118s
user    0m0.012s
sys     0m0.011s

Ce que ça signifie : La recherche est maintenant locale et instantanée ; sudo revient à des temps humains normaux.

Décision : Clôturez l’incident. Si SSH reste lent, traitez-le séparément avec la configuration DNS côté serveur.

Task 14: If SSH is slow, test from the server’s perspective (auth log timing)

cr0x@server:~$ sudo tail -n 20 /var/log/auth.log
Dec 30 10:22:11 server sshd[2194]: Connection from 10.24.3.50 port 51344 on 10.24.3.17 port 22 rdomain ""
Dec 30 10:22:21 server sshd[2194]: Accepted publickey for cr0x from 10.24.3.50 port 51344 ssh2: ED25519 SHA256:1q2w3e4r5t...
Dec 30 10:22:21 server sshd[2194]: pam_unix(sshd:session): session opened for user cr0x(uid=1000) by (uid=0)

Ce que ça signifie : Il y a un écart de 10 secondes entre la connexion et l’acceptation. Cela pointe souvent vers DNS ou GSSAPI.

Décision : Inspectez sshd_config pour UseDNS et GSSAPIAuthentication si votre environnement n’en a pas besoin.

Task 15: Check SSH daemon config for DNS-related slow paths

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

Ce que ça signifie : La résolution inverse est activée. Dans certains réseaux c’est acceptable ; dans d’autres c’est un blocage garanti.

Décision : Si vous ne vous reposez pas sur les PTR pour les logs ou le contrôle d’accès, mettez UseDNS no et redémarrez SSH.

Task 16: Apply UseDNS no (if appropriate) and confirm reload

cr0x@server:~$ sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)
cr0x@server:~$ echo 'UseDNS no' | sudo tee -a /etc/ssh/sshd_config
UseDNS no
cr0x@server:~$ sudo systemctl restart ssh
cr0x@server:~$ sudo systemctl is-active ssh
active

Ce que ça signifie : SSH a été redémarré avec le nouveau paramètre. Les nouvelles connexions ne devraient plus attendre la résolution inverse.

Décision : Si vous êtes en environnement corporate où la résolution inverse est imposée, corrigez les enregistrements PTR plutôt que de la désactiver.

Trois mini-récits d’entreprise tirés de la vraie vie

Mini-récit 1 : L’incident causé par une mauvaise supposition

Une équipe SaaS de taille moyenne a déployé Ubuntu 24.04 pour un ensemble de runners internes. Ces machines ne servaient pas le trafic client directement,
mais elles étaient le lubrifiant de la chaîne : jobs CI, signature d’artefacts, builds de conteneurs. Personne n’y a prêté attention jusqu’à ce que les déploiements commencent à expirer.

La supposition était simple et très humaine : « Si SSH marche, la machine est OK. » Les ingénieurs pouvaient se connecter finalement, donc l’histoire est devenue
« le réseau est lent aujourd’hui » puis « le VPN déconne » puis « peut-être que le nouveau kernel est bizarre. » Les gens adorent une cause à la mode.

Le détail fatal était que chaque commande privilégiée — installer des paquets, redémarrer des services, récupérer des logs en root — prenait 10–15 secondes.
Multipliez ça dans des étapes d’automatisation, le temps de job CI a explosé. Quelqu’un a finalement chronométré sudo -n true et a vu le pattern : délai cohérent, pas de pic CPU.

La correction a été une édition en deux lignes de /etc/hosts. L’image cloud avait été templatisée avec 127.0.1.1 ubuntu-template,
et cloud-init avait renommé l’hôte au démarrage sans mettre à jour cette ligne. Le système tombait systématiquement sur DNS chaque fois qu’il tentait de se résoudre.

La leçon n’était pas « soyez plus intelligents ». C’était « arrêtez de supposer que le symptôme indique la couche ». SSH étant « disponible » ne signifie pas que la résolution de nom
ne vous tue pas à l’intérieur des outils privilégiés.

Mini-récit 2 : L’optimisation qui a mal tourné

Une entreprise du secteur financier avait une « initiative de réduction de latence » qui incluait l’élagage des services au démarrage dans les images de base.
Quelqu’un a décidé que les entrées hosts locales étaient « legacy » et que tout devait être « DNS réel », parce que « nous avons le DNS ».
L’image dorée a reçu un /etc/hosts minimaliste avec juste localhost et le boilerplate IPv6.

En laboratoire, ça a marché. En production, l’équipe réseau avait un DNS split-horizon avec des vues différentes selon les segments,
et certains segments n’avaient pas d’enregistrements forward pour des hostnames éphémères. La résolution inverse existait pour l’audit, mais le forward DNS était incomplet par conception.
Soudain, des serveurs aléatoires se mettaient à faire des pauses sur sudo et des services démarraient lentement parce que leurs scripts de démarrage faisaient des recherches de noms.

L’« optimisation » a aussi rendu le dépannage plus difficile. Quand un serveur ne pouvait plus joindre les résolveurs DNS corporatifs (un drift de firewall),
les commandes d’administration de base ont commencé à se bloquer. Les opérateurs devaient se battre avec la machine pour la réparer. C’est l’équivalent opérationnel de marcher sur des râteaux.

Ils sont revenus à la pratique ennuyeuse : garder un mapping local correct du hostname dans /etc/hosts. Le DNS est resté autoritatif pour les vrais noms,
mais la machine pouvait toujours se résoudre instantanément. Cette entrée locale est devenue une fonctionnalité de fiabilité.

Conclusion : supprimer la résolution locale n’est pas de la « modernisation ». C’est externaliser l’amorçage au réseau et prier pour que le réseau soit parfait.
Le réseau n’est jamais parfait.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la journée

Une grande entreprise avec une flotte mixte (physique, VMs, conteneurs) avait une règle simple dans sa pipeline de build :
chaque nœud doit réussir un check de « self-resolution » avant d’être déclaré sain. C’était sans éclat et universellement détesté par ceux qui confondent
politique et bureaucratie.

Le check était littéralement : confirmer que getent hosts $(hostname) retourne en moins de 100ms et mappe sur loopback ou l’interface principale,
selon le rôle. Si ce n’était pas le cas, l’instance échouait le provisioning et était recyclée.

Pendant une fenêtre de maintenance DNS, un mauvais changement a augmenté la latence des résolveurs pour un sous-ensemble de segments. Beaucoup de systèmes ont eu des problèmes.
Mais les nœuds Ubuntu 24.04 nouvellement provisionnés n’ont pas aggravé l’incendie parce qu’ils avaient toujours une self-resolution locale fonctionnelle.

L’équipe d’astreinte a tout de même passé une nuit. Ils n’ont pas passé la nuit supplémentaire qu’ils auraient eue si chaque nœud autoscalé
avait rejoint la fête de la panne en se bloquant sur sudo et SSH lent.

La pratique ennuyeuse n’a pas empêché les incidents DNS. Elle a empêché que ces incidents DNS deviennent « tout est lent et personne ne peut administrer quoi que ce soit ».
Cette distinction est là où se trouve votre sommeil.

Blague n°2 : La partie la plus fiable de nombreuses infrastructures reste un fichier texte édité en 1983.

La correction ennuyeuse : faire concorder hostname et /etc/hosts

Votre objectif est simple : quand le système demande « qui suis-je ? », il doit obtenir une réponse instantanément sans toucher au DNS.
Cela signifie que le hostname courant doit être présent dans /etc/hosts sur une ligne de mapping loopback (ou une adresse locale appropriée).

À quoi ressemble le « correct » sur Ubuntu

Pour la plupart des serveurs Ubuntu, l’approche conservative, sans drame, est :

• Conserver 127.0.0.1 localhost et les entrées loopback IPv6 intactes.
• Utiliser 127.0.1.1 pour le hostname système (et éventuellement son FQDN).
• Veiller à ce que $(hostname) apparaisse sur cette ligne.

Exemple de pattern :

cr0x@server:~$ sudo sed -n '1,5p' /etc/hosts
127.0.0.1 localhost
127.0.1.1 ip-10-24-3-17 ip-10-24-3-17.internal

Pourquoi 127.0.1.1 et pas 127.0.0.1 ? Ubuntu/Debian réservent historiquement localhost pour localhost et mappent le hostname sur 127.0.1.1.
Cela évite certaines suppositions logicielles anciennes et garde la sémantique propre. Est-ce la seule façon ? Non. Est-ce la façon qui évite des cas limites surprenants sur Ubuntu ? Oui.

Quand vous devriez mapper sur une IP d’interface réelle

Si la machine exécute un logiciel qui se bind sur des adresses résolues par le hostname (certaines applications Java, certains systèmes clusterisés, certains daemons de stockage),
mapper le hostname sur loopback peut être incorrect. Dans ces cas :

• Mappez le FQDN sur l’IP de l’interface principale (celle que les services doivent annoncer).
• Conservez une entrée alias loopback pour le nom court si vous avez besoin de vitesse locale, mais faites-le intentionnellement.

C’est là que les clusters de stockage et les systèmes distribués deviennent pointilleux. Vous ne voulez pas que vos nœuds de cluster « se découvrent » sur loopback.
Si vous exécutez Ceph, des identités de nœuds Kubernetes, ou tout ce qui utilise gossip/peer advertising, confirmez les attentes avant de choisir le mapping.

Hostnames dans le cloud : décider qui peut renommer la machine

Ubuntu dans le cloud implique souvent cloud-init. Si cloud-init est autorisé à définir le hostname au démarrage, vous devez assurer
que le reste de votre configuration est cohérent :

• Si le hostname change, /etc/hosts doit le suivre.
• L’automatisation doit soit définir les deux au moment du provisioning, soit désactiver les changements de hostname pilotés par le fournisseur.

Le mode d’échec est prévisible : image dorée a ubuntu-template, l’instance devient ip-10-..., et maintenant la résolution de nom tape dans le DNS.
Votre ticket d’incident appellera ça « sudo broken » parce que les humains sont honnêtes de ce côté-là.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: “sudo takes 10–30 seconds”

Cause racine : $(hostname) ne se résout pas localement ; NSS tombe sur le DNS et attend des timeouts.

Fix : Ajoutez/mettre à jour 127.0.1.1 your-hostname (et éventuellement le FQDN) dans /etc/hosts, puis retestez avec time sudo -n true.

2) Symptom: “sudo: unable to resolve host …” appears after renaming

Cause racine : /etc/hostname ou hostnamectl a changé, mais /etc/hosts contient encore l’ancien nom.

Fix : Éditez /etc/hosts pour inclure le nouveau hostname ; ne revenez pas au nom précédent sauf si vous aviez l’intention de renommer.

3) Symptom: SSH login prompt appears slowly, but once logged in it’s fine

Cause racine : Les recherches DNS inverses côté serveur pour l’IP client sont lentes (UseDNS yes) ou les résolveurs sont inaccessibles.

Fix : Dans des environnements jetables, mettez UseDNS no. Dans des environnements audités, corrigez les enregistrements PTR et la reachabilité des résolveurs.

4) Symptom: Local services start slowly at boot; logs show “Temporary failure in name resolution”

Cause racine : Les services appellent la résolution de hostname tôt ; si le DNS est utilisé et pas prêt, ils se bloquent.

Fix : Assurez-vous que le hostname se résout via /etc/hosts et que hosts: dans nsswitch.conf a files en premier.

5) Symptom: Everything works on one network, breaks on another (VPN vs office vs cloud)

Cause racine : Votre système dépend du DNS en amont pour résoudre son propre hostname ; différents réseaux fournissent des vues/latences DNS différentes.

Fix : Rendre la self-resolution locale. Ensuite décidez si le DNS pour le hostname est requis pour des systèmes externes.

6) Symptom: You “fixed” /etc/hosts, but it still hangs

Cause racine : L’ordre NSS a été modifié, ou le hostname résolu n’est pas celui que vous pensez (FQDN vs nom court), ou la recherche concerne la résolution inverse de l’IP client (SSH).

Fix : Vérifiez hostnamectl, sudo sshd -T, et grep '^hosts:' /etc/nsswitch.conf. Utilisez time getent hosts ... pour isoler quel nom est lent.

7) Symptom: “sudo” is fast, but some storage/cluster component can’t bind or advertises 127.0.1.1

Cause racine : Vous avez mappé un hostname d’un service sur loopback, mais le service attend une adresse routable.

Fix : Mappez le service/FQDN sur l’IP réelle de l’interface. Conservez le mapping loopback seulement comme alias local si nécessaire.

Listes de contrôle / plan étape par étape

Checklist A: Fix sudo slowness caused by hostname/hosts mismatch (safe and fast)

1. Mesurez : time sudo -n true. S’il est constamment lent, continuez.
2. Identifiez le hostname : hostname et hostnamectl. Notez-le.
3. Vérifiez le mapping local : grep -n '127.0.1.1' /etc/hosts et cat /etc/hosts.
4. Sauvegardez : copiez /etc/hosts vers un fichier horodaté.
5. Éditez : assurez-vous qu’une ligne comme 127.0.1.1 your-hostname existe (ajoutez éventuellement le FQDN).
6. Validez : time getent hosts "$(hostname)" doit être < 0.1s en conditions normales.
7. Validez encore : time sudo -n true devrait tomber en dessous de la seconde.
8. Arrêtez. Ne touchez pas au DNS sauf si des symptômes persistent.

Checklist B: Fix slow SSH session setup (server-side)

1. Confirmez le délai : vérifiez les timestamps dans /var/log/auth.log autour de la connexion et de l’authentification.
2. Inspectez la configuration effective : sudo sshd -T | egrep 'usedns|gssapiauthentication'.
3. Si la résolution inverse n’est pas requise : mettez UseDNS no, redémarrez ssh, retestez.
4. Si la résolution inverse est requise : corrigez les enregistrements PTR et assurez-vous que les résolveurs sont atteignables avec faible latence depuis le serveur.
5. Retestez depuis un client et observez les logs à nouveau.

Checklist C: Prevent it in automation (the part future-you will thank you for)

1. Dans votre pipeline de provisioning, ajoutez un health check : getent hosts $(hostname) doit retourner rapidement.
2. Faites respecter la correction de /etc/hosts dans la construction d’image (les hostnames de template existent ; les laisser non corrigés non).
3. Décidez si cloud-init est autorisé à renommer l’hôte ; si oui, assurez-vous qu’il met aussi à jour hosts ou que vos outils le font.
4. Standardisez l’usage nom court vs FQDN ; les attentes mixtes créent des bugs fantômes.
5. Documentez les cas d’exception (clusters qui doivent résoudre vers des IP routables).

FAQ (les questions qu’on vous posera cinq minutes après la correction)

1) Why does a hostname mismatch affect sudo at all?

Parce que sudo (et les bibliothèques qu’il utilise) peuvent résoudre le hostname local pour le logging, l’audit, l’évaluation de politique ou l’affichage.
Si la résolution tombe sur un DNS lent, sudo hérite de cette attente.

2) Why is this showing up on Ubuntu 24.04 specifically?

Le comportement n’est pas nouveau, mais les déploiements 24.04 impliquent souvent cloud-init, des images templatisées et des defaults systemd-resolved.
Cette combinaison rend la dérive de hostname plus fréquente, et les timeouts plus visibles.

3) Do I need to reboot after fixing /etc/hosts?

Non. La résolution via /etc/hosts est lue au moment de la recherche. Une fois le fichier corrigé, les recherches devraient être immédiatement rapides.
Si vous avez changé le hostname lui-même, certains services peuvent nécessiter un redémarrage, mais la correction du hosts ne demande pas de reboot.

4) Should the hostname map to 127.0.1.1 or 127.0.0.1?

Sur Ubuntu/Debian, mapper sur 127.0.1.1 est le choix conventionnel et à faible surprise.
Gardez 127.0.0.1 pour localhost.

5) Should I put the hostname on the machine’s real IP instead of loopback?

Parfois. Si le hostname représente une identité réseau utilisée par d’autres hôtes ou membres de cluster, mappez-le sur l’IP de l’interface réelle et assurez-vous que le DNS correspond.
Si le hostname est surtout une identité locale et que vous voulez juste accélérer sudo, le mapping loopback est acceptable.

6) If I add the hostname to /etc/hosts, am I “lying” to DNS?

Vous fournissez un override local pour la correction locale. Ce n’est pas un mensonge ; c’est de l’amorçage.
Si d’autres systèmes doivent atteindre cet hôte par nom, vous avez toujours besoin d’un DNS correct. Les entrées locales ne remplacent pas cela.

7) SSH is slow only for some client networks. Is that still hostname mismatch?

Ça pourrait être, mais c’est plus souvent la résolution inverse côté serveur pour l’IP client. Différents sous-réseaux clients ont des comportements PTR différents.
Vérifiez les logs du serveur pour des écarts et confirmez le comportement de UseDNS.

8) What’s the safest way to rename an Ubuntu server without breaking sudo?

Utilisez hostnamectl set-hostname (ou éditez /etc/hostname avec précaution), puis mettez immédiatement à jour /etc/hosts
pour que le nouveau nom se résolve localement. Vérifiez avec getent hosts $(hostname).

9) Can systemd-resolved cache the wrong thing and keep it slow?

Le caching peut affecter les recherches DNS, mais une entrée correcte dans /etc/hosts avec files en premier dans NSS devrait bypasser entièrement le DNS.
Si c’est encore lent, votre ordre NSS ou le nom recherché est différent de ce que vous pensez.

10) Is disabling SSH reverse DNS (UseDNS no) always safe?

Assez sûr dans de nombreux environnements, mais pas toujours approprié. Si vous vous fiez aux contrôles basés sur l’hôte, à l’audit qui exige des PTR, ou à des politiques de logging strictes,
corrigez le DNS plutôt que de désactiver les vérifications.

Prochaines étapes pour empêcher la réapparition

La vérité opérationnelle : la discordance hostname/hosts n’est pas un « bug rare ». C’est un résultat routinier du templating, des métadonnées cloud et des humains qui renomment des serveurs
sans finir le travail.

Faites la correction ennuyeuse : assurez-vous que $(hostname) se résout instantanément via /etc/hosts. Validez avec getent.
Ensuite, et seulement ensuite, poursuivez les problèmes de qualité DNS ou le comportement de résolution inverse SSH si des symptômes persistent.

Étapes pratiques que je mettrais réellement dans un runbook :

• Ajouter un check automatisé de « self-resolution » aux pipelines de provisioning.
• Standardiser votre image de base : ligne /etc/hosts correcte, aucun hostname template laissé par erreur.
• Décider si SSH doit faire la résolution inverse dans votre environnement ; choisissez une politique, documentez-la, faites-la respecter.
• Quand vous renommez un hôte, traitez /etc/hosts comme faisant partie du renommage, pas comme un accessoire optionnel.

Vous n’obtiendrez pas de médailles pour avoir corrigé ça. Vous récupérerez votre après-midi. C’est le meilleur prix.