SSH «Connection reset by peer»: соединение сброшено удалённой стороной

Фраза «Connection reset by peer» пришла из сетевого стека операционной системы, а не из самого SSH. Она означает, что с другой стороны пришёл TCP-сегмент с флагом RST, то есть соединение оборвано принудительно, без вежливого завершения. Обычно вы видите это либо сразу при попытке входа, либо на этапе обмена ключами, либо в середине уже открытой сессии.

Ключевое отличие от «Connection refused»: там порт закрыт и о нём честно сообщили сразу, а здесь соединение установилось или начало устанавливаться, и уже потом было сброшено. Значит, до сервера или до устройства на пути пакеты доходят. Это сужает поиск: проблема не в том, что адрес недоступен, а в том, кто и почему решил разорвать разговор.

Сбросить соединение способен сам SSH-сервер: сработали ограничения на число неавторизованных подключений, лимиты на запросы с одного адреса, правила защиты от перебора паролей вроде fail2ban или собственные ограничения демона. Такой сброс часто выглядит как случайный и зависит от частоты попыток.

Второй вариант: межсетевой экран сервера или облачная группа безопасности, которая пропускает первые пакеты, но затем разрывает сессию по правилам состояния. Третий: оборудование на пути, например корпоративный шлюз, роутер с агрессивным контролем соединений или система инспекции трафика провайдера, которая реагирует на определённые признаки протокола. Четвёртый: обрыв из-за сбоя самого сервера, например нехватки памяти или падения демона sshd в момент подключения.

Начните с простого: подключитесь из другой сети, например с телефона в режиме точки доступа. Если там всё работает, причина в вашей локальной сети или у провайдера, а не на сервере. Затем запустите клиент с ключом -v или -vvv: подробный вывод покажет, на каком этапе произошёл сброс, до обмена версиями, во время согласования алгоритмов или уже при аутентификации.

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

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

Проблемы с параметрами сессии иногда лечатся настройкой на сервере. Директивы вроде MaxStartups и MaxSessions в конфигурации sshd задают, сколько параллельных подключений и сессий допустимо. При нестабильной сети помогает включить периодические keepalive-пакеты на клиенте. Если проблема воспроизводится только в определённой сети, единственный разумный путь: сообщить администратору этой сети и на время работать из другой.

Явные признаки серверной причины: ошибка возникает у всех пользователей и из любых сетей, на самом сервере в журнале видны падения или перезапуски sshd, а нагрузка или память на пределе. Стоит проверить и последние изменения: обновление пакетов, правка конфигурации, включение новых правил защиты.

Если доступа к консоли нет, а сервер арендован, напишите в поддержку хостинга с указанием времени ошибок и вашего IP-адреса. Это позволит им сопоставить события в журналах. Иногда причиной оказывается сама сеть хостинга, и тогда до восстановления остаётся только ждать.

Иногда сброс происходит не при входе, а во время работы: например, при передаче большого файла или выводе крупного отчёта. Тогда стоит вспомнить о размере пакетов и о том, как устроен путь: на некоторых каналах пакеты крупного размера теряются, а короткие проходят, из-за чего интерактивная сессия работает, а копирование обрывается. Проверьте, воспроизводится ли ошибка на файлах разного размера.

Обратите внимание и на дополнительные слои: подключение через промежуточный узел (jump host) или с перенаправлением портов. Каждый из них может сам сбросить соединение, и ошибка будет относиться не к целевому серверу. Попробуйте подключиться к целевому узлу напрямую, если такая возможность есть, и сравните поведение. Если ошибка исчезает, виновата промежуточная часть цепочки, и разбираться нужно с ней.