Após a reconstrução do servidor em nuvem, por que o SSH me fornece um erro ssh_exchange_identification?

Question

Recentemente, tivemos que reconstruir um dos nossos servidores em nuvem (usamos o Rackspace). Todos os servidores são quase idênticos e um instantâneo de outro servidor foi usado. Uma vez ativo novamente, permiti que uma tarefa do cron fosse executada, sincronizando alguns arquivos fora do controle de origem do servidor original para o servidor recém-reconstruído, usando o Unison. Essencialmente, este SSH e compara arquivos entre os dois, em seguida, copia / exclui / qualquer arquivo entre as duas máquinas.

No entanto, desde a reconstrução, estou recebendo e-mails do Cron Daemon, causando o seguinte erro:

ssh_exchange_identification: read: Connection reset by peer Fatal error: Lost connection with the server

O mais estranho aqui é que, se eu fizer login como o mesmo usuário em que a tarefa cron é executada e o SSH no mesmo servidor (usando as mesmas chaves para auth), não vejo nenhum erro. Além disso, se eu executar o Unison manualmente a partir da linha de comando, não vejo erros. Além disso, se eu desativar o modo silencioso do Unison, a saída de um trabalho em lotes uníssono bem-sucedido é mostrada no console, e essa mesma saída é mostrada em um email, mas ainda recebo vários outros com os erros acima, sempre que o cron job corre.

Eu verifiquei as permissões e o conteúdo das chaves id_rsa / id_rsa.pub, authorized_keys, etc, e elas parecem boas.

Alguém pode sugerir por que isso de repente começou a acontecer? Parece que a sincronização está funcionando, mas estou recebendo vários e-mails toda vez que ele é executado com esse erro.

    

Answer 1

"Conexão redefinida por peer" significa que a extremidade remota - o servidor SSH, neste caso - fechou o fluxo TCP de forma anormal. Uma maneira que pode acontecer é se o processo remoto falhar.

"ssh_exchange_identification" significa que o servidor e o cliente estavam trocando cadeias de caracteres que identificam o software SSH em cada extremidade da conexão. O cliente estava esperando o servidor enviar sua sequência de banner quando a conexão TCP foi fechada.

Você realmente precisa solucionar isso no servidor, se puder. Tente encontrar uma maneira de reproduzir o problema. Então, no servidor, e assumindo que o servidor está executando o openssh, você pode executar:

/path/to/sshd -d -p 1022

Isso inicia uma cópia de depuração do sshd escutando na porta 1022. Ela aceitará uma única conexão de um cliente e imprimirá a saída de depuração. Se você puder reproduzir o problema durante a conexão a essa instância do sshd, as mensagens de depuração deverão deixar bem claro o que está acontecendo.