Debian 13: SSH повільно заходить — виправлення DNS і GSSAPI, які миттєво прискорюють вхід (випадок №5)

Швидкий план діагностики

Якщо у вас тільки п’ять хвилин (а вони у вас є), не «оптимізуйте SSH» навмання. Визначте місце зависання. Потім підправте ту одну налаштування, що відповідає цьому місцю.

Перше: виміряйте час входу з клієнта (знайдіть фазу)

Запустіть SSH з максимальною детальністю (verbosity) і спостерігайте, де саме він затримується. Якщо він зависає після «Authentications that can continue» або біля рядків GSSAPI — це один шлях. Якщо він зависає після аутентифікації, перед shell — часто це DNS або модулі PAM, що роблять пошуки імен.

Друге: перевірте логи сервера під час зависання

В іншому терміналі підписуйтеся на журнал sshd. Якщо бачите «reverse mapping checking getaddrinfo…» або великі паузи між рядками логів — це DNS. Якщо бачите «GSSAPI» і повторювані спроби — це переговори Kerberos/GSSAPI.

Третє: доведіть, що DNS повільний (forward + reverse)

З сервера виконайте зворотний резолв клієнтського IP у PTR, потім резолв цього імені назад. Якщо будь-який запит триває секунди або таймаутиться — ви знайшли затримку.

Четверте: застосуйте мінімальне безпечне виправлення

• Для зупинок через зворотні DNS: встановіть UseDNS no в /etc/ssh/sshd_config (або drop-in) і перезапустіть sshd.
• Для затримок через GSSAPI: встановіть GSSAPIAuthentication no (на клієнті та/або на сервері), якщо Kerberos не потрібен.

П’яте: повторно протестуйте і відкотіться, якщо змінили не те

Повільність SSH зазвичай детермінована. Якщо ви виправили правильну причину, все миттєво пришвидшиться. Якщо стало «інакше повільно», ви тепер дебагуєте щось інше (PAM, LDAP, монтування домашніх, скрипти shell).

Що насправді означає «повільний SSH вхід»

Коли люди кажуть «SSH повільний», вони зазвичай мають на увазі один з чотирьох типів затримки:

1. Повільне TCP-з’єднання: встановлення з’єднання йде повільно. Це мережеві маршрути, фаєрвол, відкидання SYN або вибір версії IP.
2. Повільний обмін ключами: затримки в криптонеговоренні. Рідко на сучасному обладнанні, якщо тільки ентропія не зламана або мережа не псует пакети.
3. Повільна аутентифікація: сервер довго перевіряє ваш ключ/пароль. Часто це PAM + LDAP/SSSD або GSSAPI.
4. Повільність після аутентифікації: аутентифікація проходить, а потім ви чекаєте перед отриманням shell. Зазвичай це зворотні DNS, модулі сесії PAM, automount або скрипти ініціалізації shell.

Ця стаття про випадки, коли з’єднання і обмін ключами швидкі, але ви все одно сидите і чекаєте—зазвичай тому, що сервер чемно намагається дізнатися ваше ім’я (DNS) або корпоративну ідентичність (Kerberos) і чекає відповіді від чужої інфраструктури.

Одна принципова порада: не вгадуйте. SSH дає достатню видимість, щоб ідентифікувати точну паузу за часовими мітками й логами. Користуйтесь ними.

Інженер надійності John Allspaw має фразу, яка мені подобається: Операції вдаються, коли ви розумієте систему такою, якою вона є, а не якою ви її уявляєте. Це вся проблема в одному реченні.

Цікаві факти та контекст (чому це повторюється)

