What means dispatch_protocol_error: type 51 seq 5 when ssh connection fails and how to solve it?

Question

I'm trying to connect to a Linux server through SSH, by using the following command:

ssh [e-mail] -p 22

However, I'm not able to connect to it. There was only a message, dispatch_protocol_error: type 51 seq 5. The ssh command hangs for about one or two minutes until it's closed with the following messages:

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

Searching in Google for the dispatch_protocol_error message did not resulted in anything relevant to this specific dispatch protocol error, mostly people asking about different dispatch protocol errors (with other values for type and seq), and in none of these there was any explanation about what this error message means.

The only more or less interesting thing is this OpenSSH FAQ, where one of the questions is about a "Dispatch protocol error: type 20" which occurs because "older versions of OpenSSH did not support session rekeying". It suggests me to add RekeyIntervalSeconds 0 to the "SSH 2.3's ssh2_config or sshd2_config". To see what happens I tried to add this to my (client) ssh_config (I don't have a ssh2_config file), but this did not helped (in fact, it was a "Bad configuration option").

I tried to connect without the port (ssh [e-mail]), and the result was the same. I also tried to remove the host from the list of known hosts by using ssh-keygen -R hostname, supposing it was a problem with the current RSA key fingerprint. However, this did not allowed me to connect, and the same error message was shown.

I'm using a Ubuntu 16.04 and the server is a CentOS 6.8. My (client) version of SSH is the 7.2 version (from this answer: ssh -v localhost):

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

My guess, and my boss agrees with that, is that this a problem in the server, so I can't solve it just by working on my computer.

So, my question is, what this error message means and how to solve it?

P.s.: I'm not an expert in SSH, so I probably did very silly actions and missed something essential to solve this problem.

EDIT: I run the ssh with the -v (verbose) option. According to it, I was able to connect and authenticate (debug1: Authentication succeeded (none).). After this message, there are the following messages, including my error. The complete log follows below:

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: [e-mail] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [e-mail] 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 [e-mail]
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

About the server side: looking the sshd log for CentOS (/var/log/secure, as this answer shows), the only relevant results are this repetition of a similar error:

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

The other entries before and after this one (with other IDs) are not from this specific try (they're from my successful PuTTY connection, as I could see by the time data). It should be noted that the numbers in these errors messages are the same I got in the client-side.

Trying with the -M flag (ssh -M [e-mail]) resulted in the same error.

Strangely, using a client with an older version of Ubuntu (Ubuntu 12.04) I was able to connect. So maybe it can be a version incompatibility (the server is too old and/or the client is too new) - maybe a recent update of SSH, since I was able to connect using the Ubuntu 16.04 computer about a month ago, or maybe a configuration problem.

P.s.: I was able to successfully connect through PuTTY (Ubuntu version). So the problem only happened when trying to connect via SSH.