Я пытаюсь подключиться к серверу Linux через SSH, используя следующую команду:
ssh [email protected] -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, где один из вопросов касается "Ошибки протокола Dispatch: тип 20", которая возникает из-за того, что "старые версии OpenSSH не поддерживали смену ключей сеанса". Мне предлагается добавить RekeyIntervalSeconds 0в "SSH 2.3's ssh2_config или sshd2_config". Чтобы посмотреть, что произойдет, я попытался добавить это в свой (клиентский) ssh_config (у меня нет файла ssh2_config), но это не помогло (на самом деле, это была "Неправильная опция конфигурации").
Я пробовал подключаться без порта ( ), и результат был тот же. Я также пробовалssh [email protected]удалить хост из списка известных хостовс помощью 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
Я предполагаю, и мой начальник с этим согласен, что проблема на сервере, поэтому я не могу решить ее, просто работая на своем компьютере.
Итак, мой вопрос:что означает это сообщение об ошибке и как ее устранить?
P.S. Я не эксперт в SSH, поэтому, вероятно, совершил очень глупые действия и упустил что-то важное для решения этой проблемы.
РЕДАКТИРОВАТЬ:Я запускаю ssh с опцией -v (verbose). Согласно ей, мне удалось подключиться и пройти аутентификацию ( 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: [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
Что касается серверной части: просматриваем журнал 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 [email protected]
Странно, но используя клиент с более старой версией Ubuntu (Ubuntu 12.04) я смог подключиться. Так что, возможно, это несовместимость версий (сервер слишком старый и/или клиент слишком новый) - может быть, недавнее обновление SSH, так как я смог подключиться с помощью компьютера Ubuntu 16.04 около месяца назад, или, может быть, проблема в конфигурации.
Ps: Мне удалось успешно подключиться через PuTTY (версия Ubuntu). Так что проблема возникла только при попытке подключения через SSH.