SSH Macet di SSH2_MSG_KEX_ECDH_REPLY: Tidak Selalu MTU

Tunnel aktif, banner datang, dan klien mencetak pesan tentang menunggu balasan pertukaran kunci. Hasil pencarian langsung menunjuk ke MTU, dan kadang itu benar. Sering kali bukan: balasan mungkin tidak pernah dikirim, karena klien tidak dapat membaca berkas kunci atau kedua ujung tidak pernah sepakat soal algoritme. Baris itu menjelaskan apa yang ditunggu klien, bukan mengapa penantian dimulai. Perlakukan sebagai gejala dan pisahkan tiga penyebabnya sebelum mengubah ukuran apa pun.

Baca jejak untuk melihat apakah balasan memang diharapkan

Keluaran verbose menunjukkan langkah sukses terakhir sebelum keheningan. Jika banner protokol server sudah datang, TCP bekerja dan ujung jauh hidup; pertanyaan terbuka adalah apa yang terjadi pada satu paket tertentu. Satu menit hening setelah banner terlihat seperti masalah jalur. Pesan tentang tidak ada metode pertukaran kunci yang cocok adalah masalah kebijakan. Penantian panjang yang berakhir dengan server menutup sesi berarti server menyerah, dan lognya menjelaskan mengapa.

Pada kasus terakhir, baca log autentikasi server sebelum menyentuh klien. Klien tidak dapat melihat keputusan yang tidak pernah dikirim server.

Mengapa balasan kecil bisa tetap terlalu besar

Balasan pertukaran kunci biasanya sangat kecil, jadi menyalahkan ukuran terdengar salah. Dengan sertifikat host balasan tidak kecil, karena membawa rantai sertifikat server. Itu menjadikannya paket pertama dalam sesi yang dapat melebihi muatan berguna tunnel. Ketika umpan balik penemuan MTU jalur hilang di suatu tempat di rute, pengirim terus mengirim ulang paket yang tidak muat, dan klien menunggu selamanya di baris yang sama.

Tetapkan ukurannya alih-alih mengasumsikannya. Baca MTU tunnel dengan ip link show tun0, lalu kirim probe yang tidak boleh terfragmentasi: ping -4 -M do -s 1352 host, diulang dengan muatan lebih kecil. Perubahan dari gagal menjadi berhasil pada ukuran tertentu adalah bukti; kegagalan seragam menunjukkan ICMP difilter dan tidak memberi tahu apa pun.

Pengurangan sementara mengonfirmasi teori dengan cepat, dan versi permanennya masuk ke profil atau sebagai clamp MSS pada router 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 penyebab yang meniru masalah ukuran

Berkas kunci yang tidak dapat dibaca klien menghasilkan penantian yang sama, tanpa peringatan bahkan di keluaran verbose. Satu pola known_hosts membuatnya mudah: entri @cert-authority yang menunjuk kunci publik CA yang hanya dapat dibaca satu akun. Akun yang memiliki berkas terhubung, dan setiap akun lain macet. Jika kegagalan mengikuti pengguna dan bukan host, periksa mode berkas sebelum ukuran paket.

Peningkatan versi juga dapat menghapus algoritme yang dulu dipakai bersama kedua ujung. Patok satu metode yang masih ditawarkan server sebagai diagnostik: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Koneksi yang langsung berhasil membuktikan jalur baik dan perbaikan ada di kebijakan negosiasi kedua sisi.

Tiga fakta yang layak dicatat

Catat MTU tunnel sebelum dan sesudah setiap perubahan, apakah penyalinan berkas besar gagal pada ukuran yang berulang, dan apakah host tanpa sertifikat di tunnel yang sama juga macet dengan cara yang sama. Tiga pengamatan itu memisahkan ukuran dari izin dan dari negosiasi lebih cepat daripada setumpuk perintah.

Hal itu juga mencegah orang berikutnya menurunkan MTU karena gangguan yang tidak pernah soal ukuran.

Jika gambaran masih kabur, uji dari klien kedua di tunnel yang sama. Klien yang berhasil terhubung memindahkan gangguan dari jalur ke konfigurasi mesin pertama.