SSH медленно логинится: DNS, GSSAPI, PAM и UseDNS — где зависает и как ускорить вход

Медленный вход по SSH раздражает сильнее «явных» ошибок: TCP-соединение устанавливается мгновенно, а перед паролем или сразу после него появляется пауза 5–30 секунд (иногда дольше). При этом в логах может быть почти пусто, и кажется, что «просто думает».

На практике задержки обычно возникают в трёх местах: DNS (особенно reverse PTR и проверка FCrDNS), GSSAPI (Kerberos/SSO-обмен) и PAM (модули аутентификации/сессии, NSS, LDAP/SSSD и т.д.). Ниже — рабочая схема диагностики и настройки sshd_config, которые чаще всего дают мгновенный эффект.

Сначала определяем: где именно тормозит — до пароля или после

Первое, что важно выяснить: задержка происходит до аутентификации (до запроса пароля/ключа) или после (пароль приняли, но оболочка не стартует). Это сразу сужает круг: до пароля чаще виноваты DNS/GSSAPI, после — PAM, NSS или профили shell.

Диагностика со стороны клиента: ssh -vvv

Подключитесь с отладкой и смотрите, на какой строке появляется пауза:

ssh -vvv user@server

Ориентиры по выводу:

• Пауза до строки Authentications that can continue или до запроса пароля часто указывает на DNS или GSSAPI.
• Пауза после Authentication succeeded чаще связана с PAM/NSS, монтированиями, сетевыми домами или тяжёлыми профилями shell.

Диагностика на сервере: логи sshd в реальном времени

Параллельно откройте логи и повторите вход:

sudo journalctl -u ssh -f

На части дистрибутивов юнит называется иначе:

sudo journalctl -u sshd -f

Без systemd/journald проверяйте /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS/Alma/Rocky).

Цель этого шага — поймать «точку зависания»: до пароля, во время проверки пользователя или уже при старте сессии. Дальше вы точечно правите либо UseDNS/GSSAPIAuthentication, либо разбираете PAM.

DNS и reverse DNS: как UseDNS превращает вход в лотерею

Если включён UseDNS, sshd пытается сделать reverse DNS (PTR) для IP клиента и часто делает прямую проверку имени обратно в IP (FCrDNS). На практике это легко превращается в задержки из-за таймаутов резолвера.

Типовые причины:

• у IP клиента нет PTR-записи (часто домашний интернет, мобильные сети, корпоративный NAT);
• на сервере медленные или недоступные DNS в /etc/resolv.conf;
• на пути до DNS фильтрация UDP/53 и ожидание таймаутов;
• PTR есть, но FCrDNS не сходится (имя резолвится в другой IP).

Как быстро подтвердить проблему с reverse DNS

На сервере проверьте PTR для IP, с которого вы заходите:

getent hosts 203.0.113.10

Если вернулось имя — проверьте прямое разрешение обратно в A/AAAA:

getent ahosts example-client-hostname

Если эти команды «думают» секунды или десятки секунд — sshd будет думать так же, потому что использует тот же стек NSS/резолвинга.

Самый частый фикс: отключить UseDNS

На интернет-серверах, где SSH используют админы и автоматизация, UseDNS обычно не даёт практической пользы, но добавляет зависимость от внешнего DNS. Частый рабочий вариант:

sudoedit /etc/ssh/sshd_config

UseDNS no

Применяйте изменения безопасно (с проверкой синтаксиса):

sudo sshd -t

sudo systemctl reload sshd

На некоторых системах сервис называется ssh:

sudo systemctl reload ssh

Что учесть по безопасности

После отключения UseDNS sshd не будет пытаться определять имя хоста клиента через PTR при входе. Если вы где-то завязывались на hostname (например, в логике доступа), лучше перейти на IP/подсети, ключи и явные группы, а не на reverse DNS.

Если вы держите несколько серверов и хотите предсказуемую сетевую инфраструктуру без сюрпризов от «домашних» PTR и случайных DNS-таймаутов, удобнее администрировать доступ и сервисы на отдельном VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

GSSAPI и GSSAPIAuthentication: лишние попытки Kerberos = лишние таймауты

GSSAPIAuthentication позволяет входить через Kerberos/SSO. В доменной/корпоративной инфраструктуре это полезно. Но на сервере без Kerberos (или при проблемах с DNS SRV/realm/KDC) клиент может пытаться пройти GSSAPI-обмен и ждать таймауты.

Как выглядит симптом в ssh -vvv

В отладке видно, что клиент пробует GSSAPI одним из первых методов, и пауза возникает на строках про gssapi/kerberos (получение credential, определение realm, поиск KDC).

Быстрая проверка: отключить GSSAPI на клиенте

Подключитесь разово с отключением GSSAPI и сравните задержку:

ssh -o GSSAPIAuthentication=no user@server

Если стало заметно быстрее — причина найдена.

Решение: отключить GSSAPI на сервере, если SSO не используется

Если Kerberos-логин на этом сервере не нужен, проще отключить на стороне sshd:

sudoedit /etc/ssh/sshd_config

GSSAPIAuthentication no

Затем:

sudo sshd -t

sudo systemctl reload sshd

Когда отключать нельзя

