SSH 接続が失敗したときに「dispatch_protocol_error: type 51 seq 5」が発生する意味と解決方法を教えてください。

SSH 接続が失敗したときに「dispatch_protocol_error: type 51 seq 5」が発生する意味と解決方法を教えてください。

次のコマンドを使用して、SSH 経由で Linux サーバーに接続しようとしています。

ssh [email protected] -p 22

しかし、接続できません。 というメッセージだけが表示されました。sshdispatch_protocol_error: type 51 seq 5コマンドは、次のメッセージが表示されて終了するまで、約 1 ~ 2 分間ハングします。

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

Google で dispatch_protocol_error メッセージを検索しても、この特定のディスパッチ プロトコル エラーに関連する結果は何も得られませんでした。ほとんどの人は、さまざまなディスパッチ プロトコル エラー (type と seq の値が他のもの) について質問しており、そのいずれにも、このエラー メッセージの意味についての説明はありませんでした。

唯一興味深いのはこのOpenSSH FAQ、質問の 1 つは、「OpenSSH の古いバージョンではセッションの再キー化がサポートされていなかった」ために発生する「ディスパッチ プロトコル エラー: タイプ 20」に関するものです。RekeyIntervalSeconds 0「SSH 2.3 の 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

私の推測では、そして上司もそれに同意しているのですが、これはサーバーの問題なので、自分のコンピューターで作業するだけでは解決できません。

そこで私の質問は、このエラーメッセージの意味と解決方法?

Ps: 私は SSH の専門家ではないので、おそらく非常に愚かな行動をとり、この問題を解決するために重要な何かを見逃した可能性があります。

編集:-v (verbose) オプションを付けて ssh を実行しました。それによると、接続して認証できました ( 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

サーバー側について: CentOSのsshdログを見る/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

このエントリの前後にある他のエントリ (他の ID を持つ) は、この特定の試行からのものではありません (時間データからわかるように、これらは成功した PuTTY 接続からのものです)。これらのエラー メッセージの番号は、クライアント側で取得した番号と同じであることに注意してください。

-M フラグ ( ) を使用して試しても、同じエラーが発生しました。ssh -M [email protected]

不思議なことに、古いバージョンの Ubuntu (Ubuntu 12.04) を搭載したクライアントを使用すると、接続できました。したがって、バージョンの非互換性 (サーバーが古すぎる、またはクライアントが新しすぎる) が原因の可能性があります。約 1 か月前に Ubuntu 16.04 コンピューターを使用して接続できたので、SSH が最近更新された可能性があります。または、構成の問題かもしれません。

Ps: PuTTY (Ubuntu バージョン) 経由では正常に接続できました。したがって、問題は SSH 経由で接続しようとしたときにのみ発生しました。

関連情報