¿Qué significa despacho_protocol_error: escriba 51 seq 5 cuando falla la conexión ssh y cómo solucionarlo?

¿Qué significa despacho_protocol_error: escriba 51 seq 5 cuando falla la conexión ssh y cómo solucionarlo?

Estoy intentando conectarme a un servidor Linux a través de SSH, usando el siguiente comando:

ssh [email protected] -p 22

Sin embargo, no puedo conectarme a él. Sólo había un mensaje dispatch_protocol_error: type 51 seq 5. El comando ssh se bloquea durante uno o dos minutos hasta que se cierra con los siguientes mensajes:

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

La búsqueda en Google del mensaje Dispatch_protocol_error no resultó en nada relevante para este error de protocolo de despacho específico, en su mayoría personas preguntaron sobre diferentes errores de protocolo de despacho (con otros valores para tipo y secuencia), y en ninguno de estos hubo ninguna explicación sobre lo que esto mensaje de error significa.

Lo único más o menos interesante esestas preguntas frecuentes sobre OpenSSH, donde una de las preguntas es sobre un "Error de protocolo de envío: tipo 20" que se produce porque "las versiones anteriores de OpenSSH no admitían la nueva clave de sesión". Me sugiere agregar RekeyIntervalSeconds 0"ssh2_config o sshd2_config de SSH 2.3". Para ver qué sucede, intenté agregar esto a mi (cliente) ssh_config (no tengo un archivo ssh2_config), pero esto no ayudó (de hecho, era una "Opción de configuración incorrecta").

Intenté conectarme sin el puerto ( ) y el resultado fue el mismo. También intentéssh [email protected]eliminar el host de la lista de hosts conocidosusando ssh-keygen -R hostname, suponiendo que fuera un problema con la huella digital de la clave RSA actual. Sin embargo, esto no me permitió conectarme y apareció el mismo mensaje de error.

Estoy usando Ubuntu 16.04 y el servidor es CentOS 6.8. Mi versión (cliente) de SSH es la versión 7.2 (deesta respuesta: ssh -v localhost):

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

Supongo, y mi jefe está de acuerdo con eso, que se trata de un problema en el servidor, por lo que no puedo resolverlo simplemente trabajando en mi computadora.

Entonces, mi pregunta es,Qué significa este mensaje de error y cómo solucionarlo.?

Ps: no soy un experto en SSH, por lo que probablemente hice acciones muy tontas y me perdí algo esencial para resolver este problema.

EDITAR:Ejecuto ssh con la opción -v (detallada). Según él, pude conectarme y autenticarme ( debug1: Authentication succeeded (none).). Después de este mensaje, aparecen los siguientes mensajes, incluido mi error. El registro completo se muestra a continuación:

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

Acerca del lado del servidor: buscar el registro sshd para CentOS ( /var/log/secure, comoesta respuestamuestra), los únicos resultados relevantes son esta repetición de un error 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

Las otras entradas antes y después de esta (con otras ID) no son de este intento específico (son de mi conexión PuTTY exitosa, como pude ver por los datos de tiempo). Cabe señalar que los números en estos mensajes de error son los mismos que obtuve en el lado del cliente.

Al intentar usar el indicador -M ( ), se produjo el mismo error.ssh -M [email protected]

Curiosamente, usando un cliente con una versión anterior de Ubuntu (Ubuntu 12.04) pude conectarme. Entonces, tal vez pueda ser una incompatibilidad de versión (el servidor es demasiado antiguo y/o el cliente es demasiado nuevo); tal vez una actualización reciente de SSH, ya que pude conectarme usando la computadora Ubuntu 16.04 hace aproximadamente un mes, o tal vez una problema de configuración.

Ps: Pude conectarme exitosamente a través de PuTTY (versión de Ubuntu). Entonces el problema solo ocurrió al intentar conectarse a través de SSH.

información relacionada