☰

SSH は SSH2_MSG_KEX_ECDH_REPLY を待っている状態のままです。

tag-icon • tag-icon ssh
SSH は SSH2_MSG_KEX_ECDH_REPLY を待っている状態のままです。

他の国のサーバーでこの問題が発生しました。 mtuを1200から1500の値に変更しましたが、何も変更されませんでした。 opensshを再インストールしましたが、何も起こりませんでした。助けてください。 tnx.HostKeyAlgorithmsを1つのアルゴリズムに強制することも役に立ちません。また、サーバーでsshをテストしましたが、正常に動作します。問題がネットワークパラメータに関連しているようですが、どのパラメータを変更する必要があるのか​​わかりません。

debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [email protected] MAC: <implicit                                                                                                                                                             > compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit                                                                                                                                                             > compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

答え1

私は同じ問題があり、次のように解決しました。

オプション1（使い捨て）：コマンドラインからSSH接続コマンドを送信するときに-o KexAlgorithms=ecdh-sha2-nistp521パラメータを追加します。

オプション2（明確な）：KexAlgorithms=ecdh-sha2-nistp521対応するssh_configファイルに追加

答え2

次の設定を追加した後、SSHが機能し始めました。

[root@RHELSERVER .ssh]# cat /root/.ssh/config
KexAlgorithms diffie-hellman-group18-sha512

答え3

私も同じ問題に直面しました。私の場合、ターゲットSSHサーバーはF5ロードバランサーの背後にありました。
サーバーに直接接続すると正しく機能しますが、ロードバランサーを介しては機能しません。

回避策は、誤ってVIPに割り当てられたhttpプロファイルを削除することです。

答え4

雇用主のITサポートスタッフと私はこの問題を解決するために数時間を費やしました。この問題は、VPN経由で接続されている場合にのみ発生します。ここに公開されているアルゴリズムとMTU関連のソリューションはありません。他の場所で役に立ちました。

この場合、comp-lzo noファイルの指示を使用して圧縮を削除するようにOpenVPN設定ファイルを変更する必要があります（コマンドラインでも使用できます）。これはMTUの問題に関連している可能性がありますが、この問題を解決するために見つけた唯一の解決策です。

これが診断するのが難しい問題に直面している他の人に役立つことを願っています。

関連情報