Debian 13: SSH повільно входить — DNS і GSSAPI вирішують це миттєво (випадок #65)

Що насправді означає «повільний вхід SSH» (симптоми, що мають значення)

«SSH повільний» — це неточно. Потрібно знати, на якому етапі саме відбувається затримка, бо різні стадії вказують на різні підозри. SSH — це конвеєр: TCP-з’єднання → обмін ключами → автентифікація → налаштування сесії. DNS і GSSAPI можуть блокувати різні частини цього конвеєра й мають зовсім різні «відбитки».

Звичайні «відбитки» повільного входу

• Затримка перед запитом пароля (або перед пропозицією будь-якого методу автентифікації): часто зворотний DNS-пошук (сервер намагається отримати ім’я клієнта за IP) або переговори GSSAPI.
• Затримка після успішної автентифікації (пароль прийнято, але prompt з’являється пізніше): модулі PAM, домашній каталог/автоматичне монтування, скрипти ініціалізації shell або DNS під час налаштування сесії PAM.
• Затримка тільки з певних мереж (в офісі повільно, вдома нормально): split-horizon DNS, фаєрвол, що блокує UDP/TCP 53, або недоступність Kerberos-реальму з однієї сторони.
• Затримка тільки при використанні імені хоста (IP працює швидко): резолюція DNS на клієнті або «шалені» search-домені.
• Затримка тільки при першому підключенні (потім швидко): кешування негативних відповідей DNS, «прогрів» резолвера або поведінка повторних спроб GSSAPI.

Ми фокусуємося на Debian 13 з OpenSSH, і два найшвидших «миттєвих» виправлення, коли повільність — до того, як ви отримали shell, це: зворотний DNS (UseDNS) і переговори GSSAPI (Kerberos).

Жарт №1: SSH — це як охоронець, який наполягає на перевірці вашого документа в базі, яка «тимчасово недоступна». Вас не відмовляють — ви просто застрягли на вулиці.

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

Це потік «я на виклику, 02:00, і керівництво чекає». Він призначений знайти вузьке місце за хвилини, а не задовольнити вашу цікавість.

Перше: знайдіть затримку (з погляду клієнта)

1. Запустіть SSH з підказками таймінгів і детальним виводом і подивіться, яка стрічка затримується.
2. Якщо затримка навколо рядків GSSAPI — підозрюйте Kerberos/GSSAPI. Якщо навколо «Authentications that can continue» або перед банером — підозрюйте зворотний DNS на сервері.

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

1. Перевірте прямі та зворотні запити для IP клієнта з сервера за допомогою системного резолвера.
2. Шукайте таймаути, довгі проходи search-доменів або PTR записи, що вказують на нісенітницю.

Третє: підтвердіть, що sshd чекає саме на це (логи й відладка sshd)

1. Тимчасово підвищте логування sshd на одне тестове вікно або запустіть debug-режим sshd на альтернативному порту.
2. Корелюйте часові позначки: якщо в логах sshd є паузи навколо «reverse mapping checking» або GSSAPI, відповідь у вас в руках.

Після цього вирішуєте: вимкнути UseDNS (зазвичай так), вимкнути GSSAPIAuthentication (часто так, якщо ви не використовуєте Kerberos) або виправити підлягаючий шлях DNS/Kerberos (кращий довгостроковий варіант).

Чому DNS і GSSAPI блокують SSH на Debian 13

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

• Зворотні DNS-пошуки використовуються для логування і (іноді) логіки контролю доступу. Сервер може намагатися зіставити IP клієнта з іменем хоста (PTR-запис), а іноді і перевірити, що це ім’я знову вказує на той самий IP (forward-confirmed reverse DNS, або FCrDNS).
• GSSAPIAuthentication дозволяє єдину авторизацію через Kerberos. Якщо увімкнено і клієнт це пропонує (або сервер віддає цьому пріоритет), sshd може намагатися узгодити цей механізм. Якщо Kerberos misconfigured, недоступний, блокується фаєрволом або повільний, SSH чекає.

На Debian 13 ви побачите ту саму фундаментальну поведінку, як і в інших сучасних випусках Debian: OpenSSH зібраний зі здоровими значеннями за замовчуванням для сумісності, а стек резолвера може включати systemd-resolved або класичний glibc-релсовер залежно від налаштування. Більшість болю виникає в середовищах, де DNS не завжди швидкий і коректний.

Зворотний DNS: класичний мовчазний вбивця

Зворотний DNS (PTR-записи) легко ігнорувати, бо більшість застосунків за ним не стежать. SSH — стежить. Не завжди і не в кожній конфігурації, але достатньо часто, щоб стати звичною кореневою причиною «SSH повільний».

Найгірші випадки:

• IP клієнта не має PTR-запису і ваш резолвер повторно намагається декілька серверів з довгими таймаутами.
• PTR існує, але вказує на ім’я, яке не резолвиться назад (FCrDNS не проходить — відбуваються додаткові пошуки).
• DNS-сервери доступні, але повільні, або доступні тільки через шлях VPN з втратою пакетів.
• Ваш резолвер має агресивні search-домени і пробує кілька суфіксів перед тим, як зафейлити.

GSSAPI: відмінно, коли працює, набридливо, коли ні

Kerberos чудовий, коли ним правильно керують. Коли ні — він падає в способи, що виглядають як «SSH застряг». Якщо GSSAPIAuthentication увімкнено в sshd і клієнт намагається його використати, обидві сторони можуть шукати реальми, контактувати з KDC і валідувати квитки. Якщо будь-хто з цього потребує DNS (а це часто так), отримуєте подвійний удар: GSSAPI чекає на DNS, який чекає на мережу з проблемами.

Жарт №2: GSSAPI — це як колега, який «щойно приєднається за п’ять хвилин», але спочатку має встановити оновлення.

Цитата про надійність (перефразовано)

Перефразована думка: «Надія — не стратегія.» — цитата, яку в SRE-кругах приписують генералу Гордон Р. Саллівану. Операційно це означає: ви вимірюєте й перевіряєте, а не сподіваєтесь.

Цікаві факти та історія (щоб дивні речі стали зрозумілі)

• Факт 1: OpenSSH став дефакто-реалізацією SSH після того, як оригінальний SSH мав ліцензійні обмеження; OpenSSH зробив ставку на безпечні значення за замовчуванням, навіть якщо вони іноді були «балакучими».
• Факт 2: Зворотний DNS (PTR-записи) живе в спеціальній зоні DNS під in-addr.arpa (IPv4) і ip6.arpa (IPv6). Багато організацій вважають його опціональним — поки на ньому не базуються логування й контроль доступу.
• Факт 3: Концепція «forward-confirmed reverse DNS» з’явилася з гігієни проти підробки: це не сильна ідентифікація, але зменшує випадкове неправомірне маркування.
• Факт 4: Kerberos у багатьох розгортаннях сильно залежить від DNS (SRV-записи, мапінг реальмів), тож «Kerberos повільний» часто означає «DNS повільний, двічі».
• Факт 5: Перевірка ключа хоста SSH стосується ідентичності сервера, а не клієнта; зворотні DNS-пошуки в основному потрібні для імен у логах і політиках.
• Факт 6: systemd-resolved ввів нові кешування та поведінку stub-resolver у багатьох Linux-середовищах; він виправив деякі проблеми і водночас створив нові шляхи для «залежить від налаштувань» при відладці.
• Факт 7: IPv6 може посилити проблеми з DNS: клієнти можуть віддавати перевагу AAAA-запитам, а зворотні IPv6-пошуки довші й можуть викликати додаткові таймаути, якщо неправильно налаштовані.
• Факт 8: NSS (Name Service Switch) може викликати несподівані затримки, якщо він звертається до джерел на кшталт LDAP/SSSD для пошуку хостів; DNS не завжди є єдиним сервісом імен.

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

Це перевірені в полі перевірки. Кожне завдання містить: команду, реалістичний вивід, що це означає і що далі робити. Запускайте їх на Debian 13, якщо не вказано інше. Замініть IP/hostname своїми.

Завдання 1: Визначте, де SSH зупиняється (клієнтський verbose)

cr0x@server:~$ ssh -vvv admin@db-01
OpenSSH_9.8p1 Debian-1, OpenSSL 3.3.2 3 Sep 2024
debug1: Connecting to db-01 [10.20.30.41] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_ed25519 type 3
debug1: Local version string SSH-2.0-OpenSSH_9.8p1 Debian-1
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.8p1 Debian-1
debug1: Authenticating to db-01:22 as 'admin'
debug1: Authentications that can continue: gssapi-with-mic,publickey,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Next authentication method: publickey
debug1: Server accepts key: /home/admin/.ssh/id_ed25519
Authenticated to db-01 ([10.20.30.41]:22) using "publickey".
debug1: Entering interactive session.

Значення: Клієнт спробував GSSAPI першим. Якщо ви бачите кількасекундну паузу між «Next authentication method: gssapi-with-mic» і помилкою, переговори GSSAPI забирають час.

Рішення: Якщо ви не використовуєте Kerberos SSH SSO, вимкніть GSSAPI на клієнті і/або сервері. Якщо використовуєте — перевірте доступність KDC і DNS для SRV/мапінгу реальмів.

Завдання 2: Точне замірювання часу з’єднання SSH

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

Значення: З вимкненим GSSAPI і прямим IP це швидко. Це сильно вказує на GSSAPI і/або DNS при використанні імен хостів.

Рішення: Якщо це швидко, але звичайний SSH повільний — проблема в конфігурації/шляху, а не в CPU, крипто чи базовому мережевому інтерфейсі.

Завдання 3: Порівняння швидкості при використанні імені хоста та IP

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

Значення: Підключення за ім’ям повільне; часто це означає проблему резолюції на клієнті (search-домени, пріоритет IPv6 або зламаний резолвер).

Рішення: Дослідіть резолюцію DNS на клієнті: getent hosts, конфіг резолвера і чи AAAA-запити таймаутять.

Завдання 4: Слідкуйте за резолюцією через glibc/NSS (клієнт або сервер)

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

Значення: getent використовує NSS (не лише «сирий» DNS). Якщо він повільний, SSH з іменами хостів теж буде повільним.

Рішення: Якщо getent зависає, перевірте /etc/nsswitch.conf і сервіси імен (DNS, files, ldap, mdns). Ви можете застрягти на LDAP або мертвому резолвері.

Завдання 5: Перевірте швидкість зворотного DNS для IP клієнта (на сервері)

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

Значення: Це той самий запит, який sshd може робити для логування і політик. Якщо він займає секунди або таймаутиться, sshd чекатиме.

Рішення: Якщо повільно або пусто — виправте PTR-записи і доступність резолвера, або вимкніть UseDNS в sshd, щоб припинити чекати на зворотні запити.

Завдання 6: Підтвердіть forward-confirmation (PTR відображається назад)

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

Значення: Прямий запит повертає початковий IP. Це чисте зіставлення і зменшує дивну поведінку sshd, коли він робить перевірку FCrDNS.

Рішення: Якщо forward вказує кудись іще — виправте DNS. Якщо не можете (мережа третьої сторони), вимкніть UseDNS і уникайте контролю доступу за іменами хостів.

Завдання 7: Швидко перевірте конфігурацію резолвера

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

Значення: Stub-resolver на 127.0.0.53 зазвичай вказує, що systemd-resolved у ланцюжку. Search-домени можуть викликати кілька запитів.

Рішення: Якщо search-домени довгі або некоректні — скоротіть їх. Якщо systemd-resolved хворий — виправте його або вкажіть у resolv.conf реальні DNS-сервери.

Завдання 8: Перевірте статус systemd-resolved і upstream-сервери

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

Значення: Підтверджує, які DNS-сервери фактично використовуються. Якщо ті сервери доступні тільки з деяких VLAN — ви знайшли причину, чому SSH повільний з «того місця».

Рішення: Виправте маршрути/фаєрвол для DNS-серверів або налаштуйте DNS для кожного лінка. Не залишайте клієнтів гадати.

Завдання 9: Протестуйте latency сирого DNS-запиту (на сервері) з dig

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

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

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

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

Значення: 18 ms — нормально. Якщо ви бачите 2000 ms або таймаути — це ваша SSH-затримка. SSH нічого особливого не робить — він просто чекає на DNS.

Рішення: Якщо час запиту високий — виправте latency DNS або вимкніть UseDNS. Якщо таймаутиться — перевірте мережеві ACL і чи не блокується TCP/UDP 53.

Завдання 10: Знайдіть поточні ефективні налаштування sshd

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

Значення: Це правда, включно з дефолтами і фрагментами конфігу. Якщо usedns yes і зворотний DNS повільний — sshd, ймовірно, буде зависати.

Рішення: Якщо ви не потребуєте контролю доступу за іменами хостів і у вас ненадійний зворотний DNS — встановіть UseDNS no. Якщо ви не використовуєте Kerberos SSO — встановіть GSSAPIAuthentication no.

Завдання 11: Спостерігайте логі sshd на предмет часових прогалин

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

Значення: Вісім секунд між «Connection from …» і «Accepted publickey …» часто вказує на затримку перед автентифікацією: зворотний DNS або спроба GSSAPI перед ключем.

Рішення: Корелюйте з виводом клієнта через -vvv. Якщо пауза до «Accepted publickey» — налаштуйте UseDNS/GSSAPI; якщо після — дивіться PAM і ініціалізацію shell.

Завдання 12: Запустіть debug-sshd на альтернативному порті (безпечне, тимчасове)

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

Значення: -ddd дуже галасливий, але показує, який метод намагаються застосувати й де зависає. Якщо вивід заморожується після рядка зворотного пошуку або GSSAPI — ви ізолювали причину без втручання в робочий процес sshd.

Рішення: Використовуйте це лише коротко й на захищеному хості. Після підтвердження зупиніть його і внесіть зміни в реальний сервіс.

Завдання 13: Перевірте базові речі Kerberos (тільки якщо ви ним користуєтесь)

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

Значення: Квитка немає, тож GSSAPI-автентифікація зазнає невдачі і може бути повільною, якщо виявлення реальму повільне.

Рішення: Якщо ви хочете Kerberos SSO — отримайте квиток (kinit) і виправте налаштування реальмів/KDC. Якщо ні — вимкніть GSSAPI для SSH, щоб уникнути марних спроб.

Завдання 14: Перевірте, чи ssh пропонує GSSAPI (конфіг клієнта)

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

Значення: Клієнт спробує GSSAPI першим. Навіть якщо сервер нормально налаштований, клієнт може даремно витрачати час на цю спробу.

Рішення: Вимкніть GSSAPI на клієнті для проблемних хостів або глобально, якщо ви ніде його не використовуєте.

Завдання 15: Підтвердіть фрагменти конфігу SSHD (Debian includes)

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

Значення: Ваші «реальні» налаштування можуть походити з drop-in. Люди змінюють /etc/ssh/sshd_config, перезапускають ssh, і дивуються, чому нічого не змінилося.

Рішення: Змінюйте потрібний файл (вважається кращим створити новий drop-in з вищим пріоритетом, напр., 99-local.conf), потім перевіряйте через sshd -T.

Завдання 16: Перевірте конфіг перед перезавантаженням

cr0x@server:~$ sudo sshd -t

Значення: Відсутність виводу означає, що синтаксис ОК. Якщо є помилка — sshd виведе її й вийде з кодом ≠ 0.

Рішення: Ніколи не перезапускайте sshd без sshd -t на віддаленій системі. Ви отримаєте лише один шанс «захопити» доступ перш ніж це стане рисою характеру.

Виправлення, що дійсно допомагають (UseDNS, GSSAPI і родичі)

Виправлення 1: Вимкніть зворотні DNS-пошуки в sshd (найчастіший виграш)

Якщо ваша організація не покладається на контроль доступу за іменами хостів (наприклад, ви не використовуєте pattern у AllowUsers/DenyUsers і не застосовуєте хост-орієнтовану автентифікацію через DNS), вимкніть це.

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

Що це робить: Перешкоджає sshd виконувати зворотні DNS-пошуки IP клієнта під час обробки підключення. Ваші логи будуть частіше містити IP. Вхід більше не чекатиме на PTR-таймаути.

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

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

Точка рішення: Якщо reload пройшов і sshd -T показує usedns no, повторно протестуйте SSH з проблемної мережі клієнта. Якщо повільність зникла — PTR/DNS-шлях був кореневою причиною. Потім виправте DNS коректно, якщо хочете кращих логів; ви більше не блокуєтесь.

Виправлення 2: Вимкніть GSSAPIAuthentication в sshd (якщо ви не користуєтесь Kerberos SSH)

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

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

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

Точка рішення: Якщо ви покладаєтесь на Kerberos для SSH SSO — не робіть цього глобально. Використовуйте Match-блоки або конфіг клієнта для збереження GSSAPI там, де воно потрібно, і вимкнення там, де ні.

Виправлення 3: Вимкніть GSSAPI на стороні клієнта (швидка ізоляція)

Якщо ви не можете змінити сервер (керований пристрій, політика або freeze змін), вимкніть GSSAPI на клієнті. Це особливо корисно для jump-хостів і ноутбуків операторів.

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

Значення: Ви припиняєте спроби GSSAPI першими і не платите за переговори.

Рішення: Розгорніть це для уражених груп користувачів. Якщо у вас централізоване керування dotfile — тримайте це таргетовано; не зламайте ту команду, що фактично використовує Kerberos.

Виправлення 4: Зробіть DNS швидким і нудним (реальне виправлення)

Вимкнення UseDNS — прийнятна міра пом’якшення. Виправлення DNS — це лікування. У production краще зробити обидва: зупинити кровотечу зараз, а потім позбутися основного ризику.

Конкретні покращення DNS, що впливають на латентність SSH:

• Переконайтеся, що всі підмережі клієнтів, які потрапляють на сервери, також мають робочі зворотні зони (PTR) або хоча б не таймаутні відповіді.
• Переконайтеся, що DNS-сервери доступні з усіх мережевих шляхів, звідки походять SSH-підключення (VPN, bastion, офісний Wi‑Fi, CI runners).
• Зменшуйте таймаути резолвера і кількість повторів тільки якщо ви розумієте радіус впливу. Надмірне тонке налаштування таймаутів може перетворити періодичний DNS у «все ламається швидко».
• Обріжте непотрібні search-домени. Кожен додатковий суфікс — додатковий запит при відмові.

Виправлення 5: Уникайте контролю доступу за іменами хостів, якщо DNS ненадійний

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

Віддавайте перевагу контролю по IP (фаєрволи, security groups) або контролю ідентичності на ключах/сертифікатах (authorized_keys, certificates). Використовуйте імена хостів для зручності, а не для примусу, якщо ви не готові оперувати DNS як критичною системою — бо так воно й є.

Виправлення 6: Якщо затримка після автентифікації — не звинувачуйте DNS

Ця стаття про DNS і GSSAPI, бо вони дають «мить» покращення в найпоширенішому випадку повільного входу. Але якщо затримка після успішної автентифікації, перевірте:

• pam_mkhomedir, що створює домашні каталоги при першому вході
• Мережеві домашні каталоги (NFS/Autofs), що чекають на монтування
• SSSD/LDAP затримки в PAM account/session
• Повільні скрипти запуску shell (.bashrc, .profile), що викликають мережеві команди

Різна стадія в конвеєрі — різне виправлення. Діагностуйте перед зміною.

Три корпоративні міні-історії з практики

1) Інцидент через хибне припущення: «Зворотний DNS — опційний»

