conexão ssh para em "debug1: SSH2_MSG_KEXINIT enviado"

conexão ssh para em "debug1: SSH2_MSG_KEXINIT enviado"

Alterei o número da porta ssh de 22 para 2222 A conexão de configuração anterior para a porta ssh padrão 22 está correta Mapeei o NAT no roteador corretamente

Quando tento depurar

ssh -v -p2222 www.example.com

Eu recebo esse erro pendurado

debug1: SSH2_MSG_KEXINIT

Abaixo está todo o log de depuração

bob@server:~$ ssh -v -p2222 www.example.com
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to www.example.com [100.100.100.100] port 2222.
debug1: Connection established.
debug1: identity file /home/bob/.ssh/identity type -1
debug1: identity file /home/bob/.ssh/id_rsa type -1
debug1: identity file /home/bob/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 100.100.100.100

Assim como a conexão foi fechada, usei gnome-terminal, putty, securecrt em algumas máquinas dentro e fora da rede, mas todas recebem o mesmo erro

Responder1

Acabei de acontecer isso comigo em um host XEN. Eu dupliquei esse host de outro e, como é prática comum, excluí as chaves do host em /etc/ssh depois de fazer isso, pensando que novas seriam geradas posteriormente. Mas isso nunca aconteceu, e o sshd começou felizmente sem chaves de host. Ao tentar fazer ssh para este host, ele cairia após SSH2_MSG_KEXINIT. Tudo o que tive que fazer foi criar as chaves do host, que na máquina baseada em Debian é feita desta forma:

dpkg-reconfigure openssh-server

Responder2

Eu tive esse problema e resolvi-o configurando o MTU no roteador/firewall de destino e no host de destino para o mesmo que o host de origem (1500).

Responder3

Eu tive o mesmo problema, o sshd ficou confuso quando mudei a porta no sshd_config e reiniciei o serviço sshd, quando finalmente olhei os logs do servidor (o que parece que você não pode), o sshd estava reclamando da porta já estar em uso, o netstat concordou, e um ps mostrou várias instâncias de serviços sshd em execução. Eu os matei e iniciei o sshd novamente e consegui me conectar. Juro que tentei reiniciar para resolver o problema, mas acho que não, porque isso provavelmente teria resolvido o problema.

Resumindo, o sshd que deveria estar escutando na porta 2222 para autenticá-lo não é aquele que realmente está escutando, outro processo sshd é. Se você tiver o mesmo problema que eu.

Responder4

SSH2_MSG_KEXINIT não é um erro. Está apenas informando que está iniciando o processo de troca de chaves ssh.

Se a outra extremidade estiver fechando a conexão naquele ponto, aparentemente ela não gosta de você por algum motivo :-) os logs do lado remoto podem conter informações sobre o motivo pelo qual a conexão está sendo encerrada precipitadamente. (tcpwrappers, por exemplo)

informação relacionada