SFTP 接続が「SSH2_MSG_KEXINIT が送信されました」でハングする

SFTP 接続が「SSH2_MSG_KEXINIT が送信されました」でハングする

オンプレミス サーバーから SFTP 経由で AWS テスト アカウントに接続するのに苦労しています。

プライベート SSH キーがあるディレクトリに cd して実行すると、sftp -v -i <private_key_file> <client>@<hostname>次の結果が表示されます。

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to <hostname> [<IP Adress>] port 22.
debug1: Connection established.
debug1: identity file <private_key_file> type 1
debug1: key_load_public: No such file or directory
debug1: identity file <private_key_file>-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1
debug1: no match: AWS_SFTP_1.1
debug1: Authenticating to <hostname>:22 as 'client'
debug1: SSH2_MSG_KEXINIT sent

そして、ずっと後になって私はCouldn't read packet: Connection reset by peer.

奇妙なことに、同じオンプレミス サーバーから AWS 開発アカウントに同じ接続を行うと、正常に機能します。AWS テスト環境では、これが機能しません。明らかに、AWS テスト環境にあるクライアントに別の公開キーを割り当て、上記のコマンドで新しい秘密キーを参照しています。

どのような助けでも本当にありがたいです。

答え1

SSH がその後フリーズするのは、SSH2_MSG_KEXINIT sentMTU に問題があることを示す確かな兆候です。

Path MTU Discovery は、MTU を自動的に決定するはずです。ただし、間にあるファイアウォール ルールや両端のオペレーティング システムによっては、機能しない場合があります。

パス MTU 検出が機能しない場合は、MTU を手動で設定する必要があります。

最初は 1400 から始めて、機能する範囲内で最高値まで上げていくことをお勧めします。

MTU を設定し、変更を永続化する方法の詳細は、オペレーティング システムによって異なります。

関連情報