SSH hinget by SSH2_MSG_KEX_ECDH_REPLY: it is net altyd de MTU

De tunnel is oan, de banner komt oan, en de klient printsje in berjocht oer it wachtsjen op it kaai-útwikselingsantwurd. Sykresultaten wize streekrjocht nei de MTU, en soms is dat goed. Faak net: it antwurd is miskien nea stjoerd, om't de klient in kaai-bestân net lêze koe of de kanten it nea iens waarden oer in algoritme. De rigel beskriuwt wêr't de klient op wachtet, net wêrom't it wachtsjen begûn. Behannelje it as in symptoom en skied de trije oarsaken foardat jo hokker grutte dan ek feroarje.

Lês it spoar om te sjen oft der wol in antwurd ferwachte waard

Detaillearre útfier lit de lêste suksesfolle stap foar de stilte sjen. As de protokolbanner fan de tsjinner oankommen is, wurket TCP en libbet de fiere kant; de iepen fraach is wat der mei ien bepaald pakket barde. In minút stilte nei de banner liket op in paadprobleem. In berjocht oer gjin oerienkommende kaai-útwikselingsmetoade is in beliedsprobleem. In lang wachtsjen dat einiget mei it sluten fan de sesje troch de tsjinner betsjut dat de tsjinner opjûn hat, en syn log ferklearret wêrom.

Lês yn it lêste gefal it autentikaasjelog fan de tsjinner foardat jo de klient oanreitsje. De klient kin gjin beslút sjen dat de tsjinner nea stjoerd hat.

Wêrom't in lyts antwurd dochs te grut wêze kin

Antwurden by kaai-útwikseling binne normaal tige lyts, dus de grutte de skuld jaan klinkt ferkeard. Mei host-sertifikaten is it antwurd net lyts, om't it de sertifikaatkeatling fan de tsjinner draacht. Dat makket it it earste pakket yn 'e sesje dat de brûkbere lading fan 'e tunnel oerstekke kin. As de weromkeppeling fan paad-MTU-ûntdekking earne op 'e rûte ferlern giet, bliuwt de stjoerder in pakket weromstjoere dat net past, en de klient wachtet ivich op deselde rigel.

Bepale de grutte ynstee fan it oan te nimmen. Lês de MTU fan 'e tunnel mei ip link show tun0, stjoer dan probes dy't net fragmintearre wurde meie: ping -4 -M do -s 1352 host, werhelle mei lytsere ladingen. In feroaring fan mislearring nei sukses by in bepaalde grutte is bewiis; ienfoarmige mislearring suggerearret dat ICMP filtere wurdt en seit jo neat.

In tydlike ferleging befêstiget de teory fluch, en in duorsume ferzje heart yn it profyl of as in MSS-klamp op 'e router dy't de tunnel trochstjoert:

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 twa oarsaken dy't in grutteprobleem neidogge

In kaai-bestân dat de klient net lêze kin, soarget foar itselde wachtsjen, sûnder warskôging sels yn detaillearre útfier. Ien known_hosts-patroan makket dat maklik: in @cert-authority-ynfier dy't nei in iepenbiere CA-kaai wiist dy't mar ien akkount lêze kin. It akkount dat it bestân besit, ferbynt, en elk oar akkount hinget. As de flater de brûker folget ynstee fan de host, kontrolearje dan bestânsmodi foardat jo nei pakketgruttes sjogge.

In fernijing kin ek it algoritme fuorthelje dat beide kanten earder dielden. Pin ien metoade fêst dy't de tsjinner noch biedt as diagnoaze: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. In ferbining dy't daliks slagget, bewissiget dat it paad goed is en dat de reperaasje yn it ûnderhannelingsbelied oan beide kanten heart.

Trije feiten dy't it opskriuwen wurdich binne

Skriuw de MTU fan 'e tunnel foar en nei elke feroaring op, oft it kopiearjen fan in grut bestân by in werhellbere grutte mislearret en oft in sertifikaatfrije host op deselde tunnel itselde fêst komt te sitten. Dy trije waarnemingen skiede grutte fan rjochten en fan ûnderhanneling flugger as in steapel opdrachten.

Se foarkomme ek dat de folgjende persoan de MTU ferleget foar in flater dy't nea oer grutte gie.

As it byld noch net dúdlik is, test dan fan in twadde klient op deselde tunnel. In klient dy't ferbynt, ferpleatst de flater fan it paad nei de konfiguraasje fan 'e earste masine.