• OpenSSH додав підтримку GSSAPI десятиліття тому, щоб вписатися в Kerberos-орієнтовані корпоративні мережі, де «безпарольний» означає квитки, а не ключі.
• Перевірки зворотного DNS в sshd старіші за більшість сучасних хмар; вони мали сенс, коли довіра базувалась на іменах хостів і логування по імені було звичним.
• Таймаути DNS часто «повільні за задумом»: резолвери роблять повторні запити до кількох серверів, по UDP потім TCP, через search domains, з експоненціальним збільшенням інтервалів.
• Відсутній PTR запис може бути гіршим за неправильний: неправильна відповідь швидка; таймаут — повільний.
• nsswitch контролює більше, ніж здається: якщо hosts: включає mdns, nis або має невдалий порядок, «простий пошук» перетворюється на подорож по помилках вашої мережі.
• systemd-resolved змінив поверхню налагодження: ви часто говорите з локальним stub резолвером, який потім зв’язується з upstream резолверами зі своїм кешуванням і поведінкою при помилках.
• Параметри клієнта SSH можуть запускати роботу на сервері: клієнт, що пропонує GSSAPI, може змусити сервер спробувати його виконати, навіть якщо це ніколи не спрацює.
• IPv6 може додати секунди затримки, не ламаючи нічого: AAAA-запити, недоступні v6 резолвери або поламані маршрути v6 створюють «таємничі паузи».

Два висновки: (1) більшість «проблем продуктивності» SSH фактично — проблеми з сервісом імен, і (2) правильне виправлення зазвичай — одна рядкова зміна конфігурації, коли ви довели причину.

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

Це не лабораторні команди. Це ті, які ви виконуєте в якийсь вівторок о 02:10, поки хтось питає «prod окей?». Кожне завдання містить, що означає вивід і яке рішення з нього випливає.

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

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

Значення: крипто та аутентифікація швидкі; пауза відбувається після «Entering interactive session». Це вказує на пост-аутентифікаційні кроки: зворотний DNS, модулі сесії PAM, automount або init-shell. DNS — головний підозрюваний.

Рішення: Далі перевірте логи сервера та резолюцію DNS із сервера.

Задача 2: Підпишіться на логи sshd під час відтворення

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

Значення: між відкриттям сесії і наступним рядком логу шість секунд паузи. Це вікно зависання.

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

Задача 3: Визначте IP клієнта з логів, потім протестуйте зворотний DNS на сервері

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

Значення: зворотний резолв таймаутиться. sshd може чекати на це під час входу, якщо UseDNS увімкнено або інші компоненти роблять подібні пошуки.

Рішення: Виправте доступність резолверів або вимкніть використання зворотного DNS в sshd (залежно від політики). Далі зʼясуйте: DNS зламаний на сервері чи тільки для тієї підмережі?

