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

Question

Eu sou não usando hosts.allow ou hosts.deny , mais ainda o SSH funciona na minha máquina windows (mesmo laptop, disco rígido diferente) mas não na 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 lá são idênticas, o servidor trata as duas "máquinas" diferentes e ambas são permitidas via autenticação de chave pública.

Então, isso leva à conclusão de que isso deve ser um problema com 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

Permissões parece estar bem (mesmo no servidor) .. Também tentei sem configurar /etc/ssh/ssh_config com o mesmo resultado, exceto por muita configuração automática acontecendo no cliente, que acaba com o mesmo erro.

    

Answer 1

Se você descartou qualquer 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 em tais casos é iniciar sshd sem permitir que ele seja daemonizado. O problema no meu caso foi que nem syslog nem auth.log mostraram algo significativo.

Quando eu comecei no terminal, recebi:

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

Muito melhor! Esta mensagem de erro permitiu-me ver o que está errado e corrigi-lo. Nenhum dos arquivos de log continha esta saída.

NB: pelo menos no Ubuntu o $(which sshd) é o melhor método para satisfazer a exigência de sshd de um caminho absoluto. Caso contrário, você receberá o seguinte erro: sshd re-exec requires execution with an absolute path . O -p 10222 faz com que sshd ouça nessa porta alternativa, sobrescrevendo o arquivo de configuração - isso é para que ele não entre em conflito com as instâncias sshd potencialmente em execução. Certifique-se de escolher uma porta livre aqui.

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

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

    

Answer 2

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

Nesse caso, você pode receber uma das mensagens:

ssh_exchange_identification: read: Connection reset by peer

ou:

Connection closed by aaa.bbb.ccc.ddd

dependendo do quanto o host fica antes de suspender.

Se a fragmentação de 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 possuem uma partição swap. Caso contrário, reinicie o host.

    

Answer 3

Apenas no caso, porque isso aconteceu comigo. Tenha certeza que você tem o sshd rodando no host!

É uma falha estúpida, mas pode ser um problema seu.

    

Answer 4

Descobri que esse erro ocorreu devido ao excedimento das sessões ssh no servidor. Eu encontrei os hosts tentando se conectar e matou todas as sessões de todos os clientes. A questão resolvida depois de esclarecer todas as sessões.

    

Answer 5

Eu corri o problema ssh_exchange_identification: read: Connection reset by peer em um script que inicia 16 ou mais sessões ssh em um loop. sshd aparentemente não consegue acompanhar; adicionando um sono curto resolveu o 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

    

Answer 6

Ou você pode ter feito o que eu 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 ele não irá refazer o diretório quando reiniciado /etc/init.d/sshd falhará ao reiniciar e nada do systemd dirá o porquê.

Encontrei o problema executando o sshd em primeiro plano:

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

Reconstruir os 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 os programadores Linux: coisas criticamente importantes em /var/empty ... realmente ???

    

Answer 7

O erro ssh_exchange_identification: Connection closed by remote host pode acontecer por alguns motivos desconhecidos. Quando eu estava usando o código do Visual Studio . O mesmo erro aconteceu quando tentei puxar de repo remoto usando o comando git pull .

Eu apenas fechei o terminal embutido e abriu o terminal do Ubuntu e puxei novamente. E foi bem sucedido

    

Answer 8

Eu recebi o erro ssh_exchange_identification: Connection closed by remote host ao tentar se conectar ao SSH: Eu fiz um encaminhamento de porta remoto para a porta SSH 22 do meu computador local para que eu possa acessá-lo temporariamente de um servidor remoto na Internet.

Na verdade, o erro acabou de ser exibido porque eu não lembrei que desativei o serviço SSH na inicialização, então tive que iniciar o serviço SSH no meu computador local: sudo service ssh start .

    

Answer 9

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

ssh_exchange_identification: Connection closed by remote host

E aconteceu que meu Raspberry Pi estava desligado!

Eu estava pensando que um host não ligado teria gerado o erro "Nenhuma rota para hospedar". O Raspberry Pi está por trás do meu roteador ISP, então é provavelmente ele que estava fechando a conexão.

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

No route to host

    

Answer 10

Primeira coisa primeiro; telnet para o endereço IP do host para verificar se a porta 22 está realmente escutando (aberta) naquele host:

telnet x.x.x.x 22

(se não, então você pode ligar um cabo de console para login)

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

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

Lição:

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

    

Answer 11

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