Компанія була в середині міграції на нового постачальника VPN. План проекту охоплював маршрути, MFA і розгортання клієнтів. Зворотний DNS не потрапив до списку, бо історично «ніхто ним не користувався». Це припущення було правдиве в вузькому сенсі: ніхто не подав тікет із назвою «PTR records».

В перший день інженери почали скаржитися, що SSH до production-хостів займе 20–30 секунд до появи запиту пароля. Деякі сесії були нормальні; інші — ні. Спільним фактором виявився новий пул адрес VPN. Він жив у новій підмережі без делегованої зворотної зони, а DNS-сервери для цієї підмережі були доступні лише з дата‑центру — а не з сегмента, де працював sshd.

On-call команда спочатку ганялася за CPU та ентропією. Дивилися навантаження, перевіряли генерацію випадкових чисел і навіть перемикали декілька шифрів «просто щоб подивитись». Нічого не допомагало. Тим часом helpdesk реєстрував інциденти «SSH ненадійний» і піднімав їх як «регресії продуктивності сервера».

Виправлення було нудне: або додати PTR-записи (і зробити DNS доступним з серверів), або припинити чекати sshd на зворотний DNS. Вони обрали двоступеневий підхід: миттєва міра — UseDNS no. Потім мережна команда реалізувала зворотні зони для VPN-пулів і перевірила доступність з усіх VLAN серверів, що приймають SSH. Другий крок був важливим, бо інші системи — збагачення логів і кореляція SIEM — також отримали користь. Але SSH повернув prompt за кілька хвилин, і це дало їм час.