Задача 4: Перевірте, який резолвер використовує сервер (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

Значення: сервер покладається на 10.20.0.53/54. Якщо вони недоступні з цього хоста/VRF, DNS-запити будуть зависати.

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

Задача 5: Підтвердіть доступність DNS-серверів (не припускайте)

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

Значення: ваш резолвер недоступний з цього хоста. Це не проблема SSH як така; це проблема залежності.

Рішення: Виправте маршрутизацію/фаєрвол до DNS або тимчасово вкажіть цьому хосту досяжний резолвер; потім перегляньте політику UseDNS в sshd.

Задача 6: Перевірте, чи sshd налаштований робити зворотний DNS

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

Значення: sshd явно робить перевірки зворотного DNS і також спробує GSSAPI-аутентифікацію.

Рішення: Якщо ви не потребуєте логування по імені хоста або аутентифікації на основі хостів, встановіть UseDNS no. Якщо Kerberos SSH не використовується — вимкніть GSSAPI. Але спочатку перевірте, що саме спричиняє паузу.

Задача 7: Заміряйте час прямого та зворотного DNS (доведення повільності)

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

Значення: базовий шлях резолве займає ~6 секунд, що збігається з паузою при вході. Оце ваш «димовий кратер».

Рішення: Або виправте доступність DNS/записи, або скажіть sshd не блокуватись на цьому пошуку.

Задача 8: Перевірте 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

Значення: PTR вказує на хост, який не резолвиться назад у той же IP. Така невідповідність може спричиняти додаткові пошуки і плутанину в логах; деякі системи трактують це підозріло.

Рішення: Виправте PTR або A запис, якщо ви покладаєтесь на зворотний DNS для логування/аудиту. Якщо ні — відключіть UseDNS і припиніть платити цю «податку».

Задача 9: Безпечно вимкніть UseDNS через 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

Значення: синтаксис конфігу валідний, сервіс перезапущено коректно.

Рішення: Повторно протестуйте SSH за часом. Якщо стало миттєво — ви локалізували проблему до зворотних DNS-пошуків під час входу.

Задача 10: Підтвердіть покращення з клієнта

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

Значення: пауза зникла. Добре. Проте продовжуйте працювати: DNS все ще може бути зламаний, ви просто перестали чекати його в SSH.

Рішення: Заведіть інцидент чи задачу на відновлення доступності резолверів/гігієни PTR. Інші сервіси також можуть зависати.

Задача 11: Виявлення затримок GSSAPI з клієнта

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

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

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

Задача 12: Вимкніть GSSAPI на клієнті (для хоста) без змін на сервері

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

Значення: без спроб GSSAPI шлях аутентифікації коротший.

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

Задача 13: Вимкніть GSSAPI на сервері (тільки якщо 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

Значення: сервер більше не пропонуватиме GSSAPI. Це може суттєво зменшити «першу метод-автентифікацію».

Рішення: Розгортайте таке тільки після впевненості, що вся інфраструктура не використовує Kerberos SSH для SSO.

Задача 14: Перевірте порядок пошуку хостів (nsswitch), коли «DNS норм, але getent повільний»

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

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

Рішення: Розгляньте спрощення резолюції хостів на серверах (часто files dns), але координуйте це з тим, хто встановив mdns спочатку.

Задача 15: Доведіть, чи systemd-resolved є вузьким місцем (кеш проти upstream)

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

Значення: resolved не може зв’язатися з налаштованими DNS для цього запиту. Це не «повільний запит», а «немає шляху до DNS», що часто проявляється як таймаути в інших місцях.

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

Задача 16: Переконайтеся, що затримка не від PAM/SSSD/LDAP (поширена підміна)

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

Значення: Тут нічого очевидного, але суть: перевірте, чи PAM-модулі роблять зовнішні виклики. (На багатьох системах ви натомість переглядали б /etc/pam.d/sshd і логи SSSD.)

Рішення: Якщо вимкнення UseDNS і GSSAPI не допомогло, переключайтесь на дебаг PAM/сесій та сервісів директорії.

Затримки зворотного DNS: класична причина «чому SSH чемний»

Зворотний DNS — причина номер один, чому SSH «працює, але відчувається повільним». sshd отримує IP клієнта і — в залежності від конфігурації — намагається резолвнути його в hostname, а потім інколи перевіряє, чи це ім’я резолвиться назад у той же IP. Якщо DNS повільний або зламаний — sshd чекає.

Неприємна правда: у багатьох середовищах PTR записи не підтримуються так само ретельно, як A/AAAA. Люди додають A/AAAA, бо без цього щось не працює. PTR трактують як «приємність», поки щось не почне блокуватися на них. sshd — один з таких сервісів.

Що насправді робить UseDNS (а що ні)

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

Вимкнення UseDNS не запобігає всім DNS-пошукам усього іншого. PAM-модулі, інструменти аудиту та ваш prompt можуть і далі робити резолви. Але це знімає одну часту синхронну затримку прямо в шляху входу.

Чому це гіршає в сучасних мережах

Хмари й корпоративні мережі люблять посередництво: оверлейні мережі, split-horizon DNS, кілька резолверів на інтерфейс, та безпекові пристрої, що інтерсептують DNS. Кожен шар додає режими відмов, що виглядають як «іноді повільно». SSH робить ці відмови дуже помітними, бо це інтерактивно й ви помічаєте кожну секунду.

І так, IPv6 заслуговує на згадку. Неправильні dual-stack налаштування часто спричиняють «спробуйте v6 перш ніж v4, повільно впаде, потім вдасться v4». Іноді ви не побачите цього в логах, якщо не дивитесь уважно.

Стратегія виправлення: чи дійсно вам потрібен зворотний DNS в sshd?

Задайте доросле питання: чи дійсно вам потрібні зворотні DNS-пошуки під час SSH-входу?

• Якщо ви використовуєте правила доступу на основі хостів з іменами в AllowUsers/DenyUsers або match-блоках, зворотний DNS може мати значення. Практично це рідко й часто крихке.
• Якщо ви покладаєтесь на логування за іменем хоста для розслідувань, ви можете думати, що воно потрібне. Але IP-адреси зазвичай надійніші за PTR в неідеальних мережах. Ви завжди можете робити зворотні запити офлайн, коли DNS працює.
• Якщо у вас немає дисциплінованого управління PTR, включення UseDNS — це податок, який платитиметься вічно.

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

Жарт №1: DNS — як офісна політика: коли він здоровий, ви не помічаєте його; коли зламався, усе стає наради.

А якщо потрібно лишити UseDNS увімкненим?

Тоді тримайте PTR як продакшн-дані. Підтримуйте їх. Моніторьте. Тестуйте з серверних підмереж, що важливі. І переконайтесь, що сервери можуть швидко дістатися своїх резолверів.

Також: встановіть реалістичні таймаути резолверів. Деякі середовища погоджуються на довгі таймаути «бо рано чи пізно воно спрацьовує». Інтерактивні входи цього не приймають.

GSSAPI/Kerberos затримки: корпоративний податок, якого ви можливо не повинні платити

GSSAPI в SSH існує для того, щоб аутентифікація могла проходити за допомогою Kerberos-квитків. В потрібному середовищі це чудово: single sign-on, централізована політика, менше розкиду SSH-ключів. В невідповідному середовищі це повільна, що не вдається перевірка перед кожним входом.

Коли GSSAPI увімкнено, клієнт і сервер можуть виконати одну чи кілька Kerberos-обмінів перед тим, як впасти назад до public key або пароля. Якщо у клієнта немає квитків, якщо KDC недоступний, якщо зворотний DNS для realm’ів зламаний, або якщо час синхронізовано некоректно — ви отримаєте секунди затримки на кожну спробу.

Як розпізнати повільний GSSAPI

Вивід з клієнта з детальністю зазвичай показує це явно: він пробує gssapi-with-mic, падає з повідомленням «No Kerberos credentials» або подібним, і тільки потім пропонує ключ. Іноді він повторює спроби. Іноді чекає на DNS SRV-запити для KDC. Інколи чекає на мережеві таймаути до KDC.

На відміну від UseDNS, повільність GSSAPI часто видно в фазі аутентифікації, до «Entering interactive session». Так ви швидко відрізните ці проблеми.

Стратегія виправлення: вимикайте там, де доцільно, не ламайте SSO випадково

Є два безпечні підходи:

1. Вимкнення на стороні клієнта для конкретних хостів (~/.ssh/config) для хостів, де Kerberos не використовується. Це не ламає інші хости, де Kerberos SSH потрібен.
2. Вимкнення на сервері, коли ви впевнені, що середовище зовсім не використовує Kerberos SSH. Це не дозволить клієнтам навіть намагатися це робити.

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

Жарт №2: Kerberos — чудовий, поки ним не стає; потім це розподілена система з емоціями.

GSSAPI cleanup і пересилання квитків

Опції на кшталт GSSAPICleanupCredentials і пересилання клієнтських облікових даних можуть впливати на безпеку й UX, але зазвичай вони не є головною причиною «вхід повільний». Якщо ваша затримка під час аутентифікації і GSSAPI увімкнено — почніть з з’ясування, чи воно падає і таймаутиться, чи виконується швидко.

Якщо ви дійсно використовуєте Kerberos, то розглядайте KDC-шлях як залежність: DNS, синхронізація часу, фаєрволи і конфігурація realm мають бути нудно правильними. SSH тут лише повідомник.

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

1) Інцидент через хибне припущення: «DNS завжди там»

Середня компанія перемістила групу Debian-хостів в «обмежений» сегмент мережі. У сегменті були суворі egress-правила: лише порти додатків, жодної «інфраструктури». Хтось припустив, що DNS «опрацьовуватиметься платформою», бо в інших сегментах так завжди було. Хости піднялися з резолверами на корпоративний DNS, але фаєрвол не дозволяв порт 53 з тієї VLAN до тих IP.

Все виглядало нормально в дашбордах. CPU був вільний. Сервіси працювали. Але інженери помітили, що SSH-входи зайняли 5–15 секунд. Вони списували це на «повільний VPN», аж поки відповідальний на виклику не почав дебаг і витратив цілу інцидентну зміну, чекаючи shell’ів.

Справжня шкода була не в затримці сама по собі; а в поведінці, що вона спричинила. Люди відкривали більше сесій «бо перша зависла». Bastion-хости стали перевантажені. Трекінг зʼєднань SSH зріс. Інцидентна відповідь виглядала хаотично через уповільнення інструментів.

Виправлення було болісно простим: дозволити DNS-egress до резолверів або розмістити резолвер у сегменті. Вимкнення UseDNS зробило SSH миттєвим негайно, але команда все одно мала виправити DNS, бо інші компоненти (встановлення пакетів, перевірка TLS, service discovery) також були на тонкому льоду. Урок — не «вимкнути UseDNS», а «перевіряйте залежності з мережі, де реально живе сервер».

2) Оптимізація, що дала назад: «Зробимо DNS безпечнішим»