Если сервер должен принимать SSO-вход (realm/AD/IPA), отключение GSSAPIAuthentication сломает ожидаемую схему доступа. Тогда вместо отключения проверьте: DNS SRV-записи, доступность KDC, корректность времени (Kerberos чувствителен к рассинхрону), настройки realm на клиентах.

PAM: «зависает после пароля» и почему это часто не про SSH

PAM отвечает не только за факт аутентификации, но и за «обвязку» сессии: учёт, ограничения, 2FA-модули, создание домашних директорий, применение лимитов, интеграции с каталогами. Поэтому классический симптом PAM-задержки: пароль/ключ приняли, а дальше несколько секунд (или десятки) тишина.

Как понять, что задержка именно в PAM/NSS

На клиенте: вы уже видите Authentication succeeded, но приглашение shell не появляется сразу.

На сервере: в логах может быстро появиться «Accepted password/publickey», а запись про открытие сессии или запуск оболочки — заметно позже.

Частые источники задержек

• LDAP/SSSD/Winbind: запросы к внешнему каталогу, особенно если он недоступен или есть сетевые потери.
• DNS внутри NSS: порядок источников в /etc/nsswitch.conf влияет на скорость поиска пользователя/групп.
• pam_mkhomedir: создание домашней директории на сетевом хранилище, медленные ACL.
• pam_systemd: проблемы с systemd-logind или D-Bus иногда дают неожиданные паузы.
• Профили shell: медленный .bashrc/.profile, сетевые вызовы, проверки обновлений, обращения к недоступным ресурсам.

Диагностический тест: временно отключить PAM для sshd

Тест делайте аккуратно и только при наличии второй активной SSH-сессии (чтобы не отрезать себе доступ). PAM часто нужен для 2FA, политик и корректного открытия сессии.

В отдельном тестовом окне:

sudoedit /etc/ssh/sshd_config

UsePAM no

sudo sshd -t

sudo systemctl reload sshd

Если задержка исчезла — ищите «тормозящий» модуль в /etc/pam.d/sshd и зависимых файлах (common-auth/common-session и аналоги зависят от дистрибутива).

Не оставляйте UsePAM no постоянным решением, если не понимаете последствия. Обычно правильнее устранить конкретный таймаут (SSSD/DNS/модуль), чем выключить весь слой.

Если для проекта нужен простой и предсказуемый SSH-доступ без доменных интеграций и сложного PAM-стека, часто хватает аккуратно настроенного виртуального хостинга для сайта и отдельного сервера под админку (или наоборот — по вашей схеме доступа).

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Практичный чек-лист: что проверять и в каком порядке

1. Снимите симптоматику через ssh -vvv и определите, пауза до аутентификации или после.
2. Проверьте reverse DNS на сервере: getent hosts <client_ip>. Если медленно — чините резолвер и ставьте UseDNS no.
3. Проверьте GSSAPI: разово ssh -o GSSAPIAuthentication=no. Если помогло — отключайте GSSAPIAuthentication на сервере (если SSO не нужно).
4. Проверьте PAM как гипотезу (временный тест UsePAM no), затем точечно устраняйте конкретный модуль/интеграцию.
5. Проверьте профили shell: временно уберите тяжёлые действия из .bashrc/.profile или протестируйте с «чистым» пользователем.

Минимальный «быстрый» фрагмент sshd_config для типового интернет-сервера

Если у вас нет Kerberos/SSO и вам не нужно определять имя клиента через PTR, то чаще всего достаточно отключить две опции:

UseDNS no
GSSAPIAuthentication no

После правок:

sudo sshd -t

sudo systemctl reload sshd

Если не помогло: куда копать дальше

Если UseDNS и GSSAPIAuthentication отключены, а вход всё равно «думает», чаще всего проблема не в SSH как таковом. Реальные направления для проверки:

• Резолвинг на сервере: неверные DNS в /etc/resolv.conf, проблемы systemd-resolved, таймауты до апстрим-резолверов.
• nsswitch.conf: порядок files/dns/sss/ldap влияет на скорость любых lookups.
• Домашние директории на NFS/SMB: таймауты сети или зависшие монтирования тормозят старт сессии.
• Нагрузка: высокий iowait и проблемы диска могут проявляться как пауза после аутентификации (загрузка окружения, чтение профилей).

Если сервер доступен из интернета и вы планируете размещать несколько проектов, иногда проще вынести SSH и сервисы на отдельный VDS с предсказуемыми DNS и сетевой инфраструктурой, чем бороться с «плавающими» задержками из-за внешних зависимостей.

Короткий итог

Если вы видите «ssh hangs on login», то в большинстве случаев причина одна из трёх:

• reverse DNS и включённый UseDNS (часто решается UseDNS no и настройкой резолвера);
• GSSAPI без рабочей Kerberos-инфраструктуры (решается GSSAPIAuthentication no или отключением на клиенте);
• PAM/NSS задержки из-за LDAP/SSSD/модулей/сетевых ресурсов (лечится поиском конкретного узкого места, а не отключением всего слоя).

Начинайте с ssh -vvv, подтверждайте гипотезы точечными переключателями и только затем фиксируйте изменения в sshd_config и PAM — так вы ускорите вход без сюрпризов для доступа и политик безопасности.