SSHできない：debug1：SSH2_MSG_KEX_DH_GEX_REPLYが必要

Amazon EC2にサーバーXXXがあります。

SSHは標準（22）ポートで実行されています。

pubkeyを/.ssh/authorized_keysファイルに配置しました

楽しいのは、昨日は素晴らしい仕事だったということです！

しかし、今日、私は何が起こったのかわかりません！ログインできません。

ssh -vvvvサーバー名

立ち往生している

debug1：SSH2_MSG_KEX_DH_GEX_REPLYが必要です

私はパブキーをチェックしました、それはそこにあります！（チェック方法は??他の人にチェックを頼んだ）

その後、別のコンピューター（windows 7 + putty）を使用して、新しいpubkeyを配置しました。そして何？ログインできました！そして、それはWin7を備えた別のコンピューターであり、外部IPが同じであることを意味する同じLAN上にあります。

私の秘密鍵は他のサーバーでは機能しますが、これでは機能しません。

助けてください！

ネットワークインターフェイスMTUを変更して解決します。これは、ubuntu 14.04のバグです。

これは私のために働いた：

sudo ip li set mtu 1200 dev wlan0

または

sudo ifconfig wlan0 mtu 1200

sshがVPNホストに接続できません-「expecting SSH2_MSG_KEX_ECDH_REPLY」でハングします

ここでも同じ問題があり、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 aes256-gcm@openssh.com 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に下げる必要がありました。

• この問題は、クライアントがmtUを1400に設定した後も修正される「サーバーが接続をリセットしました」と言うまで、ページのリロードを待機するWebログインフォームで発生しました。

  関連リンク ：

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085

http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

https://nowhere.dk/articles/natty-narwhal-problems-connecting-to-servers-behind-cisco-firewalls-using-ssh

/programming/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

http://www.snailbook.com/faq/mtu-mismatch.auto.html

私の場合、MTUサイズを小さくする許可はありません。また、暗号を手動で指定しても機能しません。

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

この問題は、Windows（Gitで配布されるssh）とUbuntuで今日から始まりました。

これはOpenSSHのバグのようです。LauchPadに問題があります。

Windowsで3des-cbc暗号を強制し、Ubuntuでキーを強制しました。

KexAlgorithmの変更は私にとっては有効であり、MTU設定を変更するシステム権限を持っていない場合のオプションかもしれません。これは、OpenSSHの乗組員が対処するものでもあります。例えば

ssh -o KexAlgorithms=ecdh-sha2-nistp521 fu@bar.com

/ etc / ssh / ssh_configのCiphers行をコメントアウトして解決しました

Puttyがキー交換をネゴシエートし、問題を解決する順序を変更したため、オプションダイアログが問題を引き起こすことは明らかです。

cmiiw

• 〜/ .ssh / authorized_keysパーミッションを確認してください、600であるべきです

• / var / log / secure、/ var / log / messages、または/ var / log / authのオンを確認します