Команда безпеки запровадила нову політику DNS: усі хости мали використовувати пару «secure resolvers», які фільтрували та логували. Вони розігнали зміну через CM. Резолвери були нормальні—поки не стали під навантаженням. У певних режимах відмов фільтрувальний шар приймав пакети, але затримував відповіді, поки не перевірить upstream.

SSH став канаркою. Інженери повідомляли, що логін в продакш зайняв іноді десять секунд, але лише в робочі години. Спочатку звинувачували шифрування: «Можливо, новий OpenSSH повільніший». Хтось пропонував міняти шифри. Інший — відключити компресію. Жодна ідея не допомогла, бо крипто тут ні при чому.

Уважний SRE порівняв часи з ssh -vvv і часи DNS-запитів і знайшов, що зворотні lookup’и зависали саме тоді, коли secure resolvers були під навантаженням. Ще гірше: навантаження корелювало вікнами сканування безпеки, що створювало потік невідомих доменів — саме те, що фільтр мав аналізувати синхронно для інтерактивних логінів.

Вирішення було двояким: (1) вимкнути UseDNS для серверного флоту, і (2) підлаштувати шлях secure resolver так, щоб таймаути були коротші і кеші більш ємні. Безпека отримала свої логи. SRE повернув свої shell’и. Повернення не означає «безпека погана», це означає «інтерактивні системи не можуть чекати вашу конвеєрну перевірку».

