SSH zawiesza się na SSH2_MSG_KEX_ECDH_REPLY: to nie zawsze MTU

Tunel działa, baner dociera, a klient wypisuje komunikat o oczekiwaniu na odpowiedź wymiany kluczy. Wyniki wyszukiwania wskazują prosto na MTU i czasami jest to słuszne. Często nie: odpowiedź mogła nigdy nie zostać wysłana, ponieważ klient nie mógł odczytać pliku klucza albo strony nigdy nie uzgodniły algorytmu. Wiersz opisuje, na co czeka klient, a nie dlaczego oczekiwanie się zaczęło. Traktuj to jako objaw i oddziel trzy przyczyny, zanim zmienisz jakikolwiek rozmiar.

Przeczytaj ślad, aby sprawdzić, czy w ogóle oczekiwano odpowiedzi

Szczegółowe dane wyjściowe pokazują ostatni udany krok przed ciszą. Jeśli baner protokołu serwera dotarł, TCP działa, a zdalna strona żyje; otwarte pytanie brzmi, co stało się z jednym konkretnym pakietem. Minuta ciszy po banerze wygląda na problem ścieżki. Komunikat o braku pasującej metody wymiany kluczy to problem polityki. Długie oczekiwanie zakończone zamknięciem sesji przez serwer oznacza, że serwer się poddał, a jego dziennik wyjaśnia dlaczego.

W tym ostatnim przypadku przeczytaj dziennik uwierzytelniania serwera, zanim dotkniesz klienta. Klient nie może zobaczyć decyzji, której serwer nigdy nie wysłał.

Dlaczego mała odpowiedź może jednak być za duża

Odpowiedzi wymiany kluczy są zwykle maleńkie, więc obwinianie rozmiaru brzmi błędnie. Z certyfikatami hosta odpowiedź nie jest maleńka, bo niesie łańcuch certyfikatów serwera. To czyni ją pierwszym pakietem sesji, który może przekroczyć użyteczny ładunek tunelu. Gdy informacja zwrotna wykrywania MTU ścieżki ginie gdzieś po drodze, nadawca wciąż ponownie wysyła pakiet, który się nie mieści, a klient czeka wiecznie w tej samej linii.

Ustal rozmiar, zamiast go zakładać. Odczytaj MTU tunelu za pomocą ip link show tun0, następnie wyślij sondy, które nie mogą być fragmentowane: ping -4 -M do -s 1352 host, powtarzane z mniejszymi ładunkami. Zmiana z porażki w sukces przy określonym rozmiarze jest dowodem; równomierna porażka sugeruje, że ICMP jest filtrowany, i nic ci nie mówi.

Tymczasowe obniżenie szybko potwierdza teorię, a trwała wersja należy do profilu lub jako ograniczenie MSS na routerze przekazującym tunel:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Dwie przyczyny imitujące problem rozmiaru

Plik klucza, którego klient nie może odczytać, daje to samo oczekiwanie, bez ostrzeżenia nawet w szczegółowych danych wyjściowych. Jeden wzorzec known_hosts to ułatwia: wpis @cert-authority wskazujący publiczny klucz CA, który może odczytać tylko jedno konto. Konto będące właścicielem pliku łączy się, a każde inne konto zawiesza się. Jeśli błąd podąża za użytkownikiem, a nie za hostem, sprawdź uprawnienia pliku przed rozmiarami pakietów.

Aktualizacja może też usunąć algorytm, który obie strony wcześniej dzieliły. Przypnij jedną metodę, którą serwer nadal oferuje, jako diagnostykę: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Połączenie, które od razu się udaje, dowodzi, że ścieżka jest w porządku, a poprawka należy do polityki negocjacji po obu stronach.

Trzy fakty warte zapisania

Zapisz MTU tunelu przed każdą zmianą i po niej, czy kopiowanie dużego pliku zawodzi przy powtarzalnym rozmiarze i czy host bez certyfikatu w tym samym tunelu zawiesza się tak samo. Te trzy obserwacje oddzielają rozmiar od uprawnień i od negocjacji szybciej niż stos poleceń.

Powstrzymują też następną osobę przed obniżeniem MTU z powodu usterki, która nigdy nie dotyczyła rozmiaru.

Jeśli obraz nadal jest niejasny, przetestuj z drugiego klienta w tym samym tunelu. Klient, który się łączy, przenosi usterkę ze ścieżki do konfiguracji pierwszej maszyny.