ssh_exchange_identification: read: Conexão redefinida pelo par

107

Estou no OS X tentando ssh em um servidor ubuntu 12.04. Consegui fazer o SSH - até que de repente as coisas pararam de funcionar. Eu li online para usar o -vpara depurar isso. A saída é mostrada abaixo. Se eu colocar o ssh em uma caixa diferente e, em seguida, o ssh dessa caixa para o servidor, eu consigo entrar. 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 (seguindo os conselhos dos fóruns), procurei um arquivo de negação de hosts - mas esse arquivo não existe 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 cliente, mas não no servidor.

ssh

— bernie2436
fonte

Eu recomendaria iniciar uma sshdescuta em uma porta alternativa, com saída detalhada e fornecer a saída ao tentar conectar-se a ela. $(which sshd) -d -p 23. Se você não tem a capacidade de fazer isso, suas opções são bastante limitadas. A melhor aposta é conseguir alguém que tenha direitos de administrador no servidor.

— Patrick

Será que o administrador do servidor restringiu seu acesso por algum motivo? De qualquer forma, posso entrar em contato com essa pessoa.

— Mdpc

12

Os arquivos hosts.deny e hosts.allow devem ser verificados no servidor , não no cliente. Além disso, os logs do sistema no servidor devem ser verificados. Se você também não tem acesso a eles, entre em contato com o administrador do servidor para dar uma olhada.

— Ckujau

você encontrou uma solução para isso? qual era o problema?

— MeV

2

Era uma lista hosts.deny preenchida pelo administrador com um script automático. Como esqueci minha senha em algum momento, tive algumas tentativas malsucedidas de fazer login, que é quando meu IP foi colocado na lista hosts.deny. É o suficiente para a produtividade da segurança excessivamente zelosa.

— K.-Michael Aye

25

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

Seu log indica apenas a cadeia de caracteres da versão local; você deve verificar as versões de sshdexecuçã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 já aconteceu antes em ssh. A solução costumava ser diminuir as entradas Ciphers, HostKeyAlgorithms e / ou MACs, na linha de comando ( ssh -c aes256-ctr, etc.) ou na sua /etc/ssh/ssh_config.

Você deve procurar nas informações de depuração (da conexão através do intermediário ao servidor) os valores apropriados como argumento para os comandos -c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithmse -m/ / MACsresp. ssh_config muda.

Não tenho esse problema há algum tempo, mas o IIRC, quando o fiz, foi o suficiente para forçar manualmente as configurações de Ciphers e HostKeyAlgorithms, após o qual eu poderia atualizar a sshdversão do servidor e o problema desapareceu.

— Anthon
fonte

3

No meu caso, o sshdpacote do servidor foi atualizado para uma versão mais recente e resultou na incompatibilidade com a minha sshconfiguração atual do cliente, como você disse. Limpar meus ssharquivos de configuração antigos fez o truque. Essa deve ser a resposta aceita.

— chakrit

2

@chakrit, como você limpou seus arquivos de configuração ssh antigos?

— Jonathan

@ Jonathan Montei um disco de recuperação para fazer isso.

— precisa saber é

16

Você pode ter sido banido por fail2banou denyhosts. Nesse caso (e também para verificá-lo), se você não quiser se preocupar com a assistência do provedor do servidor, precisará fazer login no servidor a partir de outro endereço IP: por exemplo, outro servidor ou a conexão doméstica de um amigo ou um ponto de acesso wifi ou usando SSH com TOR.

Uma vez logado, verifique se o seu endereço IP realmente aparece /etc/hosts.deny(no lado do servidor). Se sim, então fail2banou denyhostsdeve ser o culpado de fato.

Consulte as respostas a esta pergunta para obter o procedimento para impedir o denyhostsbloqueio contínuo do seu endereço. Para fail2banencontrar o seu ip com iptables -L --line-numbere sem o ip com iptables -D <chain> <chain number>, verifique os detalhes em howtoforge .

Você pode adicionar seu endereço IP fail2bane denyhostslistas de permissões (respectivamente /etc/fail2ban/jail.conf, linha ignoreipe /var/lib/denyhosts/allowed-hosts, se necessário, criá-lo (mas lembre-se de que o caminho pode ser diferente na sua distribuição)) para evitar que o problema ocorra novamente.

— Skippy le Grand Gourou
fonte

9

No servidor host, remova o ssh pub.key localizado aqui: ~/.ssh/authorized_keyspara o seu mac. Então, tail -f /var/log/auth.logenquanto você abre outro terminal e tenta ssh novamente ssh -v me@server. Se você for solicitado uma senha, houve um problema com sua chave ssh. Se você ainda estiver vendo a resposta 'ssh_exchange_identification: read: Connection reset by peer', poderá identificar qual é o problema da entrada de log no arquivo '/var/log/auth.log' após uma falha na tentativa Entrar.

Se você ainda não conseguiu se conectar, poste a entrada registrada no arquivo de autenticação aqui e revisarei minha resposta.

— devnull
fonte

Não há necessidade de excluir a chave SSH em alguns casos. Vá direto para tail -f /var/log/auth.log e verifique as tentativas recentes.

— Jack Robson

6

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).

— elCapitano
fonte

4

Eu estava conseguindo isso devido aos servidores de nomes do meu ISP /etc/resolv.conf. Esses servidores de nomes geralmente estão sobrecarregados e, se a pesquisa reversa do DNS falhar sshd, a conexão será interrompida. Resolvi o problema usando servidores de nomes mais confiáveis, por exemplo 8.8.8.8.

— njahnke
fonte

4

Eu fui confrontado com o mesmo problema. Eu abriria a sessão ssh com êxito, mas ela seria redefinida após algum tempo. Quando tentei conectar o ganho imediatamente, recebia o erro "Conexão recusada". quando depurei a sessão, recebi esta mensagem no momento em que a conexão estava sendo redefinida

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com 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

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

— David
fonte

2

Votos negativos, o que há de errado com a resposta? Ainda pode ser um caso válido para verificar ao descer uma lista, talvez não seja um caso comum entre outros.

— Pysis 24/09/16

@Pysis: resposta correta e votada #

— Daniel

3

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ê quase sempre deve poder encontrar registros em / var / log / messages

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

— gena2x
fonte

3

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

Nas versões mais recentes do ssherro fornecido é Connection refusedou Bad port.

Nas versões anteriores, o erro fornecido é ssh_exchange_identification: read: Connection reset by peer

Portanto, quando você receber esse erro, verifique se a porta está correta.

— Mugoma J. Okomba
fonte

1

Sei que essa pergunta é antiga, mas queria compartilhar algumas descobertas que tive. Verifique se /var/empty/sshdno 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, atualizamos 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.

— Andrew Boerema
fonte

1

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

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

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

— Jeff Schaller
fonte