2) Оптимізація, що відвернула назад: «Давайте піджати таймаути резолвера»

Інша організація втомилася від довгих зависань додатків під час DNS-аутів. Хтось із добрими намірами і трохи надмірною впевненістю змінив поведінку резолвера глобально: менше повторів, коротші таймаути. Це зробило відмови швидшими, що здавалося перемогою.

Потім з’явився новий тип відмов: не «DNS впав», а «DNS нестабільний». При легкому втраті пакетів стара конфігурація могла відновитися на повторі. Нова — фейлилась швидко й послідовно. SSH був одним із перших канарейок: спроби входу відмовляли або йшли дивними шляхами (невдалі спроби IPv6, відкат на IPv4, потім GSSAPI, потім таймаут).

Операційний результат став гіршим, ніж було раніше. Замість повільних, але працездатних сесій інженери отримали періодичні блокування від jump-хостів. Це підвищило ставку, бо тепер для усунення проблем потрібен доступ, який сам собою був деградований.

Урок не «ніколи не налаштовуйте таймаути». Урок — налаштовуйте з вимірами і в межах обсягу. Вони відкотили глобальні зміни резолвера, а потім застосували вузькі політики для конкретних сервісів з коректною логікою повторів. SSH знову став нудним. У продакшні нудне — це добре.

