SSH2_MSG_KEX_ECDH_REPLY で SSH が止まる：原因はいつも MTU とは限らない

トンネルは上がり、バナーも届き、クライアントは鍵交換の返信を待っているというメッセージを出します。検索結果は MTU をまっすぐ指し、それが正しいこともあります。多くの場合は違います：クライアントが鍵ファイルを読めなかった、あるいは両端がアルゴリズムで合意できなかったために、返信が一度も送られていない可能性があります。この行はクライアントが何を待っているかを示すもので、待機が始まった理由ではありません。症状として扱い、サイズを変える前に三つの原因を切り分けてください。

トレースを読み、返信がそもそも期待されていたかを見る

詳細出力には、沈黙の直前の最後に成功した手順が表示されます。サーバーのプロトコルバナーが届いていれば TCP は機能しており、遠端は生きていますが、残る疑問は特定の一つのパケットに何が起きたかです。バナーの後に一分間の沈黙があれば、経路の問題に見えます。一致する鍵交換方式がないというメッセージは方針の問題です。サーバーがセッションを閉じて長い待機が終わるなら、サーバーが諦めたということで、そのログが理由を説明します。

最後の場合は、クライアントに触れる前にサーバーの認証ログを読んでください。サーバーが送らなかった決定をクライアントが見ることはできません。

小さな返信がそれでも大きすぎる理由

鍵交換の返信はふつうごく小さいので、サイズを疑うのは筋違いに聞こえます。ホスト証明書があると、返信はサーバーの証明書チェーンを運ぶため小さくありません。そのため、セッション内でトンネルの有効ペイロードを超えうる最初のパケットになります。経路 MTU 探索のフィードバックが途中で失われると、送信側は収まらないパケットを再送し続け、クライアントは同じ行で永久に待ちます。

サイズを仮定せずに確かめる。トンネルの MTU を ip link show tun0 で読み、次に、断片化されてはならないプローブを ping -4 -M do -s 1352 host として送り、より小さなペイロードで繰り返します。特定のサイズで失敗から成功に変わることは証拠であり、一様な失敗は ICMP がフィルタされていることを示すだけで、何も教えてくれません。

一時的な引き下げは理論をすぐに裏付け、恒久的な版はプロファイルに入れるか、トンネルを転送するルーターの MSS クランプとして設定します:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

サイズの問題に見せかける二つの原因

クライアントが読めない鍵ファイルは、詳細出力でも警告なしに同じ待機を生みます。known_hosts のあるパターンでこれは簡単に起こります：一つのアカウントしか読めない CA 公開鍵を指す @cert-authority の項目です。そのファイルを所有するアカウントは接続でき、ほかのどのアカウントも止まります。失敗がホストではなくユーザーに付いて回るなら、パケットサイズより先にファイルのモードを確認してください。

アップグレードで、両端が以前共有していたアルゴリズムが消えることもあります。サーバーがまだ提供している一つの方式、具体的には ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host を診断として固定します。すぐに成功する接続は経路が正常であることを示し、修正は両側のネゴシエーション方針に属します。

書き留める価値のある三つの事実

変更の前後でトンネルの MTU を記録し、大きなファイルのコピーが再現性のあるサイズで失敗するか、同じトンネル上の証明書なしのホストも同じように止まるかを記録します。その三つの観察は、コマンドの山より速く、サイズを権限やネゴシエーションから切り分けます。

それはまた、サイズが原因でなかった不具合のために次の人が MTU を下げるのを防ぎます。

状況がまだ不明なら、同じトンネルの二台目のクライアントから試してください。接続できるクライアントは、不具合を経路から最初のマシンの設定へ移します。