SSH Tersekat pada SSH2_MSG_KEX_ECDH_REPLY: Bukan Selalu MTU

Tunnel aktif, banner tiba, dan klien mencetak mesej tentang menunggu balasan pertukaran kunci. Hasil carian terus menunjuk kepada MTU, dan kadangkala itu betul. Selalunya tidak: balasan mungkin tidak pernah dihantar, kerana klien tidak dapat membaca fail kunci atau kedua-dua hujung tidak pernah bersetuju tentang algoritma. Baris itu menerangkan apa yang ditunggu oleh klien, bukan mengapa penantian bermula. Anggapnya sebagai gejala dan asingkan tiga punca sebelum mengubah apa-apa saiz.

Baca jejak untuk melihat sama ada balasan memang dijangka

Output terperinci menunjukkan langkah berjaya terakhir sebelum kesunyian. Jika banner protokol pelayan telah tiba, TCP berfungsi dan hujung jauh masih hidup; soalan terbuka ialah apa yang berlaku kepada satu paket tertentu. Seminit kesunyian selepas banner kelihatan seperti masalah laluan. Mesej tentang tiada kaedah pertukaran kunci yang sepadan ialah masalah dasar. Penantian panjang yang berakhir dengan pelayan menutup sesi bermakna pelayan menyerah, dan lognya menjelaskan mengapa.

Dalam kes terakhir, baca log pengesahan pelayan sebelum menyentuh klien. Klien tidak dapat melihat keputusan yang tidak pernah dihantar oleh pelayan.

Mengapa balasan kecil masih boleh terlalu besar

Balasan pertukaran kunci biasanya sangat kecil, jadi menyalahkan saiz kedengaran salah. Dengan sijil hos balasan tidak kecil, kerana ia membawa rantaian sijil pelayan. Itu menjadikannya paket pertama dalam sesi yang boleh melebihi muatan berguna tunnel. Apabila maklum balas penemuan MTU laluan hilang di suatu tempat di laluan, penghantar terus menghantar semula paket yang tidak muat, dan klien menunggu selama-lamanya pada baris yang sama.

Tentukan saiznya dan bukan menganggapnya. Baca MTU tunnel dengan ip link show tun0, kemudian hantar prob yang tidak boleh difragmen: ping -4 -M do -s 1352 host, diulang dengan muatan lebih kecil. Perubahan daripada gagal kepada berjaya pada saiz tertentu ialah bukti; kegagalan seragam menunjukkan ICMP ditapis dan tidak memberitahu anda apa-apa.

Pengurangan sementara mengesahkan teori dengan cepat, dan versi kekal terletak dalam profil atau sebagai clamp MSS pada penghala yang meneruskan 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

Dua punca yang meniru masalah saiz

Fail kunci yang tidak dapat dibaca oleh klien menghasilkan penantian yang sama, tanpa amaran walaupun dalam output terperinci. Satu corak known_hosts memudahkannya: entri @cert-authority yang menunjuk kepada kunci awam CA yang hanya boleh dibaca oleh satu akaun. Akaun yang memiliki fail itu bersambung, dan setiap akaun lain tersekat. Jika kegagalan mengikut pengguna dan bukan hos, periksa mod fail sebelum saiz paket.

Naik taraf juga boleh membuang algoritma yang dahulunya dikongsi kedua-dua hujung. Tetapkan satu kaedah yang masih ditawarkan pelayan sebagai diagnostik: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Sambungan yang berjaya serta-merta membuktikan laluan baik dan pembaikan terletak pada dasar rundingan kedua-dua pihak.

Tiga fakta yang wajar dicatat

Catat MTU tunnel sebelum dan selepas setiap perubahan, sama ada salinan fail besar gagal pada saiz yang berulang, dan sama ada hos tanpa sijil pada tunnel yang sama turut tersekat dengan cara yang sama. Tiga pemerhatian itu memisahkan saiz daripada kebenaran dan daripada rundingan lebih cepat daripada timbunan arahan.

Ia juga menghalang orang seterusnya daripada menurunkan MTU kerana kerosakan yang tidak pernah berkaitan saiz.

Jika gambaran masih kabur, uji daripada klien kedua pada tunnel yang sama. Klien yang bersambung memindahkan kerosakan daripada laluan kepada konfigurasi mesin pertama.