Ubuntu 24.04: невідповідність hostname і /etc/hosts ламає sudo/ssh — нудне виправлення, що заощаджує години

Що насправді ламається (і чому виглядає як DNS)

Суть: sudo і sshd не «роблять DNS» з нудьги. Вони викликають системні бібліотеки,
які часто резолвлять імена хостів у процесі логування, перевірок політик і заходів безпеки. Коли ім’я вашої машини не резолвиться
швидко до адреси (або взагалі не резолвиться), ви платите цим у вигляді таймаутів.

В Ubuntu резолюцію імен керує Name Service Switch (NSS), налаштований у /etc/nsswitch.conf.
Більшість налаштувань за замовчуванням перевіряють files (тобто /etc/hosts) перед DNS. Це добре: робить локальні пошуки швидкими та прогнозованими.
Але якщо в /etc/hosts немає поточного імені хоста або там невірне ім’я, резолюція переходить на DNS.
У лабораторній мережі з ненадійним DNS — або у хмарному VPC, де зворотний DNS повільний — ви отримаєте зависання.

Класичне повідомлення про помилку:
sudo: unable to resolve host somehost: Name or service not known
Але ви не завжди побачите його, бо залежно від терміналу, налаштувань логування і шляху викликів, це просто відчуватиметься як «sudo повільне».

Причина, чому SSH потрапляє в зону ураження: сервер часто робить зворотні DNS-запити для IP клієнта, а ваш хост може робити прямі запити теж.
Якщо UseDNS yes увімкнено (або за замовчуванням різні збірки відрізняються), сервер може чекати відповіді DNS.
Додаючи невідповідність локального імені хоста, ви отримуєте складені затримки — повільні підказки для автентифікації, повільне встановлення сесії, повільні логи.

Це не пафосний інцидент. Це «пісок у шестерні». Саме такі відмови крадуть увесь ваш день.

Цитата, яка підходить до операційної роботи: Надія — не стратегія. (парафраз ідеї, яка часто приписується лідерам з надійності)
Нудне виправлення — це стратегія. Зробіть його.

Жарт №1: DNS — єдина система, де «мабуть, це одна строка» і водночас це може зіпсувати весь ваш день.

Цікаві факти та історичний контекст (що пояснює дивну поведінку)

• /etc/hosts передував повсюдному DNS. Локальні файли хостів були первісною «службою довідника» на ранніх системах мережі ARPANET. DNS з’явився пізніше, щоб масштабувати проблему.
• Патерн «127.0.1.1» — це культурна річ Debian/Ubuntu. Debian історично використовував 127.0.1.1 для зв’язування системного імені хоста без прив’язки до конкретної мережевої інтерфейсної адреси.
• glibc NSS модульний за дизайном. Рядок hosts: у /etc/nsswitch.conf керує не тільки DNS vs files, але й mDNS та хуками systemd-resolved.
• Затримки зворотного DNS — давня проблема SSH. SSH-сервер може робити PTR-запити для IP клієнта; якщо DNS повільний, здається, що «SSH повільний».
• systemd змінив управління hostname. З systemd hostnamectl — це головний інтерфейс, а ім’я хоста зберігається в /etc/hostname (і іноді формується cloud-init).
• Образи хмари часто перейменовують себе. cloud-init і метадані провайдера можуть встановлювати hostname під час завантаження, іноді не оновлюючи /etc/hosts, як ви того очікуєте.
• sudo намагається бути безпечним, а не швидким. Воно логуватиме, перевіряє політики і іноді викликає пошук імен для аудиту та відображення. Затримка — вторинний ефект, не функція.
• «localhost» — це не просто атмосфера. 127.0.0.1 localhost (і IPv6 ::1) очікуються багатьма програмами; порушення цих відповідностей викликає складні наслідки.

Швидкий план діагностики (перевірте в цьому порядку)

Коли sudo зависає або SSH-з’єднання затримуються, потрібно швидко отримати сигнал. Ось порядок, який мінімізує хаос і максимально прояснює ситуацію.

