SSH olamaz: hata ayıklama1: SSH2_MSG_KEX_DH_GEX_REPLY bekleniyor

XXX ON Amazon EC2 sunucumuz var.

SSH standart (22) bir portta çalışıyor.

Pubkey'imi /.ssh/authorized_keys dosyasına yerleştirdim

İşin eğlenceli yanı, YESTERDAY harika çalışıyordu!

Ama bugün, ne oldu bilmiyorum! Sadece giriş yapamıyorum.

ssh -vvvv sunucu adı

sıkışmış

hata ayıklama1: SSH2_MSG_KEX_DH_GEX_REPLY bekleniyor

Pubkey'imi kontrol ettim ve orada! (nasıl kontrol ettim? diğerinden kontrol etmesini istedim)

sonra başka bir bilgisayar kullandım (Windows 7 + Macun) ve yeni pubkeyimi yerleştirdim. Ve ne? Giriş yapabildim! Ve Win7'ye sahip başka bir bilgisayar, harici IP'nin aynı olduğunu gösteren, aynı LAN değil.

Özel anahtarım diğer sunucular için çalışıyor, ancak bununla değil.

Lütfen yardım et!

Çözmek için MTU ağ arayüzünü değiştirin. Bu, ubuntu 14.04 için bir hatadır.

Bu benim için çalıştı:

sudo ip li set mtu 1200 dev wlan0

VEYA

sudo ifconfig wlan0 mtu 1200

ssh VPN ana bilgisayarına bağlanamadı - 'SSH2_MSG_KEX_ECDH_REPLY bekliyor'

Online.net veri merkezinde özel bir sunucuya erişmek için burada aynı sorun.

Bir yeniden başlatma işleminden sonra sorun yok, MTU’ya gerek yok, ssh bağlantısı 1-3 hafta çalışıyor, sonra KEXINIT’de engelleme aynı ssh sunucusunu bağlamak mümkün değil.

Bir tür sshd hatası olabilir, ancak mutlaka 1-3 hafta sonra meydana gelen bazı nework olayları ile tetiklenir, bu kesin sorunu birçok kez bu ağdaki birçok farklı sunucu ile çoğalttım, bazıları bunun cisco hatasıyla ilişkili olabileceğini söylüyor. muhtemelen bazı DPI seçenekleriyle ilgilidir.

Bu problem, diğer veri merkezlerinde yönettiğim diğer sunucularda asla yaşanmadı ve bu aynı dağıtım, config ve sshd versiyonlarına sahipti.

Veri merkezi güvenlik duvarları (veya diğer ağ tweaks'ları) garip şeyler yaptığı için her 10 günde bir yeniden başlatmak istemiyorsanız:

ilk önce bu istemci tarafı geçici çözümlerinden birine bağlanın:

geçici çözüm 1, yerel, istemci tarafınız MTU’yu düşürün:

ip li set mtu 1400 dev wlan0

(1400 yeterli olmalı, ancak gerekirse daha düşük değerler kullanmaya çalışabilirsiniz)

geçici çözüm 2, ssh bağlantısı için seçilen şifreyi belirterek:

ssh -c aes256-gcm@openssh.com host

(veya başka bir mevcut şifreyle deneyin)

Her iki müşteri tarafı geçici çözümü benim için yaptı, bağlanabilir ve çalışma zamanımı koruyabilirdim; ancak bu sunucu tarafını sonsuza dek düzeltmek istersiniz, bu yüzden her müşteriden MTU'larını yerel olarak ayarlamasını istemeniz gerekmez.

Gentoo'da az önce ekledim:

mtu_eth0="1400"

/etc/conf.d/net içinde

(aynı mtu seçeneği, tercih ettiğiniz dağıtım ağı yapılandırma dosyasında bir yerde bulunmalıdır)

Mtu değerini 1400 olarak belirledim, ancak çoğu durumda 1460 yeterlidir.

Başka bir yardım çözümü, parçalanmayı yönetmek için aşağıdaki iptables kurallarını kullanmak olabilir:

# / sbin / iptables -I ÇIKIŞ -p tcp - tcp-bayraklar SYN, RST SYN -j TCPMSS - clamp-mss-to-pmtu

# / sbin / ip6tables -I ÇIKIŞ -p tcp - tcp-bayraklar SYN, RST SYN -j TCPMSS - clamp-mss-to-pmtu

(ama şahsen ben şimdiye kadar buna ihtiyacım yoktu)

Ayrıca bu sorunun belirtilerinin de olabileceğini unutmayın:

debug1: SSH2_MSG_KEXINIT sent

sadece

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

mart 2016’yı düzenle:

• mtu'yu sunucuda 1400'e düşürmek her zaman işe yarar, ancak son zamanlarda mtu'nun sunucuda 1400'e düşürüldüğü ve sorunun yeniden ortaya çıktığı ve müşterinin de mtu'yu 1400'e düşürdüğü bir durum vardı.

• Bu sorun ayrıca, müşterinin MTU’yu 1400’e ayarlamasından sonra düzelten "sunucu bağlantıyı sıfırladı" diyene kadar sayfanın yeniden yüklenmesini bekleyen web oturum açma formlarında da ortaya çıktı.

  İlgili Bağlantılar :

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

Benim durumumda, MTU boyutunu düşürmek için iznim yok. Ve şifreyi el ile belirlemek işe yaramaz.

Birini belirterek MAC listesini kısaltdıktan sonra bağlanabiliyorum, örneğin:

ssh -o MACs=hmac-sha2-256 <HOST>

Ubuntu istemci makinemi yükselttikten sonra da aynı sorunu yaşadım. / Etc / ssh / ssh_config içindeki "Ciphers" satırının boyutunu küçülterek sorunumu çözdüm. Ayrıca, şifreyi komut satırında belirtirseniz de çalışır (örneğin: ssh -c kullaniciadi @ hostname)

Buradan ipucu:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493/comments/39

Bugün bu sorunu Windows (Git ile birlikte dağıtılan ssh) ve Ubuntu'da yaşamaya başladım.

OpenSSH'de bir hata olduğu anlaşılıyor , LauchPad'de bir sorun var .

Benim için Windows'ta çalıştı, 3des-cbc şifresini ve Ubuntu'daki anahtarı zorladı.

KexAlgorithm'i değiştirmek benim için çalıştı ve MTU ayarlarını değiştirmek için sistem haklarına sahip olmadığınız bir seçenek olabilir. Bu aynı zamanda OpenSSH ekibinin ele alması gerekenlerden biri olabilir. Örneğin

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

/ etc / ssh / ssh_config üzerindeki Şifreler satırını yorumlayarak çözdük

Seçenekler diyaloğunun bir soruna yol açtığı açık görünüyor, çünkü Putty'nin anahtar değişimi ve sorunu çözme şeklini değiştirdim.

cmiiw

• ~ / .ssh / official_keys iznini kontrol et, 600 olmalı

• / var / log / secure, / var / log / messages veya / var / log / auth adresinde açık durumu kontrol edin