3) Нудна, але правильна практика, що врятувала ситуацію: «Завжди майте позасмуговий доступ і reload, не restart»

Інфраструктурна команда планувала вимкнути UseDNS і GSSAPIAuthentication на флоті Debian 13 після повторних скарг на повільні входи з партнерської мережі. Вони зробили правильно: написали drop-in, перевірили синтаксис за допомогою sshd -t і використали systemctl reload замість restart.

Під час розгортання один хост повівся інакше. Старий фрагмент конфігу мав опечатку в не пов’язаній директиві. Це ніколи не помічали, бо sshd вже працював і ніхто давно не примусив його повний розбір конфігу. Reload міг би впасти, якби вони робили restart — і це могло вбити єдиний віддалений шлях доступу.

Тому що вони використали валідацію і reload, вони безпечно зловили помилку. Виправили опечатку, ще раз перезавантажили reload і продовжили. Ніяких героїчних дій, жодного доступу до консолі в дата‑центрі, ніякого панічного «хтось увімкніть монітор».

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

Типові помилки: симптом → коренева причина → виправлення

1) Симптом: пауза 10–30с перед запитом пароля

Коренева причина: sshd чекає на зворотний DNS (PTR) для IP клієнта; резолвер повторює спроби/таймаути.

Виправлення: Встановіть UseDNS no в sshd і/або виправте PTR-записи та доступність DNS. Перевірте через sshd -T і getent hosts <client-ip>.

