Conexão SSH: ssh_exchange_identifcation

Estou conectando a um servidor remoto através do meu Mac há cerca de um mês. No entanto, recentemente, tentei conectar usando ssh dylan @ MY_IP e recebi esta mensagem.

ssh_exchange_identification: read: Connection reset by peer

Eu também recebi algumas informações de diagnóstico ...

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

Depois de fazer algumas pesquisas, tentei o seguinte ...

1. Reiniciei meu roteador
2. Limpei meu arquivo "known_hosts"
3. Excluiu meu arquivo "known_hosts"
4. Lançado e renovado meu DHCP
5. Também tentei de outro dispositivo (Windows) usando o Putty com um erro também

Observe que não fiz alterações no servidor para inibir esta comunicação.

Além disso, não tenho certeza se isso causaria problemas, mas eu me conectei a ele pelo nome de domínio e pelo IP.

Além disso, consegui me conectar com sucesso de outro endereço IP.

Sei que esse é um grande problema com muitos recursos por aí, mas muitas das soluções não funcionaram nem vi nenhum tipo de resolução para ninguém.

Atualizar

Eu forcei o protocolo 1. Em vez de "Conexão redefinida pelo par", agora recebo "Conexão fechada pelo host remoto". Executando-o com informações de depuração reveladas:

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host

Foi assim que resolvi o erro "ssh_exchange_identification: Connection closed by remote host" ao conectar-me a um servidor SSH.

Eu recebi esse erro ao tentar conectar-me a uma máquina Linux incorporada, depois de descompactar um pacote para fazer o root. Muitos arquivos da biblioteca foram substituídos, incluindo o libssl.

Tentando se conectar:

chetic@ubuntu:~$ ssh -v root@192.168.1.100
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

O Google parecia sugerir apenas a verificação de hosts.deny e hosts.allow, mas minha máquina de destino não tinha esses arquivos.

Após uma reinicialização (conforme sugestão de Karthik), o sshd não estava em execução. Eu tentei iniciar manualmente o sshd no destino:

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

Substituí o /usr/lib/libssl.a pela versão original e iniciei o sshd e as coisas voltaram ao normal. O problema foi causado no meu caso por uma versão incorreta no pacote que originalmente descompactei na raiz.

Eu estava recebendo o mesmo erro (mas de qualquer máquina, incluindo a máquina problemática via ssh localhost).

Tudo começou quando eu migrei um perfil de usuário; ou seja, depois de copiar os arquivos como root, então comandos comochown -R username /Users/username/Destop

de qualquer maneira, totalmente inseguro por que / var / empty owner foi alterado para nome de usuário, mas sshdefinitivamente precisa /var/emptypertencer ao root (caso contrário, você obtém ssh_exchange_identification: read: Connection reset by peer):

    sudo chown root /var/empty

Isso não é um problema com sua máquina local, mas um problema no lado do servidor. Pode haver vários fatores que causam esse problema:

1. Alterações na configuração /etc/hosts.allow ou /etc/hosts.deny no servidor remoto.
2. Carga pesada do servidor.

No passado, quando tive esses problemas, fiz uma de duas coisas, na seguinte ordem:

1. Modifique o /etc/hosts.allow conforme mencionado no artigo acima. (e reinicie o servidor SSH)
2. Se o /etc/hosts.allow já é o necessário, basta reiniciar o servidor SSH (tenha cuidado ao fazer isso!)
3. Se a reinicialização não funcionar, gere novamente as chaves do servidor e reinicie o servidor SSH (isso é arriscado, pois todos os usuários que efetuam login nesta máquina receberão um erro sobre a alteração das chaves no servidor)

Frequentemente, eu resolvo o problema, mas tive que fazer 2 em alguns casos. Não consegui descobrir por que esse é o caso, apenas que funcionou. Talvez tenha algo a ver com a forma como a chave é apresentada, ou talvez tenha sido corrompida de alguma forma - não tenho certeza. Mas o que sei é que o erro tem algo a ver com o servidor e a maneira como o handshake acontece quando a conexão SSH está sendo configurada.

Eu tinha o SSH configurado com o Cygwin e, no meu caso, foi o firewall do Windows que causou exatamente esse erro, portanto, permita conexões na porta 22.

Consegui resolver esse problema pessoalmente com muita facilidade.

No OS X normal, você pode resolver isso simplesmente alternando "Login Remoto" em Preferências do Sistema / Compartilhamento.

No entanto, se for um servidor sem cabeça (como no meu caso), você pode usar o aplicativo OSX Server para acessar (nome do servidor) / Configurações e alternar "Conexões seguras do shell ativadas e desativadas"

Se você estiver usando uma chave privada ou de segurança para efetuar login no servidor, precisará alterar a permissão do arquivo de chave para 660, usando o comando

sudo chmod 660 Nome_do_Arquivo