1) Підтвердіть, що симптом — це затримка резолюції імен, а не CPU, диск або ентропія

Якщо затримка постійно ~5с, ~10с, ~30с — це натяк на таймаут. Спайки CPU і затримки диска виглядають хаотичніше.

2) Негайно перевірте hostname проти /etc/hosts

Це 30-секундна перевірка, що зекономить три години. Якщо системного імені немає в рядку loopback у /etc/hosts, виправте це.

3) Перевірте порядок NSS і стан systemd-resolved

Якщо /etc/nsswitch.conf намагається спочатку використовувати DNS замість files (або був змінений), ви можете створити затримку навіть за правильної hosts-файлу.

4) Для повільного SSH: перевірте поведінку DNS на сервері

Якщо сервер чекає на зворотний DNS для клієнтських IP, ви можете виправити це конфігурацією (UseDNS no) або правильними PTR-записами.
Віддавайте перевагу реальному DNS у стабільних корпоративних середовищах; у тимчасових — UseDNS no.

5) Тільки потім займайтеся upstream DNS, фаєрволами, split-horizon, VPN-клієнтами та метаданими хмари

Це реальні проблеми — але вони дорожча гілка дерева рішень. Заробіть право йти туди.

Практичні завдання: команди, виводи та рішення (12+)

Це точні перевірки, які я запускаю при виклику. Кожне завдання містить: команду, правдоподібний вивід, що це означає і яке рішення воно породжує.
Виконуйте їх від імені звичайного користувача, якщо не зазначено інше.

Завдання 1: Замірте, наскільки погана затримка (sudo)

cr0x@server:~$ time sudo -n true

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

Що це означає: sudo знадобилося 12 секунд, щоб фактично нічого не зробити. Це майже ніколи не пов’язано з CPU.
Класична територія таймаутів при пошуку імен.

Рішення: Перемикайтесь на перевірки резолюції імен перед тим, як чіпати пакунки, диски або параметри ядра.

Завдання 2: Подивіться поточний hostname (і чи схоже це на перейменування хмари)

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

Що це означає: Такий патерн виглядає як ім’я, призначене провайдером. Можливо, його встановив cloud-init або метадані.

Рішення: Переконайтеся, що /etc/hosts містить це ім’я. Якщо ні — спочатку виправте локально.

Завдання 3: Перевірте «офіційне» джерело hostname через 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

Що це означає: Система вважає своє ім’я ip-10-24-3-17. Саме це ім’я служби будуть намагатися резолвити.

Рішення: Переконайтеся, що це ім’я швидко резолвиться через files (hosts), а не DNS.

Завдання 4: Перегляньте /etc/hosts на предмет невідповідності

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

Що це означає: Ім’я системи — ip-10-24-3-17, але в /etc/hosts все ще підказано ubuntu-template.
Тому при спробі резолвнути поточне ім’я система переходить до DNS.

Рішення: Оновіть рядок з 127.0.1.1 (або додайте його), щоб включити поточне ім’я хоста та, за потреби, FQDN.

Завдання 5: Доведіть, що резолюція повільна (getent — ваш друг)

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

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

Що це означає: Навіть простий пошук зайняв 10 секунд. Це шлях NSS, що чекає на щось (здебільшого DNS).

Рішення: Виправте /etc/hosts, щоб цей пошук став миттєвим. Якщо залишиться повільним — перевірте nsswitch.conf і DNS.

Завдання 6: Перевірте порядок NSS (фактична політика резолюції)

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

Що це означає: Система має спочатку читати files. Добре. Отже, правильний запис у /etc/hosts перерве проблему.

Рішення: Якщо files не першим — поставте його першим, якщо у вас немає вагомої причини інакше (а, ймовірно, її немає).

Завдання 7: Побачити, на що чекає sudo (strace, швидко і прицільно)

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

Що це означає: Ви отримали явну помилку. Файл трасування покаже виклики на кшталт getaddrinfo() і час, витрачений на них.

