SSH hænger ved SSH2_MSG_KEX_ECDH_REPLY: det er ikke altid MTU

Tunnelen er oppe, banneret ankommer, og klienten udskriver en besked om at vente på nøgleudvekslingssvaret. Søgeresultater peger direkte på MTU, og nogle gange er det rigtigt. Ofte er det ikke: svaret blev måske aldrig sendt, fordi klienten ikke kunne læse en nøglefil, eller fordi parterne aldrig blev enige om en algoritme. Linjen beskriver, hvad klienten venter på, ikke hvorfor ventetiden begyndte. Behandl den som et symptom, og skeln de tre årsager ad, før du ændrer nogen størrelse.

Læs sporet for at se, om der overhovedet var forventet et svar

Det udførlige output viser det sidste vellykkede trin før stilheden. Hvis serverens protokolbanner er ankommet, virker TCP, og den fjerne ende lever; det åbne spørgsmål er, hvad der skete med én bestemt pakke. Et minut stilhed efter banneret ligner et problem med ruten. En besked om ingen matchende nøgleudvekslingsmetode er et politikproblem. En lang ventetid, der ender med, at serveren lukker sessionen, betyder, at serveren gav op, og dens log forklarer hvorfor.

I det sidste tilfælde skal du læse serverens autentificeringslog, før du rører klienten. Klienten kan ikke se en beslutning, serveren aldrig sendte.

Hvorfor et lille svar stadig kan være for stort

Svar på nøgleudveksling er normalt bittesmå, så det lyder forkert at bebrejde størrelsen. Med værtscertifikater er svaret ikke bittesmåt, fordi det bærer serverens certifikatkæde. Det gør det til den første pakke i sessionen, der kan overstige tunnelens brugbare nyttelast. Når feedback fra sti-MTU-opdagelse tabes et sted på ruten, bliver afsenderen ved med at gensende en pakke, der ikke kan passe, og klienten venter evigt på den samme linje.

Fastslå størrelsen i stedet for at antage den. Læs tunnelens MTU med ip link show tun0, og send derefter prober, der ikke må fragmenteres: ping -4 -M do -s 1352 host, gentaget med mindre nyttelaster. En ændring fra fiasko til succes ved en bestemt størrelse er bevis; ensartet fiasko tyder på, at ICMP filtreres, og fortæller dig intet.

En midlertidig reduktion bekræfter teorien hurtigt, og en varig version hører hjemme i profilen eller som et MSS-clamp på routeren, der videresender tunnelen:

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

De to årsager, der efterligner et størrelsesproblem

En nøglefil, klienten ikke kan læse, giver den samme ventetid uden varsel, selv ikke i udførligt output. Ét known_hosts-mønster gør det nemt at ramme: en @cert-authority-post, der peger på en CA-offentlig nøgle, som kun én konto kan læse. Den konto, der ejer filen, opretter forbindelse, og alle andre konti hænger. Hvis fejlen følger brugeren og ikke værten, skal du kontrollere filtilstande før pakkestørrelser.

En opgradering kan også fjerne den algoritme, som begge parter tidligere delte. Fastlås én metode, som serveren stadig tilbyder, som diagnostik: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. En forbindelse, der lykkes med det samme, beviser, at ruten er i orden, og at rettelsen hører hjemme i forhandlingspolitikken på begge sider.

Tre fakta, der er værd at skrive ned

Notér tunnelens MTU før og efter enhver ændring, om kopiering af en stor fil fejler ved en gentagelig størrelse, og om en certifikatfri vært på samme tunnel går i stå på samme måde. De tre observationer skiller størrelse fra rettigheder og fra forhandling hurtigere end en bunke kommandoer.

De forhindrer også den næste person i at sænke MTU på grund af en fejl, der aldrig handlede om størrelse.

Hvis billedet stadig er uklart, så test fra en anden klient på samme tunnel. En klient, der opretter forbindelse, flytter fejlen fra ruten til den første maskines konfiguration.