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