Рішення: Перестаньте гадати. Виправте локальну резолюцію імен. Якщо політика вимагає коректного DNS — виправляйте DNS далі, але не пропускайте локальне відображення.

Завдання 8: Підтвердьте, що в /etc/hostname міститься очікуване ім’я (стійкість між перезавантаженнями)

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

Що це означає: Персистентне ім’я хоста співпадає з hostnamectl. Добре. Невідповідність саме в /etc/hosts.

Рішення: Редагуйте /etc/hosts, а не /etc/hostname, якщо ви не збираєтеся фактично перейменувати сервер.

Завдання 9: Перевірте стан systemd-resolved (чи ви ним взагалі користуєтесь?)

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

Що це означає: Resolved активний, тож конфігурація DNS може керуватися через /run/systemd/resolve, а /etc/resolv.conf може бути заглушкою.

Рішення: Не редагуйте /etc/resolv.conf навмання; спочатку перевірте, куди він вказує.

Завдання 10: Підтвердіть, чи /etc/resolv.conf — це 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

Що це означає: DNS опосередковується systemd-resolved. Ваш «DNS повільний» може бути upstream, але невідповідність hostname все одно можна виправити локально.

Рішення: Розглядайте DNS окремо. Спочатку переконайтеся, що локальне ім’я хоста резолвиться без DNS.

Завдання 11: Швидко перевірте локальне відображення hosts (що резолвиться як localhost?)

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

Що це означає: Localhost у порядку. Проблема не в тому, що «хтось видалив localhost». Добра новина.

Рішення: Зосередьтеся на відображенні фактичного hostname, а не на поновленні всього файлу.

Завдання 12: Виправте /etc/hosts (безпечно) і перевірте швидкість пошуку

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

Що це означає: Ви замінили застаріле шаблонне ім’я хоста на реальне. Мінімальна зміна, максимальний ефект.

Рішення: Заново запустіть повільні команди. Якщо тепер вони миттєві — зупиняйтесь. Не «хапайтеся» за DNS без потреби.

Завдання 13: Підтвердіть виправлення через getent і час виконання sudo

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

Що це означає: Пошук тепер локальний і миттєвий; sudo повернувся до нормальних людських часових масштабів.

Рішення: Закрийте інцидент. Якщо SSH іще повільний — розбирайтеся окремо з налаштуваннями сервера для DNS.

Завдання 14: Якщо SSH повільний, протестуйте з перспективи сервера (тимінги в auth log)

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)

Що це означає: Між підключенням і прийняттям є 10-секундний разрив. Це часто вказує на затримки DNS або GSSAPI.

Рішення: Перевірте sshd_config на предмет UseDNS і GSSAPIAuthentication, якщо у вашому середовищі вони не потрібні.

Завдання 15: Перевірте конфігурацію демона SSH на шляхи повільні через DNS

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

Що це означає: Зворотний DNS увімкнено. В деяких мережах це нормально; в інших — гарантована затримка.

Рішення: Якщо ви не покладаєтеся на PTR для логування чи контролю доступу, встановіть UseDNS no і перезапустіть SSH.

Завдання 16: Застосуйте UseDNS no (якщо доречно) і підтвердіть перезавантаження

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

Що це означає: SSH перезапущено з новою опцією. Нові з’єднання більше не мусять чекати на зворотний DNS.

Рішення: Якщо ви в корпоративному середовищі, де зворотний DNS обов’язковий, виправляйте PTR-записи замість відключення цієї опції.

Три корпоративні міні-історії з реального життя

Міні-історія 1: Інцидент через хибне припущення

Середня SaaS-команда розгорнула Ubuntu 24.04 для набору внутрішніх раннерів. Ці машини не обслуговували клієнтський трафік безпосередньо,
але були мастилом у пайплайні: CI-запуски, підписування артефактів, збірки контейнерів. Ніхто не зауважив проблеми, поки не почалися таймаути у розгортаннях.