3) Нудна, але правильна практика, що врятувала день: поетапний rollout SSH-конфігурації

Інша компанія мала велику Debian-флоту зі строгим контролем змін, що дратує, поки не рятує. У них була норма: кожна зміна sshd має (a) застосовуватись через drop-in файли, (b) перевірятись командою sshd -t, і (c) розгортатись на невелику canary-групу перед масштабуванням.

Коли нове середовище почало повідомляти про повільний SSH, команда не кинулась «фіксити SSH». Вони зібрали докази: логи клієнта з -vvv, прогалини в journal сервера і таймінги DNS з getent. Підтвердили, що зворотні DNS-запити займали кілька секунд через відсутність PTR для нового VPN-пула.

Нудна практика врятувала: у них вже був затверджений drop-in для чутливих до продуктивності хостів: /etc/ssh/sshd_config.d/10-fast-login.conf з UseDNS no. Він пройшов ревʼю, тести й документацію. Їм розгорнули його спочатку на вражений сегмент, підтвердили покращення, а роботу з PTR винесли в окрему чергу.

Нічого драматичного не сталося. Ніхто не отримав друге сповіщення. Саме так виглядає «врятований день» в реальних операціях: менше сюрпризів, менше нічних героїчних дій, системи поводяться як ви очікуєте.

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

Це секція, яка стане в нагоді, коли ви втомлені і трохи сердиті на комп’ютери.

1) Симптом: довга пауза після «Authentication succeeded»

Причина: зворотний DNS під час налаштування сесії (UseDNS yes) таймаутиться або резолвер повільний.

Виправлення: встановіть UseDNS no в sshd; також виправте доступність резолверів і гігієну PTR.

