Я пытаюсь подключиться к серверу Linux через SSH, используя следующую команду:
ssh root@ip.of.server.com -p 22
Однако я не могу подключиться к нему. Было только сообщение dispatch_protocol_error: type 51 seq 5 . Команда ssh зависает в течение одной или двух минут, пока не закроется следующими сообщениями:
Connection to ip.of.server.com closed by remote host.
Connection to ip.of.server.com closed.
Поиск в Google сообщения dispatch_protocol_error не привел к чему-либо, относящемуся к этой конкретной ошибке протокола диспетчеризации, в основном люди спрашивали о различных ошибках протокола диспетчеризации (с другими значениями для type и seq), и ни в одном из них не было никакого объяснения того, что это сообщение об ошибке значит.
Единственная более или менее интересная вещь - это часто задаваемые вопросы по OpenSSH, где один из вопросов касается «ошибки протокола отправки: тип 20», которая возникает из-за того, что "более старые версии OpenSSH не поддерживали смену сеансов". Он предлагает мне добавить RekeyIntervalSeconds 0 к «SSH 2.3's ssh2_config или sshd2_config». Чтобы увидеть, что происходит, я попытался добавить это в свой (клиентский) ssh_config (у меня нет файла ssh2_config), но это не помогло (на самом деле это был "Плохой вариант конфигурации").
Я пытался подключиться без порта (ssh root@ip.of.server.com), и результат был тот же. Я также попытался удалить хост из списка известных хостов с помощью ssh-keygen -R hostname , предположив, что это проблема с текущим отпечатком ключа RSA. Однако это не позволило мне подключиться, и было показано то же сообщение об ошибке.
Я использую Ubuntu 16.04, а сервер - CentOS 6.8. Моя (клиентская) версия SSH - это версия 7.2 (из этого ответа: ssh -v localhost):
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g
Мое предположение, и мой начальник согласен с этим, заключается в том, что это проблема на сервере, поэтому я не могу решить ее, просто работая на своем компьютере.
Итак, мой вопрос, что означает это сообщение об ошибке и как его решить?
PS: я не специалист по SSH, поэтому я, вероятно, сделал очень глупые действия и пропустил что-то важное, чтобы решить эту проблему.
РЕДАКТИРОВАТЬ: я запускаю ssh с опцией -v (подробный). В соответствии с этим я смог подключиться и аутентифицироваться (debug1: Authentication succeeded (none).). После этого сообщения появляются следующие сообщения, в том числе моя ошибка. Полный журнал следует ниже:
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: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com 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 no-more-sessions@openssh.com
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
Об стороне сервера: просматривая журнал sshd для CentOS (/var/log/secure , как показывает этот ответ ), единственные релевантные результаты - это повторение подобной ошибки:
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
Другие записи до и после этой (с другими идентификаторами) не из этой конкретной попытки (они из моего успешного подключения PuTTY, как я мог видеть по данным времени). Следует отметить, что числа в этих сообщениях об ошибках совпадают с теми, которые я получил на стороне клиента.
Попытка с флагом -M (ssh -M root@ip.of.server.com) привела к той же ошибке.
Странно, но с помощью клиента с более старой версией Ubuntu (Ubuntu 12.04) я смог подключиться. Так что, возможно, это может быть несовместимость версий (сервер слишком старый и / или клиент слишком новый) - возможно, недавнее обновление SSH, поскольку я смог подключиться с помощью компьютера Ubuntu 16.04 около месяца назад, или, может быть, проблема конфигурации.
PS: мне удалось успешно подключиться через PuTTY (версия Ubuntu). Так что проблема возникла только при попытке подключения через SSH.