Припущення було простим і людяним: «Якщо SSH працює, машина в порядку». Інженери могли зайти в систему зрештою, тож історія перетворилася
на «мережа сьогодні повільна», потім «VPN глючить», потім «можливо, нове ядро некоректне». Людям подобається модна причина.

Вбивчою деталлю було те, що кожна команда з привілеями — встановлення пакунків, перезапуск сервісів, витяг логів від root — мала затримку 10–15 секунд.
Помножена на кроки автоматизації, CI-джоби роздулися в часі. Хтось нарешті замірив sudo -n true і побачив закономірність: постійна затримка, без стрибків CPU.

Виправлення — дві строки у /etc/hosts. Образ хмари був темплейтований з 127.0.1.1 ubuntu-template,
а cloud-init перейменував хост при завантаженні, не оновивши цей рядок. Система щоразу переходила на DNS, щоб резолвити себе.

Урок не в тому, щоб «стати розумнішим». Він у тому, щоб «не припускати за симптомом, який шар проблеми». SSH «доступний» не означає, що резолюція імен не вбиває вам інструменти з привілеями.

Міні-історія 2: Оптимізація, що вдарила в спину

Підрозділ фінансів мав ініціативу зі зменшення латентності, в яку включили обрізання сервісів під час завантаження образів.
Хтось вирішив, що локальні записи хостів — «спадщина», і що все повинно покладатися на «реальний DNS», бо «у нас є DNS».
Голден-образ отримав мінімалістичний /etc/hosts лише з localhost та IPv6 шаблоном.

У лабораторії це працювало. У продукції команда мереж мала split-horizon DNS з різними виглядами для сегментів,
і деякі сегменти не мали прямих записів для епhemeral імен. Зворотний DNS був для аудиту, але прямі записи були неповними за дизайном.
Раптом випадкові сервери заїдали на sudo, а деякі сервіси стартували повільно, бо стартові скрипти робили пошуки імен.

«Оптимізація» також ускладнила пошук причин. Коли сервер не міг дістатися корпоративних резольверів (помилка фаєрволу), базові адміністративні команди почали зависати.
Оператори мусили «боротися» з машиною, щоб її виправити. Це операційний еквівалент наступання на рейки.

Вони відкотилися до нудної практики: зберегти правильне локальне відображення hostname у /etc/hosts. DNS залишився авторитетним для реальних імен,
але машина завжди могла миттєво резолвити себе. Цей один локальний запис став функцією надійності.

Висновок: видалення локальної резолюції — не «модернізація». Це передача вашого завантаження на мережу і віра, що мережа ідеальна.
Мережа ніколи не ідеальна.

Міні-історія 3: Нудна практика, що врятувала день

Велика компанія зі змішаним парком (фізичні сервери, VM, контейнери) мала просте правило в пайплайні збірки:
кожен вузол має проходити «перевірку саморезолюції» перед тим, як вважатися здоровим. Це було непоказно і мало не подобалося тим, хто плутає політику з бюрократією.

Перевірка була буквально: переконатись, що getent hosts $(hostname) повертається за менше ніж 100мс і мапиться на loopback або на основний інтерфейс,
залежно від ролі. Якщо ні — інстанс відбраковувався і перепроваджувався.

Під час вікна обслуговування DNS погана зміна збільшила латентність резольверів для частини сегментів. Багато систем мали проблеми.
Але новостворені Ubuntu 24.04 вузли не погіршили ситуацію, тому що завжди мали робочу локальну саморезолюцію.

На чергуваннях усе одно були напружені моменти. Але вони не мали додаткової ночі, яку б тягнув додатковий натовп нових вузлів, що зависали на sudo і повільному SSH.

Нудна практика не запобігла інцидентам з DNS. Вона не дала цим інцидентам перерости в «все повільно й ніхто не може адмініструвати нічого».
Саме там зберігається ваш сон.

Жарт №2: Найнадійніша частина інфраструктури часто досі — текстовий файл, відредагований у 1983 році.

Нудне виправлення: узгодьте hostname і /etc/hosts

