SSH heng ved SSH2_MSG_KEX_ECDH_REPLY: det er ikkje alltid MTU

Tunnelen er oppe, banneret kjem, og klienten skriv ut ei melding om at han ventar på nøkkelutvekslingssvaret. Søkjeresultat peikar rett på MTU, og nokre gonger er det riktig. Ofte er det ikkje: svaret vart kanskje aldri sendt, fordi klienten ikkje kunne lese ei nøkkelfil eller partane aldri vart samde om ein algoritme. Linja skildrar kva klienten ventar på, ikkje kvifor ventinga starta. Handsame ho som eit symptom og skil dei tre årsakene før du endrar nokon storleik.

Les sporet for å sjå om det i det heile var venta eit svar

Den utførlege utdataa viser det siste vellukka steget før stillheita. Viss protokollbanneret til tenaren har kome, verkar TCP og den fjerne enden lever; det opne spørsmålet er kva som hende med éin bestemd pakke. Eitt minutt stillheit etter banneret ser ut som eit ruteproblem. Ei melding om ingen samsvarande nøkkelutvekslingsmetode er eit policyproblem. Ei lang venting som endar med at tenaren lukkar økta, tyder at tenaren gav opp, og loggen hans forklarar kvifor.

I det siste tilfellet, les autentiseringsloggen til tenaren før du rører klienten. Klienten kan ikkje sjå ei avgjerd tenaren aldri sende.

Kvifor eit lite svar likevel kan vere for stort

Nøkkelutvekslingssvar er vanlegvis bitte små, så det høyrest feil ut å skylde på storleiken. Med vertssertifikat er svaret ikkje bitte lite, fordi det ber sertifikatkjeda til tenaren. Det gjer det til den første pakken i økta som kan overskride den brukbare nyttelasta til tunnelen. Når tilbakemeldinga frå sti-MTU-oppdaging går tapt ein stad på ruta, held sendaren fram med å sende på nytt ein pakke som ikkje får plass, og klienten ventar evig på same linje.

Fastset storleiken i staden for å anta han. Les MTU-en til tunnelen med ip link show tun0, send deretter prober som ikkje må fragmenterast: ping -4 -M do -s 1352 host, gjenteke med mindre nyttelaster. Ei endring frå feil til suksess ved ein bestemd storleik er bevis; jamn feil tyder på at ICMP blir filtrert og fortel deg ingenting.

Ei mellombels nedsetjing stadfester teorien raskt, og ein varig versjon høyrer heime i profilen eller som ein MSS-klamp på rutaren 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

Dei to årsakene som etterliknar eit storleiksproblem

Ei nøkkelfil klienten ikkje kan lese, gjev same venting, utan varsel sjølv i utførleg utdata. Eitt known_hosts-mønster gjer dette enkelt: ein @cert-authority-oppføring som peikar på ein offentleg CA-nøkkel som berre éin konto kan lese. Kontoen som eig fila, koplar til, og alle andre kontoar heng. Viss feilen følgjer brukaren og ikkje verten, sjekk filmodusane før pakkestorleikane.

Ei oppgradering kan òg fjerne algoritmen begge partar tidlegare delte. Fest éin metode tenaren framleis tilbyr, som diagnostikk: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Ei tilkopling som lukkast med ein gong, beviser at ruta er i orden, og at rettinga høyrer heime i forhandlingspolitikken på begge sider.

Tre fakta som er verd å skrive ned

Noter MTU-en til tunnelen før og etter kvar endring, om kopiering av ei stor fil feilar ved ein gjentakbar storleik, og om ein vert utan sertifikat på same tunnel heng på same måte. Dei tre observasjonane skil storleik frå tillatingar og frå forhandling raskare enn ein haug med kommandoar.

Dei hindrar òg neste person i å senke MTU på grunn av ein feil som aldri handla om storleik.

Viss biletet framleis er uklart, test frå ein annan klient på same tunnel. Ein klient som koplar til, flyttar feilen frå ruta til konfigurasjonen til den første maskina.