2) Симптом: довга пауза перед тим, як пропонується ключ; verbose показує «gssapi-with-mic» спроби

Причина: увімкнена GSSAPI-аутентифікація; клієнт намагається Kerberos спершу і чекає на KDC/DNS/таймаути.

Виправлення: відключіть GSSAPIAuthentication на клієнті для хоста або на сервері, якщо Kerberos SSH не використовується.

3) Симптом: швидко в локальній мережі, повільно через VPN

Причина: VPN-пул адрес не має PTR або VPN-клієнти резолвлять через інший шлях; зворотні lookup’и таймаутяться.

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

4) Симптом: лише дехто сервери повільні, інші ні

Причина: ACL на DNS по підмережах, різні резолвери на інтерфейсах або split-horizon зони відсутні в одному вигляді.

Виправлення: порівняйте resolvectl status і доступність резолверів між хостами; уніфікуйте конфігурацію DNS по сегментах мережі.

5) Симптом: SSH повільний лише для деяких імен користувачів

Причина: PAM-модулі звертаються до LDAP/SSSD/automount для цих користувачів; причина не обов’язково в DNS/GSSAPI.

Виправлення: перевірте /etc/pam.d/sshd, логи SSSD та поведінку монтування домашніх директорій; протестуйте з локальним користувачем.

6) Симптом: «ssh повільний», але ssh -vvv показує затримку перед «Connection established»

Причина: затримка мережевого шляху, обмеження SYN на фаєрволі або резолвинг цілі (DNS на стороні клієнта), а не кроки входу на сервері.

Виправлення: підключіться по IP напряму, протестуйте з nc -vz і перевірте DNS клієнта vs DNS сервера.

7) Симптом: SSH повільний після входу (prompt з’явився, а потім команди гальмують)

Причина: скрипти ініціалізації shell роблять мережеві виклики (git prompt, kubectl context, LDAP-запити), або мережеві домашні директорії.

Виправлення: профілюйте шлях ініціалізації shell; тимчасово протестуйте з ssh user@host /bin/bash --noprofile --norc.

8) Симптом: вимкнення UseDNS допомогло, але логи стали «грубіші»

Причина: раніше ви покладалися на hostname-логи, отримані через PTR записи.

Виправлення: оновіть логіку/алерти, щоб орієнтуватись по IP; робіть зворотні DNS асинхронно в пайплайнах логів, якщо це потрібно.

Чек-листи / покроковий план

План A: потрібно швидко отримати SSH (безпечно і з можливим відкатом)

1. На клієнті захопіть ssh -vvv і занотуйте, де він зависає (auth чи пост-auth).
2. На сервері підпишіться на journalctl -u ssh -f під час відтворення.
3. На сервері виконайте sshd -T | grep usedns і sshd -T | grep gssapiauthentication.
4. Якщо пауза після auth і підозра на DNS: встановіть UseDNS no через /etc/ssh/sshd_config.d/.
5. Якщо пауза під час auth і verbose показує GSSAPI: відключіть GSSAPI на клієнті для хосту в ~/.ssh/config.
6. Перевірте синтаксис: sshd -t.
7. Перезапустіть SSH: systemctl restart ssh.
8. Повторно протестуйте з того ж клієнтського мережевого шляху, який був повільним (LAN vs VPN важливі).
9. Якщо виправлено, заведить задачу на інфраструктуру DNS/Kerberos, щоб інші сервіси не зависали.

План B: потрібно зберегти зворотний DNS і/або Kerberos (робіть це по-діловому)

1. Переконайтесь, що сервер може стабільно дістатися своїх резолверів (ICMP недостатньо; тестуйте UDP/TCP 53 через політику, якщо можна).
2. Переконайтесь, що PTR існують для всіх клієнтських підмереж (офіс, VPN, bastions, CI ранери).
3. Забезпечте forward-confirmed reverse DNS для критичних підмереж (PTR вказує на ім’я; ім’я резолвиться назад у той самий IP).
4. Для GSSAPI: перевірте доступність KDC, конфігурацію realm і синхронізацію часу; поламана NTP тихо зіпсує все.
5. Тримайте таймаути/повтори розумними в ланцюжку резолверів, щоб інтерактивні входи падали швидко при недоступності залежностей.
6. Періодично вимірюйте: зберігайте метрики «час входу SSH» з репрезентативних мереж.