Ваша мета проста: коли система питає «хто я?», вона має отримати відповідь миттєво, не залучаючи DNS.
Це означає, що поточне ім’я хоста має бути присутнім у /etc/hosts на мапуванні loopback (або на відповідній локальній адресі).

Як виглядає «правильно» на Ubuntu

Для більшості серверів Ubuntu консервативний, безпечний підхід такий:

• Збережіть 127.0.0.1 localhost і записи IPv6 loopback незмінними.
• Використовуйте 127.0.1.1 для системного імені хоста (і за потреби його FQDN).
• Переконайтеся, що $(hostname) з’являється в цьому рядку.

Приклад шаблону:

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

Чому 127.0.1.1, а не 127.0.0.1? Ubuntu/Debian історично тримають localhost зарезервованим для localhost і мапують ім’я хоста на 127.0.1.1.
Це уникає деяких старих припущень програмного забезпечення і зберігає семантику чистою. Чи це єдиний шлях? Ні. Чи це шлях, що уникає несподіваних крайніх випадків на Ubuntu? Так.

Коли слід мапити на реальну IP-інтерфейс

Якщо машина запускає софт, який прив’язується до адрес, що повертаються за іменем хоста (деякі Java-додатки, кластерні системи, сховища),
мапування імені хоста на loopback може бути неправильним. У таких випадках:

• Мапуйте FQDN на IP основного інтерфейсу (той, який сервіси мають рекламувати).
• Залишайте локальну loopback-аліасу для короткого імені, якщо вам потрібна локальна швидкість, але робіть це свідомо.

Тут кластери зберігання та розподілені системи стають вибагливими. Ви не хочете, щоб вузли кластера «виявляли» себе через loopback.
Якщо ви запускаєте Ceph, ідентичності вузлів Kubernetes або будь-що з gossip/peer-оголошеннями, перевірте очікування перед вибором мапінгу.

Hostnames у хмарі: вирішіть, хто може перейменовувати машину

Ubuntu у хмарі часто включає cloud-init. Якщо cloud-init має право встановлювати hostname під час завантаження, вам потрібно гарантувати,
що решта конфігурації узгоджена:

• Якщо hostname змінюється, /etc/hosts має його відстежувати.
• Автоматизація має або встановлювати обидва на етапі провізіонування, або відключити перейменування, кероване провайдером.

Режим відмови передбачуваний: голден-образ має ubuntu-template, інстанс стає ip-10-..., і тепер резолюція імен тікає в DNS.
Ваш інцидент у трекері називатимуть «sudo зламаний», бо люди чесні в такому формулюванні.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Симптом: «sudo займає 10–30 секунд»

Корінь проблеми: $(hostname) не резолвиться локально; NSS переходить на DNS і чекає таймаутів.

Виправлення: Додайте/оновіть 127.0.1.1 your-hostname (і за потреби FQDN) у /etc/hosts, потім перевірте time sudo -n true.

2) Симптом: «sudo: unable to resolve host …» з’являється після перейменування

Корінь проблеми: /etc/hostname або hostnamectl змінилися, але /etc/hosts ще містить старе ім’я.

Виправлення: Відредагуйте /etc/hosts, щоб включити нове ім’я; не відкатуйте перейменування, якщо ви його мали на увазі.

3) Симптом: підказка входу SSH з’являється повільно, але після входу все нормально

Корінь проблеми: На сервері повільні зворотні DNS-запити для IP клієнта (UseDNS yes) або резольвери недоступні.

Виправлення: У тимчасових середовищах встановіть UseDNS no. У середовищах з аудитом — виправте PTR-записи і доступність резольверів.

4) Симптом: локальні сервіси повільно стартують під час завантаження; у логах — «Temporary failure in name resolution»

Корінь проблеми: Сервіси викликають резолюцію hostname рано; якщо використовується DNS і він ще не готовий — вони чекають.

Виправлення: Переконайтеся, що hostname резолвиться через /etc/hosts і що в nsswitch.conf рядок hosts: має files першим.

