SSH hänger vid SSH2_MSG_KEX_ECDH_REPLY: det är inte alltid MTU

Tunneln är uppe, bannern kommer och klienten skriver ut ett meddelande om att den väntar på nyckelutbytessvaret. Sökresultat pekar rakt på MTU, och ibland är det rätt. Ofta inte: svaret kanske aldrig skickades, eftersom klienten inte kunde läsa en nyckelfil eller parterna aldrig kom överens om en algoritm. Raden beskriver vad klienten väntar på, inte varför väntan började. Behandla den som ett symptom och skilj de tre orsakerna innan du ändrar någon storlek.

Läs spåret för att se om ett svar överhuvudtaget förväntades

Det utförliga utdata visar det sista lyckade steget före tystnaden. Om serverns protokollbanner har anlänt fungerar TCP och fjärränden lever; den öppna frågan är vad som hände med ett specifikt paket. En minuts tystnad efter bannern ser ut som ett vägproblem. Ett meddelande om ingen matchande nyckelutbytesmetod är ett policyproblem. En lång väntan som slutar med att servern stänger sessionen betyder att servern gav upp, och dess logg förklarar varför.

I det sista fallet, läs serverns autentiseringslogg innan du rör klienten. Klienten kan inte se ett beslut som servern aldrig skickade.

Varför ett litet svar ändå kan vara för stort

Svar vid nyckelutbyte är vanligtvis pyttesmå, så att skylla på storleken låter fel. Med värdcertifikat är svaret inte pyttesmått, eftersom det bär serverns certifikatkedja. Det gör det till det första paketet i sessionen som kan överskrida tunnelns användbara nyttolast. När återkopplingen från väg-MTU-upptäckten tappas någonstans på vägen fortsätter avsändaren att skicka om ett paket som inte får plats, och klienten väntar för evigt på samma rad.

Fastställ storleken i stället för att anta den. Läs tunnelns MTU med ip link show tun0, skicka sedan prober som inte får fragmenteras: ping -4 -M do -s 1352 host, upprepade med mindre nyttolaster. En ändring från misslyckande till framgång vid en viss storlek är bevis; enhetligt misslyckande tyder på att ICMP filtreras och säger dig ingenting.

En tillfällig sänkning bekräftar teorin snabbt, och en bestående version hör hemma i profilen eller som en MSS-klämma på routern som vidarebefordrar tunneln:

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 två orsakerna som imiterar ett storleksproblem

En nyckelfil som klienten inte kan läsa ger samma väntan, utan varning även i utförligt utdata. Ett known_hosts-mönster gör detta enkelt: en @cert-authority-post som pekar på en offentlig CA-nyckel som bara ett konto kan läsa. Kontot som äger filen ansluter, och varje annat konto hänger. Om felet följer användaren och inte värden, kontrollera filmoder innan paketstorlekar.

En uppgradering kan också ta bort algoritmen som båda sidor tidigare delade. Fäst en metod som servern fortfarande erbjuder som diagnostik: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. En anslutning som lyckas direkt bevisar att vägen är i ordning och att rättelsen hör hemma i förhandlingspolicyn på båda sidor.

Tre fakta som är värda att skriva ner

Notera tunnelns MTU före och efter varje ändring, om kopiering av en stor fil misslyckas vid en repeterbar storlek och om en värd utan certifikat på samma tunnel hänger på samma sätt. De tre observationerna skiljer storlek från behörigheter och från förhandling snabbare än en hög kommandon.

De hindrar också nästa person från att sänka MTU på grund av ett fel som aldrig handlade om storlek.

Om bilden fortfarande är oklar, testa från en andra klient på samma tunnel. En klient som ansluter flyttar felet från vägen till den första maskinens konfiguration.