erro SSH ssh_exchange_identification: read: Conexão redefinida pelo peer

Question

Estou tentando acessar o ssh para um servidor, mas tenho " ssh_exchange_identification: read: Connection reset by peer ". O mesmo cliente funciona bem quando movo o computador para casa, mas mostro o erro quando o computador está no escritório de trabalho. É possível que alguma configuração de rede LAN na rede do escritório cause o problema? Eu tentei outros computadores na rede do escritório, o mesmo problema.

Posso alterar as configurações do servidor para corrigir esse problema?

Cliente e servidor com o mesmo Debian "Linux debian 3.16.0-4-amd64 # 1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU / Linux"

No lado do cliente, o log mostra:

OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /home/client/.ssh/config
debug1: /home/client/.ssh/config line 13: Applying options for navtk
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/client/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to www.host.com [xx.xx.xx.xx] port xx.
debug1: Connection established.
debug1: identity file /home/client/.ssh/user type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/user-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3
ssh_exchange_identification: read: Connection reset by peer

E o login no lado do servidor

Server listening on :: port 443.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 735
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
debug1: getpeername failed: Transport endpoint is not connected
debug1: get_remote_port failed

    

Answer 1

"Conexão redefinida pelo peer" significa que o fluxo TCP foi fechado anormalmente a partir da outra extremidade. Acho que as explicações mais prováveis são de que o processo do servidor remoto que manipula a conexão falhou, ou então algum dispositivo de rede (como um firewall dinâmico ou um balanceador de carga) decidiu interferir na conexão.

Você precisa depurar isso no servidor remoto, se puder. sshd logs através de syslog , e em um típico sistema Unix as entradas de log estarão em um dos arquivos no diretório /var/log . Se você tiver sorte, sshd estará registrando algo toda vez que a sessão for descartada.

Se você tiver acesso root no servidor, poderá executar uma instância de depuração de sshd . Torne-se root e execute:

/path/to/sshd -ddd -p 1022

Isso executará uma instância do servidor SSH que escutará na porta 1022, aceitará uma conexão e imprimirá as informações de depuração no seu terminal. Execute seu cliente como de costume, exceto especificar a porta 1022 como a porta:

ssh -p 1022 user@host

As informações de depuração impressas pelo servidor deixarão claro o que está acontecendo.

Editar: a saída do servidor indica que o servidor não está falhando ou fechando deliberadamente a conexão TCP. Algo mais está causando o fechamento. Eu daria uma olhada em qualquer software de segurança instalado no servidor que pudesse monitorar sessões TCP, assim como firewalls, balanceadores de carga ou hardware de rede similar que pudesse fazer parte da rede local.

    

Answer 2

Estou tendo o mesmo problema. Agora, parece que a questão é com o meu provedor. Tente fazer um traceroute no seu servidor. Para mim, isso falha antes de chegar ao servidor.

Meu servidor é um servidor de hospedagem compartilhada. Minha empresa de hospedagem me disse que eles tiveram o mesmo problema com outros clientes que usam AT & T ou Comcast.

Espero que isso ajude ou, pelo menos, evite que você gaste tempo excessivo em outras possibilidades.

    

Answer 3

É muito tarde aqui, mas pode ser que alguém simplesmente aceite isso.

1. Reinicie (pare e inicie) o servidor.
2. Acesso ao servidor por ssh novamente com o ip público. (Você pode continuar na próxima etapa se é com sucesso.)
3. Reinicie o servidor da web.

É isso ou você pode precisar apontar o domínio para o ip público novamente.

Meus ambientes são AWS e NGINX.

    

Answer 4

"ssh_exchange_identification: read: A conexão redefinida por peer" também acontecerá quando você acabar na lista de bloqueio (por exemplo, porque você digitou a senha errada com muita frequência). Aconteceu com o meu Synology-NAS. Portanto, verifique se o IP do qual você está se conectando não está nessa lista.

No caso de uma sinologia, verifique em "Painel de controle" / "Segurança" / "Conta".