ssh_exchange_identification: read: Conexão redefinida pelo peer

Question

Eu estou no OS X tentando ssh em um servidor 12.04 do Ubuntu. Eu pude acessar o SSH - até que de repente as coisas pararam de funcionar. Eu li on-line para usar o -v para depurar isso. A saída é mostrada abaixo. Se eu ssh em uma caixa diferente e, em seguida, ssh da caixa para o servidor eu sou capaz de fazer o login. Eu não tenho idéia de como depurar esse problema, mas gostaria de aprender.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

Até agora (a conselho de fóruns), procurei por um arquivo hosts negar - mas não existe esse arquivo na minha máquina.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

Eu tenho acesso de administrador na máquina do cliente, mas não no servidor.

    

Answer 1

A mudança abrupta pode ser o resultado de uma mudança no arquivo de configuração nos servidores sshd configuration, mas você indica que não pode verificar ou alterar isso sem o direito admin. Você ainda pode tentar o seguinte se os administradores do servidor não puderem ser alcançados (no tempo).

Seu log indica apenas a string de versão local, você deve verificar as versões de sshd em execução no servidor e na máquina intermediária.

Se essas versões diferirem (especialmente entre a máquina local e o servidor e menos entre a máquina intermediária e o servidor) pode haver alguma incompatibilidade de negociação, isso aconteceu antes em ssh . A solução costumava ser encurtar as entradas das Cifras, HostKeyAlgorithms e / ou MACs, seja na linha de comando ( ssh -c aes256-ctr , etc.) ou no seu /etc/ssh/ssh_config .

Você deve procurar nas informações de depuração (da conexão por meio do intermediário ao servidor) os valores apropriados como argumento para -c / Ciphers , -o HostKeyAlgorithms / HostKeyAlgorithms e -m / MACs linha de comando resp. ssh_config muda.

Eu não tive esse problema por um tempo, mas o IIRC quando eu fiz isso foi o suficiente para forçar manualmente a configuração Ciphers e HostKeyAlgorithms, após o qual eu pude atualizar a versão sshd do servidor e o problema desapareceu.

    

Answer 2

Você pode ter sido banido por fail2ban ou denyhosts . Nesse caso (e também para verificar isso), se você não quiser se incomodar com a assistência do provedor do servidor, será necessário fazer login no servidor a partir de outro endereço IP: por exemplo, outro servidor, ou a conexão inicial de um amigo ou um hot spot de Wi-Fi ou o uso de SSH com TOR.

Uma vez logado, verifique se o seu endereço IP realmente aparece em /etc/hosts.deny (no lado do servidor). Se assim for, então fail2ban ou denyhosts deve ser o culpado de fato.

Veja as respostas a esta pergunta para o procedimento de impedir que denyhosts bloqueie sua endereço continuamente. Para fail2ban encontre seu ip com iptables -L --line-number e desbanque seu ip com iptables -D <chain> <chain number> , você confere detalhes em howtoforge .

Você pode adicionar seu endereço IP a fail2ban e denyhosts whitelists (respectivamente /etc/fail2ban/jail.conf , linha ignoreip e /var/lib/denyhosts/allowed-hosts , criá-lo se necessário (mas cuidado com o fato de que o caminho pode ser diferente em sua distribuição)) para evitar que o problema volte a acontecer.

    

Answer 3

No servidor host, remova o ssh pub.key localizado aqui: ~/.ssh/authorized_keys para o seu mac. Então tail -f /var/log/auth.log enquanto você abre outro terminal e tenta ssh novamente ssh -v me@server . Se você for solicitado para uma senha, então houve um problema com sua chave ssh. Se você ainda estiver vendo a resposta 'ssh_exchange_identification: read: Conexão redefinida por peer', deverá ser capaz de identificar qual é o problema da entrada de log no arquivo '/var/log/auth.log' após a tentativa falhada para fazer o login.

Se você ainda não conseguiu se conectar, poste a entrada registrada do arquivo auth aqui e eu revisarei minha resposta.

    

Answer 4

Isso pode acontecer se você tiver várias máquinas na rede com o mesmo endereço MAC (por exemplo, se você fizer uma cópia de uma máquina virtual e esquecer de alterar o MAC).

    

Answer 5

Eu estava recebendo isso devido aos servidores de nomes do meu ISP em /etc/resolv.conf . Esses servidores de nomes são geralmente sobrecarregados e, se a pesquisa inversa de DNS falhar, sshd interromperá a conexão. Eu resolvi o problema usando mais servidores de nomes confiáveis, por exemplo 8.8.8.8 .

    

Answer 6

Eu estava enfrentando o mesmo problema. Eu iria abrir a sessão ssh com sucesso, mas ela seria reiniciada depois de algum tempo. Quando eu tentei conectar ganho imediatamente eu iria receber o erro "Conexão recusada". quando depurei a sessão, recebi esta mensagem no momento em que a conexão estava sendo reinicializada

debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1  
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1  
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1                                                           

Neste momento, percebi que havia um conflito de endereço IP na rede. Mudei para outro endereço e o problema foi resolvido

    

Answer 7

Eu tive o mesmo problema, mas a causa foi diferente: eu estava usando a porta errada.

Nas versões mais recentes de ssh , o erro fornecido é Connection refused ou Bad port .

Em versões mais antigas, o erro fornecido é ssh_exchange_identification: read: Connection reset by peer

Então, quando você receber tal erro, verifique se a porta está correta.

    

Answer 8

Seu log significa que o lado do servidor descarta a conexão. Para descobrir o motivo, você deve consultar os logs do lado do servidor, eles devem mostrar o motivo da desconexão. Você deve ser quase sempre capaz de encontrar logs em / var / log / messages

Eu poderia adivinhar que, como a conexão caiu logo após o número da versão do cliente, o servidor de alguma forma ameaça o cliente como incompatível.

    

Answer 9

Eu sei que esta pergunta é antiga, mas queria compartilhar algumas descobertas que tive. Verifique se /var/empty/sshd no servidor possui propriedade e permissões apropriadas.

Tivemos um script de chef que foi modificado para atualizar algumas permissões de diretório, mas inadvertidamente atualizou o diretório abaixo do destino pretendido, alterando a propriedade de / var para um usuário / grupo de aplicativo e alterando as permissões para 775.

    

Answer 10

Como não foi mencionado explicitamente em uma Resposta, uma outra maneira de esse erro aparecer é se um firewall baseado em rede entre você e o servidor decidiu bloquear a conexão. O firewall poderia ter decidido que havia conexões "demais" do IP do sistema OS X e começou a bloqueá-lo. Ainda não havia conexões "demais" do outro sistema e, portanto, isso era permitido.

A última mensagem que você recebeu do servidor é aquela que ocorre antes mesmo de você iniciar qualquer tentativa de autenticação, o que exclui uma grande classe de possibilidades em torno de sua conta, chave ou senha.

Exemplos de tais políticas de força bruta de uma amostragem aleatória de fornecedores são:

• CloudFlare: Como eu uso Rate Limiting para proteger contra ataques de força bruta?
• F5: Configurando a proteção contra ataques de força bruta
• FortiNet: criando uma assinatura IPS personalizada para detectar uma taxa padrão - exemplo para detectar um ataque de força bruta
• Palo Alto: impedir ataques de força bruta
• Sonicwall: Como bloquear ataques de força bruta e de dicionário com SRA