Felizmente, o ssh_exchange_identification: read: Connection reset by peer error é bastante raro, mas você pode topar com ele se estiver tentando fazer o ssh em qualquer tipo de servidor Unix. Não importa se você está usando o Windows com cygwin para acessar o Ubuntu ou macOS com o terminal para ssh no Arch, Fedora ou CentOS. Como o ssh é universal em Unix e Linux, esse erro pode ocorrer a qualquer momento em que o servidor remoto redefine a conexão sem sua permissão.
Método 1: verifique o arquivo hosts.deny
Se você tiver privilégios administrativos no servidor e uma maneira de acessá-lo, a maneira mais fácil de resolver esse problema é acessar um prompt conectado diretamente no computador do servidor e dar uma olhada no arquivo hosts.deny.
Tipo 
no servidor para ver se sua máquina está listada como banida por qualquer motivo.
Se estiver, geralmente é um erro e você pode removê-lo com segurança e reconectar via ssh na outra máquina. Caso contrário, certifique-se de que não haja curingas estranhos que impeçam a conexão de sua máquina. Um arquivo novo com nada além do texto padrão adicionado pela distribuição do servidor não seria o culpado, no entanto, na maioria dos casos.
Experimentar 
se desejar adicionar manualmente seu login remoto para garantir que ele possa se conectar. Lembre-se de que isso raramente é necessário, mas se você adicioná-los, precisará seguir o texto informativo fornecido pela distribuição. Você adicionaria, por exemplo, uma linha na parte inferior que diz como ALL: appuals.com para permitir que todos em appuals.com se conectem ao servidor. Certifique-se de digitar seu host corretamente se fizer isso, pressione Ctrl + O para salvar o arquivo e Ctrl + X para sair.
Você deve conseguir fazer o ssh no servidor neste ponto.
Método 2: alterar as opções de configuração do ssh
Se você não conseguir acessar o servidor remoto ou o método anterior não corrigiu a opção, limpe seus arquivos de configuração ssh antigos e veja se isso resolve após uma atualização. Supondo que não, adicione a opção -v ao ssh e tente se conectar novamente. Se você ainda receber uma mensagem de erro, tente adicionar -c aes256-ctr ao seu comando ssh e veja se isso resolve. Isso deve encurtar a lista de cifras e permitir que você se conecte ao servidor para o qual estava tentando fazer o ssh, já que isso reduz o tamanho do pacote.
Alguns usuários notaram que isso é especialmente útil ao solucionar problemas de alguns tipos de equipamentos da marca Cisco porque algumas peças de hardware de servidor esperam tamanhos de pacote menores por padrão. Basta adicionar -c aes256-ctr ao seu comando ssh usual e você poderá entrar.
Método 3: Substituindo Banimentos de IP Acidentais
Se você tentou fazer login algumas vezes antes e foi negado, seu próprio servidor pode ter confundido você com um endereço IP incorreto. Isso geralmente acontece se você continuar tentando a conexão durante a solução de problemas, o que é uma resposta racional, mas pode parecer um ataque à sub-rotina fail2ban. Para ter certeza de que não é o caso, execute sudo iptables -L –line-number da conexão remota e procure seu endereço IP. Você provavelmente descobrirá que existe uma série de conexões não relacionadas que você pode ignorar.
Depois de encontrar o problema, execute iptables -D seguido pela cadeia ofensiva e o número da cadeia para evitar que você seja banido pelo seu próprio software novamente. Você não deve ter mais problemas como resultado. No entanto, se você fizer,
você pode editar o seguinte arquivo. 
Carregue-o em seu editor de texto favorito, provavelmente nano ou vi, como root. Você provavelmente vai querer executar algo como 
e então procure uma linha onde se lê ignoreip. Adicione seu endereço IP a esta linha para bloquear permanentemente o fail2ban de adicionar seu endereço IP a qualquer lista de bloqueio.
Distribuições diferentes do Linux fazem as coisas de maneira um pouco diferente, mas essas mudanças devem entrar em vigor instantaneamente na maioria dos casos.
3 minutos lidos
