☰

SSH 接続が「debug1: SSH2_MSG_KEXINIT が送信されました」で停止します

tag-icon • tag-icon ssh
SSH 接続が「debug1: SSH2_MSG_KEXINIT が送信されました」で停止します

SSHポート番号を22から2222に変更しました。以前のセットアップ接続はデフォルトのSSHポート22で問題ありません。ルーターのNATを正しくマッピングしました。

デバッグしようとすると

ssh -v -p2222 www.example.com

このエラーが発生します

debug1: SSH2_MSG_KEXINIT

以下はすべてのデバッグログです

bob@server:~$ ssh -v -p2222 www.example.com
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to www.example.com [100.100.100.100] port 2222.
debug1: Connection established.
debug1: identity file /home/bob/.ssh/identity type -1
debug1: identity file /home/bob/.ssh/id_rsa type -1
debug1: identity file /home/bob/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 100.100.100.100

接続が閉じられたのと同じように、ネットワーク内外のいくつかのマシンでgnome-terminal、putty、securecrtを使用しましたが、すべて同じエラーが発生します。

答え1

XEN ホストでこの現象が発生しました。このホストを別のホストから複製し、一般的な方法に従い、後で新しいホスト キーが生成されるだろうと考えて、この操作を行った後、/etc/ssh 内のホスト キーを削除しました。しかし、この操作は実行されず、sshd はホスト キーなしで正常に起動しました。このホストに ssh しようとすると、SSH2_MSG_KEXINIT の後に切断されます。必要なのはホスト キーを作成することだけで、Debian ベースのマシンでは次のように実行されます。

dpkg-reconfigure openssh-server

答え2

私もこの問題を抱えていましたが、宛先ルーター/ファイアウォールと宛先ホストの MTU をソース ホストと同じ (1500) に設定することで解決しました。

答え3

私も同じ問題を抱えていました。sshd_config でポートを変更して sshd サービスを再起動すると、sshd が混乱してしまいました。最終的にサーバー ログを確認したところ (確認できないようです)、sshd はポートがすでに使用されていると文句を言っていました。netstat は同意し、ps は実行中の sshd サービスのインスタンスをいくつか表示しました。それらを強制終了して sshd を再度起動すると、接続できました。問題を解決するために再起動を試みたと断言しますが、おそらく再起動すれば解決したはずなので、そうではないようです。

簡単に言うと、認証のためにポート 2222 でリッスンしているはずの sshd は、実際にリッスンしているのではなく、別の sshd プロセスがリッスンしているのです。私と同じ問題がある場合。

答え4

SSH2_MSG_KEXINIT はエラーではありません。これは、SSH キー交換プロセスを開始していることを通知しているだけです。

その時点で相手側が接続を閉じている場合は、何らかの理由で相手側があなたを嫌っているようです :-) リモート側からのログには、接続が急にシャットダウンされた理由に関する情報が含まれている可能性があります。(たとえば、tcpwrappers)

関連情報