☰

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

tag-icon • tag-icon linux ssh key-authentication
ssh_exchange_identification: Conexão fechada pelo host remoto (não usando hosts.deny)

Eu sounãousando hosts.allowor hosts.deny, além disso, 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 portdá:

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 verifiquei os logs de segurança e as linhas são idênticas, o servidor trata as duas "máquinas" diferentes de forma diferente 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 quê?

[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 (as mesmas no servidor). Também tentei sem configurar /etc/ssh/ssh_configcom o mesmo resultado, exceto por muita configuração automática acontecendo no cliente que termina com o mesmo erro.

Responder1

Postado originalmente em Pergunte ao Ubuntu

Se você descartou quaisquer fatores “externos”, o conjunto de etapas a seguir geralmente ajuda a restringi-lo. Portanto, embora isso não responda diretamente à sua pergunta, pode ajudar a rastrear a causa do erro.

Solução de problemassshd

O que geralmente considero muito útil em tais casos é iniciar sshdsem deixá-lo daemonizar. O problema no meu caso foi que nem syslogmostrou auth.lognada significativo.

Quando 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 há de errado e corrigi-lo. Nenhum dos arquivos de log continha esta saída.

Observação:pelo menos no Ubuntu $(which sshd)é o melhor método para satisfazer sshdo requisito de um caminho absoluto. Caso contrário, você receberá 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 - isso é para que ele não entre em conflito 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).

Este método me ajudou muitas vezes a encontrar problemas, sejam problemas de autenticação ou outros tipos. Para obter uma saída realmente detalhada stdout, use $(which sshd) -Ddddp 10222(observe o adicionado ddpara aumentar a verbosidade). Para obter mais informações sobre depuração, verifique a qualidade man sshd.

A principal vantagem deste método é que permite verificar a sshdconfiguraçãosemtendo que reiniciar sshdna porta padrão.Normalmenteisso não deve interferir nas conexões SSH existentes, mas eu já vi isso. Portanto, isso permite validar o arquivo de configuração antes de - potencialmente - cortar o acesso a um servidor remoto (por exemplo, tenho isso para alguns VPS e até mesmo para servidores físicos onde preciso pagar mais para obter acesso fora de banda para a máquina).

Responder2

Você também pode ter um host cuja memória esteja tão fragmentada que não seja possível alocar uma memória contígua para uma página para bifurcar o processo de hospedagem de 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 de quão longe o host chega antes de desistir.

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. Descobri que o Apache e o MySQL são os culpados nas VMs, já que as VMs não possuem uma partição swap. Caso contrário, reinicie o host.

Responder3

Por precaução, porque isso aconteceu comigo. Certifique-se de ter o sshd rodando no host!

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

Responder4

Encontrei o ssh_exchange_identification: read: Connection reset by peerproblema em um script que inicia 16 ou mais sessões ssh em loop. sshd aparentemente não consegue acompanhar; adicionando um sono curto (claramente umGambiarra... :D downvoters) 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

informação relacionada