Estou tentando me conectar a um servidor Linux através de 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é ser fechado com as seguintes mensagens:
Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.
Pesquisar no Google pela mensagem dispatch_protocol_error não resultou em nada relevante para esse erro específico do protocolo de despacho, principalmente pessoas perguntando sobre diferentes erros de protocolo de despacho (com outros valores para tipo e seq), e em nenhum deles houve qualquer explicação sobre o que isso mensagem de erro significa.
A única coisa mais ou menos interessante éesta pergunta frequente do OpenSSH, onde uma das perguntas é sobre um "Erro de protocolo de despacho: tipo 20" que ocorre porque "versões mais antigas do OpenSSH não suportavam rechaveamento de sessão". Ele sugere que eu adicione RekeyIntervalSeconds 0ao "ssh2_config ou sshd2_config do SSH 2.3". Para ver o que acontece tentei adicionar isso ao meu (cliente) ssh_config (não tenho um arquivo ssh2_config), mas isso não ajudou (na verdade, era uma "opção de configuração incorreta").
Tentei conectar sem a porta ( ) e o resultado foi o mesmo. Eu também tenteissh [email protected]remova o host da lista de hosts conhecidosusando ssh-keygen -R hostname, supondo que houvesse um problema com a 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 versão (cliente) do SSH é a versão 7.2 (deesta 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?
Ps: Não sou especialista em SSH, então provavelmente fiz ações muito bobas e perdi algo essencial para resolver esse problema.
EDITAR:Eu executo o ssh com a opção -v (detalhado). Segundo ele, consegui me conectar e autenticar ( debug1: Authentication succeeded (none).). Após esta mensagem, existem as seguintes mensagens, incluindo o meu erro. O log 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 do CentOS ( /var/log/secure, comoesta respostamostra), os únicos resultados relevantes são esta repetição de um erro semelhante:
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 outros IDs) não são desta tentativa específica (são da minha conexão PuTTY bem-sucedida, como pude ver pelos dados de tempo). Deve-se observar que os números nessas mensagens de erro são os mesmos que obtive no lado do cliente.
Tentar com o sinalizador -M ( ) resultou no mesmo erro.ssh -M [email protected]
Estranhamente, usando um cliente com uma versão mais antiga do Ubuntu (Ubuntu 12.04) consegui me conectar. Então talvez possa ser 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 me conectar usando o computador Ubuntu 16.04 há cerca de um mês, ou talvez um problema de configuração.
Ps: Consegui me conectar com sucesso através do PuTTY (versão Ubuntu). Então o problema só aconteceu ao tentar conectar via SSH.