ssh_exchange_identification: conexão fechada pelo host remoto (não usando hosts.deny)

Estou não usando hosts.allowou hosts.deny, ainda mais SSH funciona do meu windows-máquina (mesmo laptop, diferente disco rígido), mas não a minha máquina Linux.

ssh -vvv root@host -p port dá:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

Na máquina Windows, tudo funciona bem, então eu verifiquei os logs de segurança e as linhas são idênticas, o servidor trata as duas "máquinas" diferentes de maneira diferente e são permitidas pela autenticação de chave pública.

Isso leva à conclusão de que esse deve ser um problema no meu laptop ArchLinux local ... mas o que?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

Então esse não é o problema ..

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Não há conflitos com as configurações do firewall (por enquanto).

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

As permissões parecem estar boas (iguais no servidor). Também tentadas sem configurar /etc/ssh/ssh_configcom o mesmo resultado, exceto por muitas configurações automáticas acontecendo no cliente, que terminam com o mesmo erro.

Se você descartou algum fator "externo", o seguinte conjunto de etapas geralmente ajuda a reduzi-lo. Portanto, embora isso não responda diretamente à sua pergunta, pode ajudar a rastrear a causa do erro.

Solução de problemas sshd

O que eu acho geralmente muito útil nesses casos é começar sshdsem deixar daemonizar. O problema no meu caso era que syslognem auth.logmostrava nada significativo.

Quando o iniciei no terminal, obtive:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Muito melhor! Essa mensagem de erro me permitiu ver o que havia de errado e corrigi-lo. Nenhum dos arquivos de log continha essa saída.

Nota: pelo menos no Ubuntu, $(which sshd)é o melhor método para satisfazer a sshdexigência de um caminho absoluto. Caso contrário, você vai ter o seguinte erro: sshd re-exec requires execution with an absolute path. O -p 10222faz sshdescutar nessa porta alternativa, substituindo o arquivo de configuração - para não colidir com sshdinstâncias potencialmente em execução . Certifique-se de escolher uma porta gratuita aqui.

Finalmente: conecte-se à porta alternativa ( ssh -p 10222 user@server).

Esse método me ajudou muitas vezes a encontrar problemas, sejam de autenticação ou outros tipos. Para obter uma saída realmente detalhada stdout, use $(which sshd) -Ddddp 10222(observe o dditem adicionado para aumentar a verbosidade). Para mais verificação de bondade de depuração man sshd.

Você também pode ter um host com uma memória tão fragmentada que não pode alocar uma página com uma memória contígua para bifurcar o processo de hospedagem de uma sessão SSH.

Nesse caso, você pode receber uma das seguintes mensagens:

ssh_exchange_identification: read: Connection reset by peer

ou:

Connection closed by aaa.bbb.ccc.ddd

dependendo de quão longe o host chega antes de cair fora.

Se a fragmentação da memória for a causa aparente, a solução é acessar o servidor por outros meios e reiniciar alguns dos serviços pertinentes. Eu descobri que o Apache e o MySQL são os culpados pelas VMs, já que as VMs não têm uma partição de troca. Caso contrário, reinicie o host.

Só por precaução, porque isso aconteceu comigo. Verifique se o sshd está sendo executado no host!

É um fracasso estúpido, mas pode ser realmente o seu problema.

Descobri que esse erro se devia ao exceder as sessões ssh no servidor. Eu encontrei os hosts tentando conectar e eliminou todas as sessões de todos os clientes. O problema foi resolvido após a limpeza de todas as sessões.

Encontrei o ssh_exchange_identification: read: Connection reset by peerproblema em um script que inicia 16 ou mais sessões ssh em um loop. aparentemente, o sshd não pode acompanhar; adicionar um sono curto resolveu meu problema:

for i in $(seq 32)
do
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1
done

Ou você pode ter feito o que fiz ontem à noite e excluído / var / empty. Aparentemente, esse diretório e suas permissões são essenciais para o funcionamento do sshd e não o refaz quando o reinício /etc/init.d/sshdfalhará ao reiniciar e nada do systemd lhe dirá o porquê.

Encontrei o problema executando o sshd em primeiro plano:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

A reconstrução dos diretórios resolveu o problema no meu caso:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Nota para programadores do Linux: Coisas criticamente importantes em /var/empty... realmente ???

Ocorreu o erro ssh_exchange_identification: Connection closed by remote hostao tentar conectar-me ao SSH: fiz um encaminhamento de porta remota para a porta SSH 22 do meu computador local, para que eu possa acessá-lo temporariamente a partir de um servidor remoto na Internet.

Na verdade, o erro foi apenas exibida porque eu não me lembro que eu desativado o serviço de SSH na inicialização para que eu tinha para iniciar o serviço SSH no meu computador local: sudo service ssh start.

As coisas importantes primeiro; telnet para o endereço IP do host para verificar se a porta 22 está realmente escutando (aberta) nesse host:

telnet x.x.x.x 22

(caso contrário, você pode conectar um cabo do console para fazer login)

No meu caso, ele não estava funcionando e eu liguei um cabo do console para fazer login. Depois de fazer login, descobri que todas as 5 linhas VTY estavam ocupadas nesse host (um roteador Cisco).

Eu limpei as conexões antigas que estavam penduradas lá para liberar as linhas do VTY, funcionou. Eu adicionei o comando "exec-timeout 15" sob as linhas do VTY. Então eu removi o cabo do console.

Lição:

Defina um tempo limite de 5 a 10 minutos em todos os seus dispositivos - (se nenhuma atividade for detectada).

Meu caso foi definido por engano como proxy de soquete (que não está funcionando). Eu tenho exatamente a mesma saída ssh -vvv e log sshd vazio.

O erro ssh_exchange_identification: Connection closed by remote hostpode ocorrer por alguns motivos desconhecidos. Quando eu estava usando o código do Visual Studio . O mesmo erro ocorreu quando tentei extrair do repositório remoto usando o git pullcomando

Eu só fechou o terminal incorporado e abriu o terminal do Ubuntu e puxou novamente. E foi bem sucedido

De com CentOS Linux release 7.4.1708 (Core)com OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017atrás de uma conexão não filtrando portas, tive:

ssh_exchange_identification: conexão fechada pelo host remoto

E aconteceu que meu Raspberry Pi estava desligado!

Eu estava pensando que um host não ligado teria produzido o erro "Nenhuma rota para hospedar". O Raspberry Pi está atrás do meu roteador ISP e, provavelmente, foi ele que estava fechando a conexão.

Então eu repeti o experimento (tentando conectar-se a um Raspberry Pi desligado) de outra conexão com a Internet, também não filtrando portas com o Debian Stretch OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017e, desta vez, esperava o seguinte:

Nenhuma rota para hospedar