2) Симптом: пауза на «Next authentication method: gssapi-with-mic»

Коренева причина: Спроба GSSAPI/Kerberos першою; виявлення реальму/KDC повільне або не вдається.

Виправлення: Вимкніть GSSAPIAuthentication на клієнті/сервері, якщо не використовується. Якщо використовується — виправте конфіг Kerberos, доступність KDC і DNS SRV/мапінг реальмів.

3) Симптом: SSH по IP миттєвий, по імені хоста повільний

Коренева причина: Проблеми резолюції на клієнті (search-домени, таймаути AAAA, поганий резолвер).

Виправлення: Використовуйте getent hosts і resolvectl status щоб знайти, де резолюція застрягає. Виправте сервера резолвера і search-домени; розгляньте AddressFamily inet як діагностику (не як постійне рішення).

4) Симптом: затримка після «Authenticated» але перед prompt

Коренева причина: PAM session модулі, мережеві домашні, SSSD/LDAP або ініціалізація shell.

Виправлення: Перевірте journalctl -u ssh на таймінги сесій, потім огляньте PAM-конфіг і ініціалізацію шелла користувача. Не витрачайте час на перемикання UseDNS, якщо затримка після автентифікації.

5) Симптом: тільки VPN-користувачі бачать повільні входи

Коренева причина: Для пулу VPN відсутня зворотна зона або DNS-сервери недоступні з мережевого шляху сервера. Іноді проблеми з MTU/фрагментацією роблять DNS «ніби працює».

