SSH henger ved SSH2_MSG_KEX_ECDH_REPLY: det er ikke alltid MTU

Tunnelen er oppe, banneret kommer, og klienten skriver ut en melding om at den venter på nøkkelutvekslingssvaret. Søkeresultater peker rett på MTU, og noen ganger er det riktig. Ofte er det ikke: svaret ble kanskje aldri sendt, fordi klienten ikke kunne lese en nøkkelfil eller partene aldri ble enige om en algoritme. Linjen beskriver hva klienten venter på, ikke hvorfor ventingen startet. Behandle den som et symptom og skill de tre årsakene før du endrer noen størrelse.

Les sporet for å se om det i det hele tatt var ventet et svar

Det utførlige utdataet viser det siste vellykkede trinnet før stillheten. Hvis serverens protokollbanner har kommet, virker TCP og den fjerne enden lever; det åpne spørsmålet er hva som skjedde med én bestemt pakke. Ett minutts stillhet etter banneret ser ut som et ruteproblem. En melding om ingen samsvarende nøkkelutvekslingsmetode er et policyproblem. En lang venting som ender med at serveren lukker økten, betyr at serveren ga opp, og loggen forklarer hvorfor.

I det siste tilfellet, les serverens autentiseringslogg før du rører klienten. Klienten kan ikke se en beslutning serveren aldri sendte.

Hvorfor et lite svar likevel kan være for stort

Nøkkelutvekslingssvar er vanligvis bittesmå, så det høres feil ut å skylde på størrelsen. Med vertssertifikater er svaret ikke bittesmått, fordi det bærer serverens sertifikatkjede. Det gjør det til den første pakken i økten som kan overskride tunnelens brukbare nyttelast. Når tilbakemeldingen fra sti-MTU-oppdagelse går tapt et sted på ruten, fortsetter avsenderen å sende på nytt en pakke som ikke får plass, og klienten venter evig på samme linje.

Fastslå størrelsen i stedet for å anta den. Les tunnelens MTU med ip link show tun0, og send deretter prober som ikke må fragmenteres: ping -4 -M do -s 1352 host, gjentatt med mindre nyttelaster. En endring fra feil til suksess ved en bestemt størrelse er bevis; jevn feil tyder på at ICMP filtreres og forteller deg ingenting.

En midlertidig reduksjon bekrefter teorien raskt, og en varig versjon hører hjemme i profilen eller som en MSS-klamp på ruteren som 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 årsakene som etterligner et størrelsesproblem

En nøkkelfil klienten ikke kan lese, gir samme venting, uten varsel selv i utførlig utdata. Ett known_hosts-mønster gjør dette enkelt: en @cert-authority-oppføring som peker på en offentlig CA-nøkkel som bare én konto kan lese. Kontoen som eier filen, kobler til, og alle andre kontoer henger. Hvis feilen følger brukeren og ikke verten, sjekk filmodusene før pakkestørrelsene.

En oppgradering kan også fjerne algoritmen begge parter tidligere delte. Fest én metode serveren fortsatt tilbyr, som diagnostikk: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. En tilkobling som lykkes umiddelbart, beviser at ruten er i orden, og at rettelsen hører hjemme i forhandlingspolitikken på begge sider.

Tre fakta som er verdt å skrive ned

Noter tunnelens MTU før og etter enhver endring, om kopiering av en stor fil feiler ved en gjentakbar størrelse, og om en vert uten sertifikat på samme tunnel henger på samme måte. De tre observasjonene skiller størrelse fra tillatelser og fra forhandling raskere enn en haug med kommandoer.

De hindrer også neste person i å senke MTU på grunn av en feil som aldri handlet om størrelse.

Hvis bildet fortsatt er uklart, test fra en annen klient på samme tunnel. En klient som kobler til, flytter feilen fra ruten til den første maskinens konfigurasjon.