5) Симптом: все працює в одній мережі, ламається в іншій (VPN vs офіс vs хмара)

Корінь проблеми: Ваша система залежить від upstream DNS для резолюції власного hostname; різні мережі дають різні вигляди/латентність DNS.

Виправлення: Зробіть саморезолюцію локально. Потім вирішіть, чи потрібен також DNS для зовнішніх систем.

6) Симптом: ви «виправили» /etc/hosts, але все одно зависає

Корінь проблеми: Змінено порядок NSS, або ім’я, яке резолвиться, відрізняється від очікуваного (FQDN vs коротке ім’я), або пошук — це зворотний DNS для IP клієнта (SSH).

Виправлення: Перевірте hostnamectl, sudo sshd -T та grep '^hosts:' /etc/nsswitch.conf. Використайте time getent hosts ..., щоб ізолювати, яке ім’я повільне.

7) Симптом: sudo швидкий, але якийсь компонент сховища/кластера не може прив’язатися або рекламує 127.0.1.1

Корінь проблеми: Ви мапували ім’я сервісу на loopback, але сервіс очікує маршрутизовану адресу.

Виправлення: Мапуйте сервіс/FQDN на реальний IP інтерфейсу. Залишайте loopback-мепінг лише як локальний псевдонім, якщо це потрібно.

Контрольні списки / покроковий план

Чекліст A: Виправлення повільності sudo через невідповідність hostname/hosts (безпечно і швидко)

1. Замір: time sudo -n true. Якщо постійно повільно — рухайтесь далі.
2. Визначте hostname: hostname і hostnamectl. Запишіть його.
3. Перевірте локальне відображення: grep -n '127.0.1.1' /etc/hosts і cat /etc/hosts.
4. Резервна копія: скопіюйте /etc/hosts у файл з міткою часу.
5. Редагуйте: переконайтеся, що існує рядок на кшталт 127.0.1.1 your-hostname (за потреби додайте FQDN).
6. Валідація: time getent hosts $(hostname) має бути < 0.1s в нормальних умовах.
7. Перевірка знову: time sudo -n true має впасти до субсекундного рівня.
8. Зупиніться. Не чіпайте DNS, якщо симптоми зникли.

Чекліст B: Виправлення повільного встановлення SSH-сесії (на боці сервера)

1. Підтвердіть затримку: перевірте часові мітки в /var/log/auth.log навколо підключення та автентифікації.
2. Перегляньте ефективну конфігурацію: sudo sshd -T | egrep 'usedns|gssapiauthentication'.
3. Якщо зворотний DNS не потрібен: встановіть UseDNS no, перезапустіть ssh, перевірте.
4. Якщо зворотний DNS потрібен: виправте PTR-записи і переконайтеся, що резольвери доступні з низькою латентністю від сервера.
5. Перевірте з клієнта й знову спостерігайте логи.

Чекліст C: Запобігання в автоматизації (частина, за яку подякує вам майбутнє)

1. У пайплайні провізіонування додайте health check: getent hosts $(hostname) має повертатися швидко.
2. Забезпечте коректність /etc/hosts у образі (шаблонні імена допустимі; залишати їх не виправленими — ні).
3. Вирішіть, чи cloud-init може перейменовувати хост; якщо так — забезпечте, щоб він також оновлював hosts або щоб це робила ваша автоматизація.
4. Уніфікуйте використання коротких імен vs FQDN; змішані очікування породжують фантомні баги.
5. Задокументуйте виняткові випадки (кластери, що повинні резолвитися до маршрутизованих IP).

FAQ (питання, які вам зададуть за п’ять хвилин після виправлення)

1) Чому невідповідність hostname впливає на sudo взагалі?

Тому що sudo (і бібліотеки, які воно використовує) можуть резолвити локальне ім’я хоста для логування, аудиту, оцінки політик або відображення.
Якщо резолюція переходить на повільний DNS — sudo успадковує очікування.

2) Чому це з’явилося саме на Ubuntu 24.04?