Виправлення: Реалізуйте PTR для VPN-пулів і забезпечте доступність DNS; паралельно вимкніть UseDNS, щоб прибрати залежність.

6) Симптом: зміна /etc/ssh/sshd_config нічого не змінила

Коренева причина: Debian використовує drop-in у /etc/ssh/sshd_config.d/; фрагмент перекриває вашу директиву.

Виправлення: Використайте sshd -T щоб підтвердити ефективну конфігурацію і знайдіть фрагменти з grep -R. Помістіть своє перекриття у 99-local.conf.

Контрольні списки / покроковий план (безпечне впровадження)

Крок за кроком: прискорення входів без ризику на одному сервері Debian 13

1. Підтвердіть вузьке місце. З клієнта запустіть ssh -vvv і зазирніть, де відбувається пауза.
2. Перевірте зворотний DNS з сервера. Виконайте getent hosts <client-ip>; якщо повільно — ймовірна причина.
3. Перевірте ефективні налаштування sshd. Запустіть sudo sshd -T | egrep 'usedns|gssapiauthentication'.
4. Створіть локальний drop-in для перекриття. Використовуйте /etc/ssh/sshd_config.d/99-local.conf, щоб не боротися з фрагментами від вендора.
5. Валідуйте конфіг. Запустіть sudo sshd -t. Відсутність виводу — означає OK.
6. Reload, не restart. sudo systemctl reload ssh зберігає існуючі сесії і зменшує ймовірність «ой».
7. Перевірте нову ефективну конфігурацію. Знову sudo sshd -T.
8. Перетестуйте з ураженої мережі. Заміряйте час з /usr/bin/time -p ssh ... true.
9. Спостерігайте логи. Перевірте journalctl -u ssh -S -5m на покращення таймінгів.
10. Потім виправляйте DNS коректно. Якщо UseDNS маскував проблеми з PTR/DNS-доступністю — заплануйте їх усунення. Операційний борг накопичує відсотки.

