Недавно нам пришлось перестроить один из наших облачных серверов (мы используем Rackspace). Все серверы практически идентичны, использовался снимок другого сервера. Когда я снова заработал, я разрешил запустить задание cron, которое синхронизирует пару файлов вне системы управления версиями с исходного сервера на только что восстановленный сервер с помощью Unison. По сути, этот SSH и сравнивает файлы между двумя, а затем копирует / удаляет / любые файлы между двумя машинами.
Однако после перестройки я получаю электронные письма от Cron Daemon со следующей ошибкой:
ssh_exchange_identification: read: Connection reset by peer Fatal error: Lost connection with the server
Странно то, что если я вхожу в систему как тот же пользователь, под которым выполняется задание cron, и по SSH на тот же сервер (используя те же ключи для аутентификации), я не вижу никаких ошибок. Кроме того, если я запускаю Unison вручную из командной строки, я не вижу ошибок. Более того, если я отключу беззвучный режим Unison, то результат успешного пакетного задания Unison будет показан в консоли, и тот же результат будет показан в электронном письме, но я все равно получаю несколько других с ошибками, как указано выше, всякий раз, когда задание cron бежит.
Я проверил разрешения и содержимое ключей id_rsa / id_rsa.pub, authorized_keys и т. Д., И они кажутся нормальными.
Кто-нибудь может предположить, почему это могло внезапно начаться? Похоже, синхронизация работает, но я получаю несколько писем каждый раз, когда она запускается с этой ошибкой.
«Сброс соединения одноранговым узлом» означает, что удаленный конец - в данном случае SSH-сервер - закрыл TCP-поток ненормально. Это может произойти в случае сбоя удаленного процесса.
«ssh_exchange_identification» означает, что сервер и клиент обменивались строками баннера, которые идентифицируют программное обеспечение SSH на каждом конце соединения. Клиент ждал, пока сервер отправит строку своего баннера, когда TCP-соединение закрылось.
Вам действительно нужно устранить это на сервере, если вы можете. Попробуйте найти способ воспроизвести проблему. Затем на сервере и при условии, что на сервере запущен openssh, вы можете запустить:
/path/to/sshd -d -p 1022
Это запустит отладочную копию sshd, прослушивающую порт 1022. Он примет одно соединение от клиента и распечатает отладочные данные. Если вы можете воспроизвести проблему при подключении к этому экземпляру sshd, сообщения отладки должны прояснить, что происходит.