SSHできません：debug1：SSH2_MSG_KEX_DH_GEX_REPLYが必要です
Amazon EC2にサーバーXXXがあります。
SSHは標準（22）ポートで実行されています。
/.ssh/authorized_keysファイルに公開鍵を配置しました
面白いのは、昨日はうまく機能していたということです。
しかし、今日、私は何が起こったのかわかりません！ログインできません。
ssh -vvvvサーバー名
引っかかっている
debug1：SSH2_MSG_KEX_DH_GEX_REPLYが必要です
私は自分のpubkeyを確認しました。 （どのように確認したのですか??他の人に確認するように頼みました）
次に、別のコンピューター（windows 7 + PuTTY）を使用して、新しいpubkeyを配置しました。そして何？ログインできました！そして、それは、Win7を備えた別のコンピュータが同じLAN上にあり、外部IPが同じであることを意味します。
私の秘密鍵は他のサーバーでは機能しますが、これでは機能しません。
助けてください！
それを解決するために、ネットワークインターフェイスMTUを変更します。これは、ubuntu 14.04のバグです。
これは私のために働きました：
Sudo ip li set mtu 1200 dev wlan0
OR
Sudo ifconfig wlan0 mtu 1200
ここでも、online.netデータセンターの専用サーバーにアクセスする場合と同じ問題があります。
再起動後に問題はありません。MTUを変更する必要はなく、ssh接続は1〜3週間機能します。その後、まったく同じバグが表示され、KEXINITでブロックされ、sshサーバーに接続できなくなります。
それはある種のsshdバグである可能性がありますが、1〜3週間後に発生するいくつかのネットワーク障害によって必ず引き起こされます。このネットワーク上の多くの異なるサーバーでこの正確な問題を何度も再現しました。一部のDPIオプションに関連している可能性があります。
この問題は、私が他のデータセンターで管理している他のサーバーでは発生しませんでした。また、ディストリビューション、構成、およびsshdのバージョンがまったく同じです。
データセンターのファイアウォール（または他のネットワークの調整）が奇妙なことをしているために10日ごとに再起動したくない場合：
まず、クライアント側の回避策の1つに接続します。
回避策1、ローカル、クライアント側のMTUを下げる：
ip li set mtu 1400 dev wlan0
（1400で十分ですが、必要に応じて低い値を使用することもできます）
回避策2、ssh接続用に選択した暗号を指定：
ssh -c [email protected] Host
（または他の利用可能な暗号で試してください）
これらのクライアント側の回避策はどちらもうまくいきました。接続して稼働時間を節約できました。しかし、このサーバー側を永久に修正したいので、すべてのクライアントにローカルでMTUを微調整するように依頼する必要はありません。
Gentooで私は追加しました：
mtu_eth0="1400"
/etc/conf.d/net
（同じmtuオプションが、優先するディストリビューションネットワーク構成ファイルのどこかにあるはずです）
私はmtuを1400に設定しましたが、ほとんどの場合、おそらく1460で十分です。
別の助けとなる回避策は、次のiptablesルールを使用して断片化を管理することです。
＃/ sbin/iptables -I OUTPUT -p tcp --tcp-flags SYN、RST SYN -j TCPMSS --clamp-mss-to-pmtu
＃/ sbin/ip6tables -I OUTPUT -p tcp --tcp-flags SYN、RST SYN -j TCPMSS --clamp-mss-to-pmtu
（しかし私は個人的にこれまでこれを必要としませんでした）
また、この問題の症状は次のようになることもあります。
debug1: SSH2_MSG_KEXINIT sent
だけでなく
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
2016年3月に編集：
サーバーでmtuを1400に下げるとほとんどの場合うまくいきますが、最近サーバーでmtuがすでに1400に下げられて問題が再現し、クライアントもmtuを1400に下げる必要があるというケースがありました。
この問題は、「サーバーが接続をリセットした」と言うまでページがリロードされるのを待っているWebログインフォームでも発生し、クライアントがmtUを1400に設定した後で修正されました。
関連リンク ：
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085
https://stackoverflow.com/questions/2419412/ssh-connection-stop-at-debug1-ssh2-msg-kexinit-sent
http://www.1-script.com/forums/ssh/ssh-hang-after-ssh2-msg-kexinit-sent-10616-.htm
私の場合、MTUサイズを下げる権限がありません。また、暗号を手動で指定しても機能しません。
MACリストを指定して、MACリストを短くすると接続できます。例：
ssh -o MACs=hmac-sha2-256 <Host>
Ubuntuクライアントマシンをアップグレードした後も、同じ問題が発生しました。/etc/ssh/ssh_configの「Ciphers」の行のサイズを小さくすることで問題を解決しました。コマンドラインで暗号を指定した場合も機能します（例：ssh -c username @ hostname）
ここからのヒント：
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39
KexAlgorithmの変更 は私にとってはうまくいきましたが、MTU設定を変更するためのシステム権限がない場合のオプションかもしれません。これは、OpenSSHのスタッフが対応する必要がある場合もあります。例えば.
ssh -o KexAlgorithms=ecdh-sha2-nistp521 [email protected]
私は今日、Windows（Gitで配布されたSSH）とUbuntuでこの問題を抱え始めました。
OpenSSHのバグのようです。 LauchPad に問題があります。
Windowsでは3des-cbc暗号とUbuntuではキーを強制しました。