Debian/Ubuntu: SSH зависает на Connecting to — как найти и убрать задержку входа

Ситуация знакомая: вы запускаете ssh user@server, видите строку Connecting to ..., а дальше всё будто зависает. Или TCP-соединение устанавливается быстро, но перед запросом пароля проходит 5–20 секунд. Бывает и третий сценарий: аутентификация уже успешна, а shell появляется с заметной паузой.

На Debian и Ubuntu это почти всегда решаемая история. Важно только не править sshd_config вслепую, а сначала понять, на каком именно этапе возникает задержка: до TCP-connect, во время обмена баннером, на аутентификации, в DNS-проверках, в PAM или уже после логина.

Ниже — практическая схема диагностики, которая помогает в большинстве реальных случаев: от медленного reverse DNS и лишнего GSSAPIAuthentication до проблемных скриптов в /etc/update-motd.d/ и тяжёлого ~/.bashrc.

Сначала определяем, где именно зависает SSH

Главный инструмент на клиенте — подробный вывод OpenSSH:

ssh -vvv user@server

Если у вас нестандартный порт, укажите его явно:

ssh -vvv -p 2222 user@server

Смотреть нужно не на весь поток строк, а на место, после которого начинается пауза. Обычно встречаются такие варианты:

• задержка до успешного TCP-подключения — ищем проблему в сети, маршруте, DNS клиента, MTU или firewall;
• задержка после Connecting to, но до нормального обмена ключами — возможны фильтрация трафика, нестабильный маршрут или сетевой middlebox;
• задержка перед запросом пароля — частые кандидаты: UseDNS и GSSAPIAuthentication;
• задержка сразу после успешной аутентификации — почти всегда проверяем PAM, MOTD и shell startup.

Не меняйте сразу несколько параметров. Если одновременно отключить PAM, DNS-проверки и GSSAPI, вы не поймёте, что именно дало эффект. Меняйте по одному пункту и каждый раз перепроверяйте результат.

Что означает зависание на Connecting to

Строка Connecting to не гарантирует, что проблема именно в сервере SSH. На этом этапе клиент ещё только устанавливает соединение с адресом и портом, поэтому сначала исключаем базовые вещи:

getent hosts server
ping -c 1 server
ssh -vvv user@server
nc -vz server 22

Если имя хоста резолвится медленно, проблема может быть на стороне клиента: сломанный DNS, VPN, неудачный маршрут к DNS-серверу или подвисающий IPv6. Особенно часто это проявляется на ноутбуках и в корпоративных сетях.

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

ssh -vvv user@203.0.113.10
ssh -vvv user@server.example

Если по IP всё быстро, а по имени медленно, серверный sshd трогать рано: сначала разбирайтесь с клиентским DNS или зависимостями от имени хоста.

Для стабильной диагностики и предсказуемого поведения SSH особенно удобен отдельный VDS, где вы контролируете и сетевую часть, и конфигурацию демона, и PAM-цепочку.

Классическая причина: reverse DNS и UseDNS

Один из самых частых источников задержек — обратное DNS-разрешение IP клиента на сервере. Когда вы подключаетесь к sshd, сервер может пытаться определить имя клиента через PTR-запись. Если reverse DNS отвечает медленно или настроен некорректно, логин начинает подвисать.

Сначала проверьте, как параметр задан в конфигурации:

