SSH se blochează la SSH2_MSG_KEX_ECDH_REPLY: nu este întotdeauna MTU

Tunelul este activ, bannerul sosește, iar clientul tipărește un mesaj despre așteptarea răspunsului schimbului de chei. Rezultatele căutării indică direct MTU, și uneori asta este corect. Adesea nu: răspunsul poate să nu fi fost trimis niciodată, pentru că clientul nu a putut citi un fișier de cheie sau cele două capete nu au căzut niciodată de acord asupra unui algoritm. Linia descrie la ce așteaptă clientul, nu de ce a început așteptarea. Tratați-o ca simptom și separați cele trei cauze înainte de a schimba orice dimensiune.

Citiți urma pentru a vedea dacă se aștepta vreun răspuns

Ieșirea detaliată arată ultimul pas reușit înainte de tăcere. Dacă bannerul de protocol al serverului a sosit, TCP funcționează și capătul îndepărtat este viu; întrebarea deschisă este ce s-a întâmplat cu un anumit pachet. Un minut de tăcere după banner arată ca o problemă de cale. Un mesaj despre niciun metodă de schimb de chei potrivită este o problemă de politică. O așteptare lungă care se termină cu serverul închizând sesiunea înseamnă că serverul a renunțat, iar jurnalul său explică de ce.

În ultimul caz, citiți jurnalul de autentificare al serverului înainte de a atinge clientul. Clientul nu poate vedea o decizie pe care serverul nu a trimis-o niciodată.

De ce un răspuns mic poate fi totuși prea mare

Răspunsurile schimbului de chei sunt de obicei minuscule, așa că a da vina pe dimensiune sună greșit. Cu certificate de gazdă răspunsul nu este minuscul, pentru că poartă lanțul de certificate al serverului. Asta îl face primul pachet din sesiune care poate depăși sarcina utilă a tunelului. Când feedback-ul descoperirii MTU a căii se pierde undeva pe rută, expeditorul continuă să retrimită un pachet care nu încape, iar clientul așteaptă veșnic pe aceeași linie.

Determinați dimensiunea în loc să o presupuneți. Citiți MTU-ul tunelului cu ip link show tun0, apoi trimiteți sonde care nu trebuie fragmentate: ping -4 -M do -s 1352 host, repetate cu sarcini mai mici. O schimbare de la eșec la succes la o anumită dimensiune este o dovadă; eșecul uniform sugerează că ICMP este filtrat și nu vă spune nimic.

O reducere temporară confirmă rapid teoria, iar o versiune durabilă aparține profilului sau unui clamp MSS pe routerul care redirecționează tunelul:

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

Cele două cauze care imită o problemă de dimensiune

Un fișier de cheie pe care clientul nu îl poate citi produce aceeași așteptare, fără avertisment chiar și în ieșirea detaliată. Un model known_hosts face asta ușor: o intrare @cert-authority care indică o cheie publică CA pe care doar un cont o poate citi. Contul care deține fișierul se conectează, iar orice alt cont se blochează. Dacă eșecul urmează utilizatorul și nu gazda, verificați modurile fișierului înainte de dimensiunile pachetelor.

O actualizare poate elimina și algoritmul pe care ambele capete îl împărțeau anterior. Fixați o singură metodă pe care serverul încă o oferă ca diagnostic: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. O conexiune care reușește imediat dovedește că calea este în regulă și că remedierea aparține politicii de negociere de ambele părți.

Trei fapte care merită notate

Notați MTU-ul tunelului înainte și după orice modificare, dacă copierea unui fișier mare eșuează la o dimensiune repetabilă și dacă o gazdă fără certificat pe același tunel se blochează la fel. Acele trei observații separă dimensiunea de permisiuni și de negociere mai repede decât un teanc de comenzi.

Ele împiedică și următoarea persoană să reducă MTU pentru o defecțiune care nu a fost niciodată despre dimensiune.

Dacă imaginea este încă neclară, testați de la un al doilea client pe același tunel. Un client care se conectează mută defecțiunea de pe cale în configurația primei mașini.