Контрольний список управління змінами: розгортання на флоті без драми

• Виберіть 2–3 репрезентативні хости (різні підмережі, ролі, шаблони автентифікації).
• Зніміть базові таймінги (ім’я хоста і IP, з GSSAPI і без).
• Реалізуйте конфіг через автоматизацію (один drop-in файл, послідовно для всіх хостів).
• Релоадьте sshd партіями; моніторте аномалії автентифікації.
• Підтвердіть, що жодна команда не залежить від Kerberos SSH перед глобальним вимкненням GSSAPI.
• Переконайтеся, що маєте альтернативний шлях доступу (bastion, консоль, позасмуговий доступ) перед змінами SSH у масштабі.
• Після розгортання перевірте: ефективний конфіг sshd, латентність входів і ясність логів.

FAQ

1) Чи завжди слід ставити UseDNS no на серверах?

У більшості середовищ: так. Якщо ви не використовуєте контроль доступу за іменами хостів в sshd, вимкнення прибирає крихку залежність і пришвидшує входи під час проблем з DNS.

2) Чи знижує безпеку вимкнення UseDNS?

Це може послабити деякі «помилкові» заходи безпеки. Якщо ви покладалися на імена клієнтів для контролю доступу — це вже ненадійно. Краще використовувати контролі по IP і ключі/сертифікати для ідентичності.

