Nie można SSH: debugować 1: oczekuje SSH2_MSG_KEX_DH_GEX_REPLY

Mamy serwer XXX na Amazon EC2.

SSH działa na standardowym porcie (22).

Umieściłem mój klucz pub w pliku /.ssh/authorized_keys

Zabawne jest to, że Wczoraj działało świetnie!

Ale dzisiaj nie wiem, co się stało! Po prostu nie mogę się zalogować.

ssh -vvvv nazwa serwera

utknął

debug1: oczekiwanie SSH2_MSG_KEX_DH_GEX_REPLY

Sprawdziłem mój klucz pubowy i już tam jest! (jak sprawdziłem? Poprosiłem drugiego faceta, żeby to sprawdził)

a potem użyłem innego komputera (Windows 7 + kit) i umieściłem mój nowy klucz pub. I co? Mogłem się zalogować! I to jest inny komputer z Win7 jest w tej samej sieci LAN, co oznacza, że ​​zewnętrzny adres IP jest taki sam.

Mój klucz prywatny działa na innych serwerach, ale nie z tym.

Proszę pomóż!

Zmień MTU interfejsu sieciowego, aby go rozwiązać. To jest błąd dla Ubuntu 14.04.

To działało dla mnie:

sudo ip li set mtu 1200 dev wlan0

LUB

sudo ifconfig wlan0 mtu 1200

ssh nie łączy się z hostem VPN - zawiesza się na „oczekując SSH2_MSG_KEX_ECDH_REPLY”

Dokładnie ten sam problem, aby uzyskać dostęp do serwera dedykowanego w centrum danych online.net.

Nie ma problemu po ponownym uruchomieniu, nie trzeba zmieniać MTU, połączenie ssh działa przez 1-3 tygodnie, a następnie pojawia się ten sam błąd, blokuje się na KEXINIT, nie można już połączyć się z serwerem ssh.

Może to być jakiś błąd sshd, ale koniecznie jest on wywoływany przez nowe rzeczy, które dzieją się po 1-3 tygodniach, wiele razy odtworzyłem ten dokładny problem z wieloma różnymi serwerami w tej sieci, niektórzy twierdzą, że może to być związane z błędem cisco, prawdopodobnie związane z niektórymi opcjami DPI.

Ten problem nigdy nie wystąpił w przypadku innych serwerów, którymi zarządzam w innych centrach danych i które mają dokładnie taką samą dystrybucję, konfigurację i wersję sshd.

jeśli nie chcesz restartować co 10 dni, ponieważ zapory w centrum danych (lub inne poprawki sieciowe) robią dziwne rzeczy:

najpierw połącz się z jednym z tych obejść po stronie klienta:

obejście 1, obniżanie lokalnej jednostki MTU po stronie klienta:

ip li set mtu 1400 dev wlan0

(1400 powinno wystarczyć, ale w razie potrzeby możesz spróbować użyć niższych wartości)

obejście 2, określając wybrany szyfr dla połączenia ssh:

ssh -c [email protected] host

(lub spróbuj użyć innego dostępnego szyfru)

Oba te obejścia po stronie klienta dały mi radę, mogłem połączyć się i zaoszczędzić czas pracy; ale chcesz to naprawić po stronie serwera, na zawsze, więc nie musisz prosić każdego klienta o lokalne dostosowanie MTU.

Na Gentoo właśnie dodałem:

mtu_eth0="1400"

w /etc/conf.d/net

(ta sama opcja mtu powinna być dostępna gdzieś w preferowanym pliku konfiguracji sieci dystrybucyjnej)

Ustawiłem mtu na 1400, ale w większości przypadków prawdopodobnie wystarczy 1460.

innym pomocnym obejściem może być użycie następujących reguł iptables do zarządzania fragmentacją:

# / sbin / iptables -I WYJŚCIE -p tcp - tcp-flags SYN, RST SYN -j TCPMSS - clamp-mss-to-pmtu

# / sbin / ip6tables -I WYJŚCIE -p tcp --tcp-flags SYN, RST SYN -j TCPMSS - clamp-mss-to-pmtu

(ale ja osobiście nie potrzebowałem tego do tej pory)

zauważ również, że objawami tego problemu mogą być również:

debug1: SSH2_MSG_KEXINIT sent

nie tylko

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

edytuj marzec 2016:

• obniżenie mtu do 1400 na serwerze najczęściej zawsze działa, ale ostatnio miałem przypadek, w którym mtu został już obniżony do 1400 na serwerze i problem pojawił się ponownie, a klient musiał również obniżyć mtu do 1400.

• Problem pojawił się także w formularzach logowania do sieci, czekając na ponowne załadowanie strony, aż powie „serwer zresetował połączenie”, również naprawiony po tym, jak klient ustawił mtU na 1400.

  powiązane linki :

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

W moim przypadku nie mam uprawnień do obniżenia rozmiaru MTU. I ręczne określenie Szyfru nie działa.

Jestem w stanie połączyć się po skróceniu listy MAC poprzez podanie jednego, np .:

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

Miałem ten sam problem po aktualizacji mojego komputera klienckiego Ubuntu. Rozwiązałem swój problem, zmniejszając rozmiar linii „Szyfrów” w / etc / ssh / ssh_config. Działa również, jeśli podasz szyfr w wierszu polecenia (np .: ssh -c nazwa_użytkownika @ nazwa hosta)

Wskazówka stąd:

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

Zacząłem mieć ten problem dzisiaj w systemie Windows (ssh dystrybuowany z Git) i Ubuntu.

Wygląda na to, że jest to błąd w OpenSSH, jest problem w LauchPad .

Działa dla mnie w systemie Windows, wymuszając szyfr 3des-cbc i klucz w Ubuntu.

Zmiana KexAlgorytmu działała dla mnie i może być opcją, w której nie masz uprawnień systemowych do zmiany ustawień MTU. Może to być także kwestia, którą załoga OpenSSH ma się zająć. na przykład

ssh -o KexAlgorithms=ecdh-sha2-nistp521 [email protected]

rozwiązaliśmy to, komentując linię Ciphers na / etc / ssh / ssh_config

Wydaje się jasne, że okno dialogowe opcji powoduje problem, ponieważ zmieniłem kolejność, w której Putty negocjuje wymianę kluczy i rozwiązany problem.

cmiiw

• sprawdź swoje uprawnienia ~ / .ssh / autoryzowane_klucze, powinno to być 600

• sprawdź on / var / log / secure, / var / log / messages lub / var / log / auth