Estou me conectando a um servidor remoto por meio do meu Mac há cerca de um mês. Recentemente, tentei me conectar usando ssh dylan@MY_IP e recebi esta mensagem.
ssh_exchange_identification: read: Connection reset by peer
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 ...
- Reiniciei meu roteador
- Limpei meu arquivo "known_hosts"
- Excluí meu arquivo “known_hosts”
- Liberado e renovado meu DHCP
- Também tentei de outro dispositivo (Windows) usando Putty com erro também
Observe que não fiz nenhuma alteração no servidor para inibir essa comunicação.
Além disso, não tenho certeza se isso causaria problemas, mas me conectei a ele pelo nome de domínio e também pelo IP.
Além disso, consegui me conectar com êxito a partir de outro endereço IP.
Eu sei que este é um grande problema com muitos recursos disponíveis, mas muitas soluções não funcionaram e eu realmente não vi nenhum tipo de solução para ninguém.
Atualizar
Forcei-o para o protocolo 1. Em vez de "Conexão redefinida por peer", agora recebo "Conexão fechada por host remoto". Executá-lo 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
Responder1
Foi assim que resolvi o erro "ssh_exchange_identification: Conexão fechada por host remoto" ao conectar-me a um servidor SSH.
Recebi este erro ao tentar conectar-me a uma máquina Linux embarcada, após descompactar um pacote para fazer root. Muitos arquivos de biblioteca foram substituídos, incluindo libssl.
Tentando se conectar:
chetic@ubuntu:~$ ssh -v [email protected]
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
Pesquisar no Google apenas parecia sugerir 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 funcionando. Tentei iniciar manualmente o sshd no destino:
# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f
Substituí /usr/lib/libssl.a pela versão original e iniciei o sshd e as coisas voltaram ao normal. O problema, no meu caso, foi causado por uma versão incorreta no pacote que descompactei originalmente para fazer root.
Responder2
Eu estava recebendo o mesmo erro (mas de qualquer máquina, incluindo a máquina problemática via ssh localhost).
Tudo começou quando migrei um perfil de usuário; ou seja, depois de copiar os arquivos como root, executei comandos comochown -R username /Users/username/Destop
de qualquer forma, não tenho certeza por que /var/empty proprietário foi alterado para nome de usuário, mas sshdefinitivamente precisa /var/emptypertencer ao root (caso contrário, você obterá ssh_exchange_identification: read: Connection reset by peer):
sudo chown root /var/empty
Responder3
Este não é um problema da sua máquina local, mas um problema do lado do servidor. Poderia sermúltiplos fatorescausando este problema:
- Mudanças na configuração /etc/hosts.allow ou /etc/hosts.deny no servidor remoto.
- Carga pesada do servidor.
No passado, quando tive esses problemas, fiz uma de duas coisas, na seguinte ordem:
- Modifique o /etc/hosts.allow conforme mencionado no artigo acima. (e reinicie o servidor SSH)
- Se /etc/hosts.allow já estiver do jeito que deveria ser, basta reiniciar o servidor SSH (e tenha cuidado ao fazer isso!)
- Se a reinicialização não funcionar, gere novamente as chaves do servidor e reinicie o servidor SSH (isso é arriscado, pois cada usuário que fizer login nesta máquina receberá um erro sobre o servidor ter as chaves alteradas)
Na maioria das vezes, 1 resolve o problema, mas tive que fazer 2 em alguns casos.por queesse é o caso, só que funcionou. Talvez tenha algo a ver com a forma como a chave é apresentada, ou talvez ela tenha sido corrompida de alguma forma - não tenho certeza. Mas o que eu sei é que o erro tem algo a ver com o servidor e com a maneira como o handshake acontece quando a conexão SSH está sendo configurada.
Responder4
Certamente é um bug, o ssh funciona com uma das minhas máquinas, mas não com a outra. Eu resolvi isso, siga estes.
- Gere um token de acesso sem data de expiração e selecione todas as opções disponíveis.
- Remova as chaves SSH existentes.
- Clone o repositório com https em vez de ssh.
- Use o nome de usuário, mas use o token de acesso gerado em vez da senha.
alternativamente, você pode definir remoto como http usando este comando no repositório existente e usar este comando git remote set-url originhttps://gitlab.com/[nome de usuário]/[nome do repositório].git