Correção: ssh_exchange_identification & lsquo; conexão fechada pelo host remoto & rsquo;

Embora em muitos casos o ssh_exchange_identification: conexão encerrada por erro de host remoto possa ser causado por problemas relacionados aos arquivos de configuração hosts.deny e hosts.allow, há outras coisas que podem causar o problema. Se você está lendo isso, é provável que você já tenha verificado se ambos os arquivos não estavam bloqueando o seu endereço IP de tentar usar ssh em um servidor remoto.

Supondo que seja esse o caso, você pode estar olhando para um problema de dependência, algo relacionado à fragmentação de memória ou até mesmo um número excessivo de sessões provenientes de clientes individuais. A boa notícia é que, depois de resolver o problema, você não verá o erro novamente.

Método 1: corrigindo dependências ausentes

Se você obteve o ssh_exchange_identification: conexão fechada por erro de host remoto somente após atualizar OpenSSL ou glibc, então você pode estar vendo uma dependência ausente. Execute sudo lsof -n | grep ssh | grep DEL a partir da linha de comando nesta situação. Isso lhe dará uma lista de arquivos abertos, em seguida, procure apenas aqueles que foram excluídos recentemente relacionados ao daemon ssh.

Se você não receber nada de volta, você ainda pode tentar reiniciar o daemon ou o próprio sistema. Você vai querer reiniciar se vários erros forem devolvidos a você, embora você possa ignorar com segurança aqueles relacionados às mensagens / run / user / 1000 / gvfs, pois são causados ​​por um problema não relacionado que deve fazer com um sistema de arquivos virtual.

Você também pode tentar usar apt-get, pacman ou yum para atualizar seus pacotes se suspeitar que as dependências são um problema. Se você estiver em um sistema baseado em Debian ou Ubuntu, então você pode tentar sudo apt-get -f upgrade e ver se isso corrige algum pacote quebrado que você possa ter entrado em conflito.

Método 2: corrigindo a fragmentação da memória

Se isso não ajudar, você pode ter um problema no lado do host da equação. Hosts executados dentro de uma VM nem sempre têm uma partição de troca, o que pode levar à fragmentação da memória. Acesse o host por algum outro meio, talvez fisicamente, se possível, e reinicie todos os serviços que apresentarem problemas. MySQL, Apache, nginx e outros serviços semelhantes podem ser os culpados.

Embora nem sempre seja possível reinicializar o host, isso pode corrigir o problema e pode ser uma boa ideia se você estiver alternando entre essa mensagem de erro e uma que retorna um endereço IP. Lembre-se de que, se você tiver qualquer tipo de acesso ao servidor, poderá executar o comando vmstat -s e obter algumas estatísticas importantes sobre como a memória está sendo usada, mesmo como um usuário regular em muitos casos.

Método 3: verificar instâncias extras ssh

Exceto isso, verifique se os hosts estão tentando se conectar ao servidor. Você pode ter excedido o número máximo de sessões ssh sem saber. Limpe as sessões antigas e tente reconectar. Uma maneira fácil de fazer isso é executar o comando who para ver quais processos do usuário estão logados. Você deve ver apenas um ou dois usuários logados. Se houver vários usuários paralelos, elimine os processos do usuário e tente fazer o login novamente .

Isso pode acontecer se o sshd não conseguir acompanhar um script que inicia muitas sessões ssh diferentes em um loop. Se isso já aconteceu com você, adicione o comando sleep 0.3 ao loop para que o daemon sshd tenha tempo para acompanhar.

Método 4: Encontre o Limite de Conexão sshd

Problemas de conexão como esse são especialmente prevalentes ao tentar usar ssh para acessar um roteador ou outro tipo de switch em caixa discreto, uma vez que o número máximo padrão de conexões é muito pequeno. Embora você não queira sobrecarregar o servidor, pode dar uma olhada em qual é a configuração padrão.

Tente executar no servidor para descobrir quantas conexões o sshd pode controlar. Na maioria dos casos, o sistema deve ter como padrão 10 conexões simultâneas, o que deve ser suficiente para a maioria das estruturas de servidor em que a maioria dos usuários provavelmente precisará usar o ssh regularmente.