Поведінка не нова, але розгортання 24.04 часто пов’язані з cloud-init, шаблонними образами та налаштуваннями systemd-resolved за замовчуванням.
Ця комбінація робить дрейф hostname частішим, а таймаути помітнішими.

3) Чи потрібно перезавантажувати після виправлення /etc/hosts?

Ні. Резолюція імен через /etc/hosts читається під час запиту. Після корекції файл одразу починає працювати швидко.
Якщо ви змінювали саме ім’я хоста, можливо, деякі сервіси потребуватимуть перезапуску, але reboot не потрібен через hosts-файл.

4) Чи треба мапити hostname на 127.0.1.1 чи на 127.0.0.1?

В Ubuntu/Debian конвенційно прийнято мапити його на 127.0.1.1. Залишайте 127.0.0.1 для localhost.

5) Чи ставити hostname на реальний IP машини замість loopback?

Іноді так. Якщо hostname представляє мережеву ідентичність, якою користуються інші хости або члени кластера, мапуйте його на реальний IP інтерфейсу і забезпечте співпадіння з DNS.
Якщо ім’я переважно локальне і вам потрібно лише пришвидшити sudo, loopback-мепінг підходить.

6) Якщо я додав hostname у /etc/hosts, чи я «брешу» DNS?

Ви створюєте локальний оверрайд для коректності локальної роботи. Це не брехня — це bootstrap. Якщо інші системи мають досягати хоста за іменем, вам все одно потрібен коректний DNS.
Локальні записи hosts не замінюють зовнішню систему імен.

7) SSH повільний лише для деяких клієнтських мереж. Це все ще невідповідність hostname?

Може бути, але частіше це зворотний DNS на сервері для IP клієнта. Різні підмережі мають різну PTR-поведінку.
Перевірте логи сервера на розриви і підтвердіть поведінку UseDNS.

8) Який найбезпечніший спосіб перейменувати сервер Ubuntu без зламання sudo?

Використовуйте hostnamectl set-hostname (або обережно відредагуйте /etc/hostname), а потім негайно оновіть /etc/hosts
так, щоб нове ім’я резолвилось локально. Перевірте через getent hosts $(hostname).

9) Чи може systemd-resolved кешувати неправильний результат і зберігати затримки?

Кешування може впливати на DNS-пошуки, але правильний запис у /etc/hosts з files першим у NSS має обходити DNS повністю.
Якщо все ще повільно — перевірте порядок NSS або переконайтеся, що ви дивитесь те саме ім’я, яке резолвиться.

10) Чи безпечно завжди відключати зворотний DNS для SSH (UseDNS no)?

У багатьох середовищах це досить безпечно, але не завжди доречно. Якщо ви покладаєтеся на контролі на основі імен хостів, аудит, що вимагає PTR, або строгі політики логування,
виправляйте DNS замість відключення перевірок.

Наступні кроки, щоб уникнути повторення

Операційна істина: невідповідність hostname/hosts — це не «рідкісна помилка». Це рутинний наслідок шаблонізації, метаданих хмари і людей, які перейменовують сервери
без завершення всіх супутніх кроків.

Зробіть нудне виправлення: переконайтеся, що $(hostname) резолвиться миттєво через /etc/hosts. Перевіряйте через getent.
Потім, і тільки потім, розбирайтеся з якістю DNS або поведінкою зворотного DNS для SSH, якщо симптоми залишилися.

Практичні кроки, які я б додав у ранбук:

• Додайте автоматичну «перевірку саморезолюції» в пайплайни провізіонування.
• Стандартизуйте базовий образ: правильний рядок у /etc/hosts, без залишених шаблонних імен.
• Вирішіть, чи SSH має робити зворотний DNS у вашому середовищі; оберіть політику, задокументуйте її і застосуйте.
• Коли ви перейменовуєте хост, розглядайте /etc/hosts як частину перейменування, а не як опціональний аксесуар.

За це вам медалі не дають. Ви повернете свій вечір. Оце краща нагорода.