#Что происходит и когда это важно
В журнале сервера есть сообщения о закрытии до аутентификации с адресом клиента и портом; часть подключений при этом работает нормально.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Автоматический сканерБот проверяет открытый порт и отключается, не предъявляя ключ. | Много кратких подключений с разных адресов. | Сопоставить частоту и защиту сервера, не блокировать случайно пользователей. |
| Сетевой разрыв клиентаКлиент или прокси закрыл соединение на этапе рукопожатия. | Совпадает с нестабильной сетью/сном ноутбука. | Проверить клиентский ssh -v и связь. |
| Несовместимость версий или алгоритмовКлиент прерывает подключение после начального обмена. | В подробном журнале есть ошибки KEX/host key. | Сверить версии и требуемые алгоритмы. |
| Лимиты до аутентификацииMaxStartups или защитные ограничения отсекают подключения. | В журнале есть drops/throttling при большом числе соединений. | Изучить значения и нагрузку, не отключая лимиты. |
#Пошаговая диагностика и исправление
- Уточните частоту и адрес источникаОткройте серверную консоль. Посмотрите, это единичная запись или множество событий. Не публикуйте публично IP-адреса пользователей и соответствующие временные метки. Отдельно отметьте, совпадает ли строка с моментом неуспешного входа конкретного разрешённого пользователя.
- Получите журнал только SSH-сервераНа Debian/Ubuntu администратор выполняет
sudo journalctl -u ssh -b -n 150 --no-pager, на других системах частоsudo journalctl -u sshd -b -n 150 --no-pager. Сравните время строки с жалобами реальных пользователей. Единичная запись без симптомов не требует ремонта. - Проверьте службу и активные соединенияВыполните
systemctl status ssh --no-pagerилиsystemctl status sshd --no-pagerпо фактическому имени. Затемss -tn sport = :22при штатном порте 22: вывод показывает TCP-соединения на локальном SSH-порту; если настроен другой порт, замените номер. Команда ничего не блокирует. - Попросите проблемного клиента включить диагностикуНа клиенте выполните
ssh -v пользователь@серверс настоящими данными. Сопоставьте этап обрыва и время на двух системах. Не просите присылать закрытые ключи, а из вывода удалите имена/адреса перед публичным размещением. - Различите нормальные боты и лимитыЕсли подключение рабочих пользователей не нарушено, убедитесь, что действуют стандартные политики sshd, обновления безопасности и сетевые правила. Если есть MaxStartups/PerSourcePenalties, их значения проверяет администратор по конфигурации и журналу; не выключайте ограничения из-за одиночной строки.
- Исследуйте именно подтверждённую проблемуЕсли реальные пользователи постоянно теряют соединение, проверьте DNS/маршруты, алгоритмы SSH, ProxyJump и лимиты до аутентификации по отдельности. Не меняйте сразу все параметры и не делайте массовую блокировку подсетей.
- Повторно проверьте штатный доступИз доверенной сети выполните тестовый SSH-вход и завершите его
exit. Убедитесь, что нормальный клиент проходит аутентификацию, а число неожиданных обрывов не растёт. Если тест не проходит, не изменяйте настройки защиты вслепую; сначала найдите точную причину в журнале.
#Команды из инструкции с пояснениями
Linux · Терминал (Bash)КомандаНужен sudo
Сервер Debian/Ubuntu: последние строки SSH; требует администратора.
sudo journalctl -u ssh -b -n 150 --no-pagerLinux · Терминал (Bash)Команда
Состояние сервера OpenSSH на Debian/Ubuntu.
systemctl status ssh --no-pagerLinux · Терминал (Bash)Команда
Просмотр TCP-соединений к локальному порту 22; измените порт при необходимости.
ss -tn sport = :22#Как проверить результат
Легитимные SSH-сеансы проходят успешно; одиночные подключения, закрытые до аутентификации, трактуются по частоте, источнику и сопутствующим ошибкам.
#Если проблема не устранена
Если массовые отказы совпадают с активностью настоящих пользователей, сохраните небольшую обезличенную выборку журнала, версии OpenSSH, правила MaxStartups и передайте администратору.