Naghihintay ang SSH sa SSH2_MSG_KEX_ECDH_REPLY: hindi laging MTU

Buhay ang tunnel, dumarating ang banner, at naglalabas ang kliyente ng mensahe tungkol sa paghihintay sa sagot ng palitan ng susi. Direktang tumuturo sa MTU ang mga resulta ng paghahanap, at kung minsan tama iyon. Madalas hindi: maaaring hindi kailanman naipadala ang sagot, dahil hindi mabasa ng kliyente ang isang key file o hindi kailanman nagkasundo ang dalawang dulo sa isang algorithm. Inilalarawan ng linya kung ano ang hinihintay ng kliyente, hindi kung bakit nagsimula ang paghihintay. Ituring itong sintomas at ihiwalay ang tatlong sanhi bago baguhin ang anumang laki.

Basahin ang trace upang makita kung may inaasahang sagot

Ipinapakita ng detalyadong output ang huling matagumpay na hakbang bago ang katahimikan. Kung dumating ang protocol banner ng server, gumagana ang TCP at buhay ang malayong dulo; ang bukas na tanong ay kung ano ang nangyari sa isang partikular na packet. Ang isang minutong katahimikan pagkatapos ng banner ay mukhang problema sa ruta. Ang mensaheng walang tugmang paraan ng palitan ng susi ay problema sa patakaran. Ang mahabang paghihintay na nagtatapos sa pagsasara ng session ng server ay nangangahulugang sumuko ang server, at ipinapaliwanag ng log nito kung bakit.

Sa huling kaso, basahin ang authentication log ng server bago hawakan ang kliyente. Hindi makikita ng kliyente ang desisyong hindi kailanman ipinadala ng server.

Bakit ang maliit na sagot ay maaaring masyadong malaki

Ang mga sagot sa palitan ng susi ay karaniwang napakaliit, kaya ang pagsisi sa laki ay mukhang mali. Sa mga host certificate, hindi maliit ang sagot, dahil dinadala nito ang certificate chain ng server. Ginagawa nitong unang packet sa session na maaaring lumampas sa magagamit na payload ng tunnel. Kapag nawala sa isang lugar sa ruta ang feedback ng pagtuklas ng path MTU, patuloy na ipinapadala ng nagpadala ang packet na hindi kasya, at ang kliyente ay naghihintay magpakailanman sa parehong linya.

Tukuyin ang laki sa halip na ipagpalagay. Basahin ang MTU ng tunnel gamit ang ip link show tun0, pagkatapos ay magpadala ng mga probe na hindi dapat i-fragment: ping -4 -M do -s 1352 host, paulit-ulit na may mas maliliit na payload. Ang pagbabago mula sa pagkabigo tungo sa tagumpay sa isang tiyak na laki ay ebidensya; ang pantay na pagkabigo ay nagmumungkahi na sinasala ang ICMP at wala itong sinasabi sa iyo.

Ang pansamantalang pagbaba ay mabilis na nagpapatunay sa teorya, at ang pangmatagalang bersyon ay nabibilang sa profile o bilang MSS clamp sa router na nagpapasa ng tunnel:

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

Ang dalawang sanhi na ginagaya ang problema sa laki

Ang key file na hindi mabasa ng kliyente ay gumagawa ng parehong paghihintay, walang babala kahit sa detalyadong output. Isang pattern sa known_hosts ang nagpapadali nito: isang entry na @cert-authority na tumuturo sa pampublikong key ng CA na isang account lang ang makakabasa. Kumokonekta ang account na may-ari ng file, at bawat ibang account ay nag-hang. Kung sinusundan ng pagkabigo ang user at hindi ang host, tingnan ang mga mode ng file bago ang mga laki ng packet.

Maaari ring alisin ng upgrade ang algorithm na dating pinagsasaluhan ng dalawang dulo. I-pin ang isang paraan na inaalok pa ng server bilang diagnostic: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Ang koneksyong agad na nagtagumpay ay nagpapatunay na maayos ang ruta at ang pagwawasto ay nasa patakaran ng negosasyon sa magkabilang panig.

Tatlong katotohanang sulit isulat

Itala ang MTU ng tunnel bago at pagkatapos ng anumang pagbabago, kung nabigo ang pagkopya ng malaking file sa paulit-ulit na laki, at kung ang host na walang certificate sa parehong tunnel ay nag-hang din nang pareho. Ang tatlong obserbasyon ay naghihiwalay sa laki mula sa mga pahintulot at sa negosasyon nang mas mabilis kaysa sa isang tumpok ng mga utos.

Pinipigilan din nila ang susunod na tao na ibaba ang MTU dahil sa isang depektong hindi kailanman tungkol sa laki.

Kung malabo pa rin ang larawan, subukan mula sa pangalawang kliyente sa parehong tunnel. Ang kliyenteng kumokonekta ay naglilipat ng depekto mula sa ruta patungo sa configuration ng unang makina.