sudo grep -i usedns /etc/ssh/sshd_config /etc/ssh/sshd_config.d/* 2>/dev/null
sudo sshd -T | grep usedns

Если в эффективной конфигурации видно usedns yes, попробуйте явно отключить эту проверку:

sudoedit /etc/ssh/sshd_config

UseDNS no

sudo sshd -t
sudo systemctl reload ssh

На Debian и Ubuntu имя systemd-сервиса обычно ssh. Это мелочь, но именно на ней часто теряют время.

После изменения стоит дополнительно проверить, как сервер вообще видит IP клиента и есть ли задержка в DNS:

host 198.51.100.25
getent hosts 198.51.100.25
journalctl -u ssh -b --no-pager

Если задержка исчезла после UseDNS no, диагноз почти наверняка подтверждён.

Здесь же полезно не ограничиваться одной правкой: посмотрите, нет ли локальных особенностей resolver, проблем с PTR-записями или задержек на стороне корпоративного DNS. Иначе симптом уйдёт только частично.

Если вы часто поднимаете тестовые Linux-серверы и хотите быстро воспроизводить такие кейсы с сетью, DNS и SSH, удобнее делать это на отдельном VDS с полным доступом к системной конфигурации.

GSSAPIAuthentication: лишняя попытка, которая съедает секунды

Следующий типовой виновник — GSSAPIAuthentication. В инфраструктуре с Kerberos или Active Directory этот механизм полезен, но на обычных Linux-серверах он нередко только добавляет паузу перед нормальной аутентификацией.

Быстрый тест на клиенте выглядит так:

ssh -vvv -o GSSAPIAuthentication=no user@server

Если после этого подключение заметно ускорилось, можно закрепить настройку локально:

Host *
    GSSAPIAuthentication no

Либо отключить на сервере, если Kerberos у вас точно не используется:

sudoedit /etc/ssh/sshd_config

GSSAPIAuthentication no

sudo sshd -t
sudo systemctl reload ssh

Здесь важно помнить: задержка от GSSAPI иногда появляется только при подключении по имени, а не по IP, потому что в процессе участвуют DNS-запросы и построение сервисного principal.

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

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

Подробнее

Banner, PAM и MOTD: задержка уже после входа

Если SSH-аутентификация уже прошла, а терминал появляется с задержкой, ищите проблему не в транспортном уровне, а в post-login цепочке. На Debian и Ubuntu это чаще всего PAM, pam_motd, pam_lastlog и пользовательские startup-скрипты оболочки.

Сначала проверьте, не включён ли баннер и не тормозит ли он сам по себе:

sudo sshd -T | grep banner
ls -l /etc/issue.net
stat /etc/issue.net

Для теста баннер можно временно отключить:

sudoedit /etc/ssh/sshd_config

Banner none

sudo sshd -t
sudo systemctl reload ssh

Если пауза остаётся, переходите к PAM и MOTD. Часто именно скрипты в /etc/update-motd.d/ тянут сеть, пытаются проверять обновления или собирают статистику слишком долго.

ls -l /etc/update-motd.d/
ls -l /etc/pam.d/sshd

Быстрый тест — временно снять исполняемый бит со скриптов MOTD:

sudo chmod -x /etc/update-motd.d/*

После проверки не забудьте вернуть права нужным файлам или оставить только действительно полезные скрипты.

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

Как быстро отделить сетевую проблему от серверной

Чтобы не гадать, удобно сделать несколько коротких проверок.

Подключение по IP вместо имени

Если по IP быстро, а по FQDN медленно, почти наверняка виноваты DNS или GSSAPI-зависимости от имени хоста.

Отключение GSSAPI одной опцией

ssh -vvv -o GSSAPIAuthentication=no user@server

Если это помогает, проблема в GSSAPI или связанных с ним DNS/Kerberos-поисках.

Проверка без pseudo-TTY

ssh -T user@server true

Если команда выполняется быстро, а интерактивный вход тормозит, значит искать нужно в shell startup, MOTD или PAM.

Измерение чистого времени входа

time ssh -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -T user@server true

Так удобнее оценить скорость именно SSH-сессии без влияния интерактивной оболочки.

Что смотреть на сервере: логи и эффективную конфигурацию

На Debian и Ubuntu самые полезные команды для проверки такие:

sudo journalctl -u ssh -b --no-pager
sudo journalctl -u ssh -f
sudo sshd -T

Во время тестового входа держите второй терминал с journalctl -f. Нередко проблемный участок виден сразу: таймаут PAM-модуля, медленная DNS-проверка, ошибка чтения баннера или зависание на генерации MOTD.

Команда sshd -T особенно полезна на системах, где активно используются include-файлы в /etc/ssh/sshd_config.d/. Читать только основной конфиг недостаточно: фактические параметры могут отличаться.

В первую очередь проверьте значения usedns, gssapiauthentication, usepam, banner, printmotd и printlastlog.

Частый скрытый виновник: shell startup

Если вход по SSH формально успешен, а тормозит уже появление приглашения, обязательно проверьте пользовательские файлы инициализации:

sed -n '1,200p' ~/.profile
sed -n '1,200p' ~/.bashrc
sed -n '1,200p' ~/.bash_profile 2>/dev/null

Типичные проблемы — команды hostname -f, обращения к Docker, Git, Python, Kubernetes CLI, сокетам, DNS-именам или внешним API. Всё это легко превращает обычный вход в 10-секундное ожидание.

Если вы параллельно настраиваете веб-стек, полезно также держать в уме смежные причины задержек на сервере, например неудачные конфигурации процессов и пулов. По этой теме может пригодиться материал про несколько PHP-FPM пулов в Nginx, когда нужно разделить нагрузку и упростить диагностику.

Короткий рабочий чек-лист

1. Запустите ssh -vvv user@server и зафиксируйте место паузы.
2. Сравните подключение по IP и по имени.
3. Проверьте вариант с -o GSSAPIAuthentication=no.
4. Посмотрите эффективное значение UseDNS через sshd -T.
5. Откройте journalctl -u ssh -f и выполните тестовый вход.
6. Сравните интерактивную и неинтерактивную сессию через ssh -T user@server true.
7. Проверьте /etc/update-motd.d/, PAM и пользовательские startup-файлы.

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

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

Подробнее

В большинстве случаев проблема находится в одной из четырёх точек: reverse DNS, GSSAPI, MOTD/PAM или shell startup.

Итог

Когда в Debian или Ubuntu SSH зависает на Connecting to или долго пускает в shell, почти всегда помогает один и тот же подход: определить фазу задержки, проверить DNS, исключить GSSAPI, посмотреть PAM и post-login скрипты.

Главное — не лечить вслепую. Один запуск ssh -vvv, сравнение IP и FQDN, плюс проверка sshd -T и journalctl обычно дают больше пользы, чем серия случайных правок в конфиге.

И обязательно тестируйте изменения с уже открытой резервной SSH-сессией. Особенно если трогаете UsePAM, методы аутентификации или параметры входа. Это простая привычка, которая реально спасает доступ к серверу.