SSH jumittuu viestissä SSH2_MSG_KEX_ECDH_REPLY: syy ei aina ole MTU

Tunneli on pystyssä, banneri saapuu ja asiakas tulostaa viestin avaintenvaihdon vastauksen odottamisesta. Hakutulokset osoittavat suoraan MTU:hun, ja joskus se pitää paikkansa. Usein ei: vastausta ei ehkä koskaan lähetetty, koska asiakas ei voinut lukea avaintiedostoa tai osapuolet eivät koskaan sopineet algoritmista. Rivi kuvaa, mitä asiakas odottaa, ei sitä, miksi odotus alkoi. Käsittele sitä oireena ja erottele kolme syytä ennen minkään koon muuttamista.

Lue jäljitys nähdäksesi odotettiinko vastausta ylipäätään

Yksityiskohtainen tuloste näyttää viimeisen onnistuneen vaiheen ennen hiljaisuutta. Jos palvelimen protokollabanneri on saapunut, TCP toimii ja etäpää on elossa; avoin kysymys on, mitä yhdelle tietylle paketille tapahtui. Minuutti hiljaisuutta bannerin jälkeen näyttää polkuongelmalta. Viesti siitä, ettei sopivaa avaintenvaihtomenetelmää ole, on käytäntöongelma. Pitkä odotus, joka päättyy palvelimen sulkiessa istunnon, tarkoittaa, että palvelin luovutti, ja sen loki kertoo miksi.

Jälkimmäisessä tapauksessa lue palvelimen todennusloki ennen asiakkaan koskemista. Asiakas ei voi nähdä päätöstä, jota palvelin ei koskaan lähettänyt.

Miksi pieni vastaus voi silti olla liian suuri

Avaintenvaihdon vastaukset ovat yleensä pikkuruisia, joten koon syyttäminen kuulostaa väärältä. Isäntävarmennusten kanssa vastaus ei ole pikkuruinen, koska se kuljettaa palvelimen varmenneketjun. Se tekee siitä istunnon ensimmäisen paketin, joka voi ylittää tunnelin käyttökelpoisen hyötykuorman. Kun polun MTU:n havaitsemisen palaute häviää jossain reitillä, lähettäjä lähettää yhä uudelleen pakettia, joka ei mahdu, ja asiakas odottaa ikuisesti samalla rivillä.

Selvitä koko sen sijaan, että olettaisit sen. Lue tunnelin MTU komennolla ip link show tun0 ja lähetä sitten kokeita, joita ei saa pirstoa: ping -4 -M do -s 1352 host, toistettuna pienemmillä kuormilla. Muutos epäonnistumisesta onnistumiseen tietyllä koolla on todiste; tasainen epäonnistuminen viittaa siihen, että ICMP suodatetaan, eikä kerro sinulle mitään.

Tilapäinen pienennys vahvistaa teorian nopeasti, ja pysyvä versio kuuluu profiiliin tai MSS-rajoitukseksi reitittimelle, joka välittää tunnelia:

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

Kaksi syytä, jotka jäljittelevät kokoongelmaa

Avaintiedosto, jota asiakas ei voi lukea, tuottaa saman odotuksen, ilman varoitusta edes yksityiskohtaisessa tulosteessa. Yksi known_hosts-kaava tekee siitä helppoa: @cert-authority-merkintä, joka osoittaa CA:n julkiseen avaimeen, jonka vain yksi tili voi lukea. Tiedoston omistava tili yhdistää, ja kaikki muut tilit jumittuvat. Jos vika seuraa käyttäjää eikä isäntää, tarkista tiedoston oikeudet ennen pakettikokoja.

Päivitys voi myös poistaa algoritmin, jota molemmat osapuolet aiemmin jakoivat. Kiinnitä yksi menetelmä, jota palvelin yhä tarjoaa, diagnostiikkaa varten: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Yhteys, joka onnistuu heti, todistaa, että polku on kunnossa, ja korjaus kuuluu molempien osapuolten neuvottelukäytäntöön.

Kolme tosiasiaa, jotka kannattaa kirjata

Kirjaa tunnelin MTU ennen ja jälkeen minkä tahansa muutoksen, epäonnistuuko suuren tiedoston kopiointi toistuvalla koolla ja jumittuuko saman tunnelin varmennevapaa isäntä samoin. Ne kolme havaintoa erottavat koon käyttöoikeuksista ja neuvottelusta nopeammin kuin pino komentoja.

Ne myös estävät seuraavaa henkilöä laskemasta MTU:ta vian vuoksi, joka ei koskaan johtunut koosta.

Jos kuva on yhä epäselvä, testaa saman tunnelin toisesta asiakkaasta. Yhdistävä asiakas siirtää vian polulta ensimmäisen koneen kokoonpanoon.