O que significa dispatch_protocol_error: digite 51 seq 5 quando a conexão ssh falha e como resolvê-lo?

Question

Estou tentando conectar-me a um servidor Linux por meio do SSH, usando o seguinte comando:

ssh [email protected] -p 22

No entanto, não consigo me conectar a ele. Havia apenas uma mensagem, dispatch_protocol_error: type 51 seq 5 . O comando ssh trava por cerca de um ou dois minutos até que seja fechado com as seguintes mensagens:

Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.

A pesquisa no Google pela mensagem dispatch_protocol_error não resultou em nada relevante para esse erro específico de protocolo de despacho, principalmente pessoas perguntando sobre diferentes erros de protocolo de despacho (com outros valores para type e seq), e em nenhum deles houve qualquer explicação sobre o que esta mensagem de erro significa.

A única coisa mais ou menos interessante é este FAQ do OpenSSH , onde Uma das perguntas é sobre um "Erro de protocolo de distribuição: tipo 20", que ocorre porque "versões mais antigas do OpenSSH não suportavam a recriação de senhas". Isso sugere que eu adicione RekeyIntervalSeconds 0 ao "SSH 2.3's ssh2_config ou sshd2_config". Para ver o que acontece eu tentei adicionar isso ao meu (cliente) ssh_config (eu não tenho um arquivo ssh2_config), mas isso não ajudou (na verdade, era uma "opção de configuração ruim").

Eu tentei me conectar sem a porta ( ssh [email protected] ) e o resultado foi o mesmo. Eu também tentei remover o host da lista de hosts conhecidos usando ssh-keygen -R hostname , supondo que fosse um problema com o impressão digital da chave RSA atual. No entanto, isso não me permitiu conectar, e a mesma mensagem de erro foi mostrada.

Estou usando um Ubuntu 16.04 e o servidor é um CentOS 6.8. Minha (cliente) versão do SSH é a versão 7.2 (de esta resposta : ssh -v localhost ):

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g

Meu palpite, e meu chefe concorda com isso, é que isso é um problema no servidor, então não posso resolvê-lo apenas trabalhando no meu computador.

Então, minha pergunta é, o que esta mensagem de erro significa e como resolvê-la ?

P.: Eu não sou um especialista em SSH, então eu provavelmente fiz ações muito tolas e perdi algo essencial para resolver este problema.

EDIT: Eu corro o ssh com a opção -v (verbose). De acordo com isso, eu consegui conectar e autenticar ( debug1: Authentication succeeded (none). ). Depois desta mensagem, há as seguintes mensagens, incluindo o meu erro. O registro completo segue abaixo:

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ip.of.server.com [ip.of.server.com] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuser/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to ip.of.server.com:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:server_host_key_ssh_rsa_is_here
debug1: Host 'ip.of.server.com' is known and matches the RSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:6
debug1: rekey after 3249842342 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 3249842342 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentication succeeded (none).
Authenticated to ip.of.server.com ([ip.of.server.com]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
dispatch_protocol_error: type 51 seq 5
debug1: Received SSH2_MSG_UNIMPLEMENTED for 6
debug1: Received SSH2_MSG_UNIMPLEMENTED for 7
debug1: Received SSH2_MSG_UNIMPLEMENTED for 9
debug1: Received SSH2_MSG_UNIMPLEMENTED for 10
debug1: Received SSH2_MSG_UNIMPLEMENTED for 11
debug1: Received SSH2_MSG_UNIMPLEMENTED for 12

... (there are lots of this SSH2_MSG_UNIMPLEMENTED message)

debug1: Received SSH2_MSG_UNIMPLEMENTED for 60
debug1: Received SSH2_MSG_UNIMPLEMENTED for 61
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 1 clearing O_NONBLOCK
debug1: channel 0: free: client-session, nchannels 1
Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.
Transferred: sent ..., received ... bytes, in ... seconds
Bytes per second: sent ..., received ...
debug1: Exit status -1

Sobre o lado do servidor: procurando o log sshd para o CentOS ( /var/log/secure , como esta resposta mostra), o Somente resultados relevantes são a repetição de um erro similar:

Jan  5 14:38:44 myserverside sshd[1234]: dispatch_protocol_error: type 90 seq 6
Jan  5 14:38:44 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 7
Jan  5 14:38:46 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 9
Jan  5 14:38:48 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 10
Jan  5 14:38:50 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 11
Jan  5 14:38:52 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 12

...

Jan  5 14:40:31 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 60
Jan  5 14:40:33 myserverside sshd[1234]: dispatch_protocol_error: type 80 seq 61

As outras entradas antes e depois desta (com outras IDs) não são desta tentativa específica (elas são da minha conexão PuTTY bem-sucedida, como pude ver pelos dados de hora). Deve-se notar que os números nessas mensagens de erro são os mesmos que eu obtive no lado do cliente.

Tentar com o sinalizador -M ( ssh -M [email protected] ) resultou no mesmo erro.

Estranhamente, usando um cliente com uma versão mais antiga do Ubuntu (Ubuntu 12.04) eu consegui me conectar. Então, talvez seja uma incompatibilidade de versão (o servidor é muito antigo e / ou o cliente é muito novo) - talvez uma atualização recente do SSH, já que consegui conectar usando o computador Ubuntu 16.04 há cerca de um mês ou talvez problema de configuração.

P.: Consegui me conectar com sucesso através do PuTTY (versão do Ubuntu). Então o problema só aconteceu ao tentar se conectar via SSH.