3) Ми використовуємо Kerberos. Чи можна виправити повільний SSH без вимкнення GSSAPI?

Можна. Виправте підлягаючу інфраструктуру Kerberos/DNS: переконайтеся, що KDC доступні, мапінг реальмів коректний, і SRV-записи швидко резолвляться з мереж серверів і клієнтів.

4) Чому SSH повільний тільки з одного офісу або VPN?

Бо доступність DNS і зворотні зони часто різняться по мережах. Цей офіс може звертатися до іншого резолвера або пул VPN може не мати PTR-зон.

5) Я вимкнув GSSAPI на сервері, але клієнти все ще повільні. Чому?

Клієнти все ще можуть повільно резолвити ім’я сервера (резолюція на клієнті), або затримка після автентифікації (PAM, монтування, скрипти). Використовуйте ssh -vvv і серверні логи, щоб знайти стадію.

6) Який найбезпечніший спосіб протестувати зміни sshd віддалено?

Використайте sshd -t перед застосуванням змін, потім systemctl reload ssh. Для глибшої діагностики тимчасово запустіть окремий debug-sshd на порті 2222.

7) Чи може IPv6 спричиняти повільні входи SSH, навіть якщо ми «не використовуємо IPv6»?

Так. Клієнти можуть робити AAAA-запити і пробувати IPv6 підключення першими. Якщо IPv6 частково увімкнений (відсутні маршрути, фаєрвол блокує) — виникають таймаути. Діагностуйте через порівняння ім’я/IP і тести резолвера.

8) Чи щось ще зламається, якщо вимкнути UseDNS?

В основному зміниться спосіб, як sshd резолвить і логуватиме імена клієнтів. Якщо у вас є обробка логів, що очікує імена хостів — налаштуйте її. Операційно, логування IP зазвичай прийнятне.

9) У мене затримка після «session opened» у логах. Це ще DNS/GSSAPI?

Менш ймовірно. Це вказує на роботу PAM-сесії, мережеві домашні або ініціалізацію shell. Виправлення у PAM, SSSD/LDAP, automount або dotfiles користувача — а не у UseDNS.

10) Яка різниця між виправленням DNS і простим вимкненням UseDNS?

Вимкнення UseDNS зупиняє sshd від очікування зворотних пошуків. Виправлення DNS покращує все середовище: збагачення логів, Kerberos, service discovery та інші сервіси, що роблять запити. Якщо можете — робіть обидва.

Висновок: що робити далі

Якщо входи SSH на Debian 13 повільні — не гадати. Знайдіть паузу через ssh -vvv, підтвердіть поведінку DNS через getent/dig і перевірте ефективні налаштування sshd через sshd -T. Потім зробіть практичні кроки:

• Встановіть UseDNS no, якщо у вас немає тестованої причини його тримати.
• Встановіть GSSAPIAuthentication no, якщо ви не використовуєте Kerberos SSH SSO або не можете довести, що воно здорове.
• Безпечно перезавантажте sshd (перевірте конфіг, reload а не restart).
• Потім виправляйте DNS належним чином: зворотні зони для підмереж клієнтів, доступні резолвери і менше «креативних» search-доменів.

Нагорода миттєва: SSH перестане поводитися так, ніби глибоко обдумує ваш запит, і знову стане інструментом.