解決策 1:
ネットワークインターフェースの 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」でハングする
解決策 2:
online.net データセンターの専用サーバーにアクセスする場合とまったく同じ問題です。
再起動後は問題ありません。MTU を変更する必要はありません。ssh 接続は 1 ～ 3 週間機能します。その後、まったく同じバグが発生し、KEXINIT でブロックされ、ssh サーバーに接続できなくなります。
これはある種の sshd バグである可能性がありますが、1 ～ 3 週間後に発生したネットワークの問題が原因である必要があります。このネットワーク上のさまざまなサーバーでこの正確な問題を何度も再現しました。シスコのバグに関連している可能性があると言う人もいます。いくつかの DPI オプションに関連している可能性があります。
この問題は、他のデータセンターで管理している他のサーバーでは発生したことがなく、ディストリビューション、構成、および sshd バージョンがまったく同じです。
データセンターのファイアウォール (またはその他のネットワークの調整) が奇妙なことを行っているため、10 日ごとに再起動したくない場合:
まず、クライアント側の回避策のいずれかに接続します:
回避策 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
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
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
http://www.snailbook.com/faq/mtu-mismatch.auto.html
解決策 3:
私の場合、MTU サイズを下げる権限がありません。また、暗号を手動で指定しても機能しません。
MAC リストを次のように指定して短縮した後、接続できました。
ssh -o MACs=hmac-sha2-256 <HOST>
解決策 4:
Ubuntu クライアント マシンをアップグレードした後、同じ問題が発生しました。 /etc/ssh/ssh_config の「Ciphers」行のサイズを小さくすることで問題を解決しました。コマンドラインで暗号を指定しても機能します (例:ssh -c [email protected])
ここからのヒント:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39
解決策 5:
今日、Windows (Git で配布される ssh) と Ubuntu でこの問題が発生し始めました。
OpenSSH のバグのようです。LauchPad に問題があります。
Windows で 3des-cbc 暗号と Ubuntu のキーを強制することでうまくいきました。