Почему после перестроения облачного сервера SSH выдает ошибку ssh_exchange_identification?
Недавно нам пришлось перестраивать один из наших облачных серверов (мы используем 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, авторизованные ключи и т. Д., И они выглядят нормально.
Кто-нибудь может подсказать, почему это могло вдруг начаться? Кажется, синхронизация работает, но я получаю несколько писем каждый раз, когда запускается с этой ошибкой.
1 ответ
"Сброс соединения по одноранговой сети" означает, что удаленный конец - в данном случае сервер SSH - ненормально закрыл поток TCP. Это может произойти в случае сбоя удаленного процесса.
"ssh_exchange_identification" означает, что сервер и клиент обменивались строками баннеров, которые идентифицируют программное обеспечение SSH на каждом конце соединения. Клиент ждал, пока сервер отправит свою строку баннера, когда TCP-соединение закрыто.
Вам действительно нужно устранить неполадки на сервере, если вы можете. Попробуйте найти способ воспроизвести проблему. Затем на сервере, и, предполагая, что на сервере работает openssh, вы можете выполнить:
/path/to/sshd -d -p 1022
Это запускает отладочную копию прослушивания sshd на порту 1022. Он примет одно соединение с клиентом и напечатает выходные данные отладки. Если вы можете воспроизвести проблему при подключении к этому экземпляру sshd, сообщения отладки должны прояснить, что происходит.