План C: мінімальні і аудитуємi зміни

1. Використовуйте drop-ins у /etc/ssh/sshd_config.d/ замість редагування основного файлу.
2. Одна зміна на файл (легше відкотити).
3. Завжди запускайте sshd -t перед рестартом.
4. Тримайте відкриту консольну сесію під час рестарту, якщо ви віддалено, щоб не відрізати себе.

Питання і відповіді (FAQ)

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

Майже завжди так. Якщо тільки у вас немає конкретної, протестованої залежності від зворотного DNS в sshd. Більшість середовищ цього не потребують, і вартість платиться реальна, коли DNS ненадійний.

2) Чи зменшить безпеку вимкнення UseDNS?

Це прибирає клас перевірок на основі hostname, але перевірки по hostname зазвичай слабші за контроль по IP і ключах. Не використовуйте PTR як сигнал для авторизації. Використовуйте ключі, MFA, мережеві ACL і явні allowlist’и.

3) Чому SSH взагалі робить зворотний DNS?

Через спадщину й зручність логування. Старі практики опиралися на імена хостів і доступ за імені. Сьогодні мережі змінюються швидше, ніж PTR записи. IPи часто чесніші ідентифікатори.

4) Якщо я вимкну GSSAPI, чи зламаю я доменні входи?

Не обов’язково. Домашні користувачі все ще можуть аутентифікуватися через публічні ключі або паролі, залежно від налаштування PAM. Але ви зламаєте Kerberos-based SSH SSO для тих, хто ним користується. Тому починати краще з вимкнення на клієнті для конкретних хостів.

5) SSH повільний тільки при першому з’єднанні, потім швидкий. Чому?

Кешування DNS (клієнтське, серверне або в systemd-resolved) може робити наступні запити швидкими. Це підказка, що в процесі задіяний сервіс імен. Заміряйте з getent hosts і порівняйте холодний і теплий кеш.

6) Я встановив UseDNS no, але після auth все ще повільно. Що далі?

Перемикайтесь на PAM/сесію та середовище користувача: затримки LDAP/SSSD, automount домашніх директорій, повільні init-скрипти shell або збій мережевого файлового сховища. Протестуйте локального користувача з мінімальним shell, щоб ізолювати.

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

Так. Dual-stack резолюція і проблеми з доступністю можуть додавати затримки в DNS і зверненнях до сервісів ідентифікації. Шукайте шаблони «v6 спроба, потім fallback» у verbose логах і статусі резолвера.

8) Чи «виправити» це зміною шифрів або KEX алгоритмів?

Ні, не для цього симптому. Якщо ваша пауза вимірюється в секундах і відбувається після auth або під час GSSAPI, тюнінг крипто — це магія. Спочатку виміряйте; потім виправляйте ту залежність, яка насправді повільна.

9) Чи це специфічно для Debian 13?

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

10) Яка найменша зміна, що дає найбільший виграш?

UseDNS no часто дає миттєвий «інстантний» фікс для пост-аутентифікаційних пауз. Для пауз у фазі аутентифікації — найменша й безпечна зміна: відключити GSSAPI на клієнті для відповідного хоста.

Висновок: подальші кроки, що працюють

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

Зробіть наступне:

1. Захопіть один сеанс ssh -vvv, що показує паузу, і збережіть зі часовою міткою і типом клієнтської мережі (LAN/VPN/bastion).
2. На сервері виміряйте time getent hosts <client-ip>. Якщо це співпадає з паузою — діагноза завершена.
3. Встановіть UseDNS no через drop-in, перевірте sshd -t, перезапустіть, повторно протестуйте.
4. Якщо verbose показує GSSAPI-дзвінки, вимкніть його на клієнті для хоста спершу; вимикайте серверно лише коли впевнені, що Kerberos SSH не використовується.
5. Заведiть реальне виправлення: доступність резолверів, гігієна PTR, і (якщо треба) надійність KDC. SSH лише виявив проблему.

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