SSH, SSH2_MSG_KEX_ECDH_REPLY aşamasında takılıyor: sebep her zaman MTU değil

Tünel çalışıyor, banner geliyor ve istemci anahtar değişimi yanıtını beklediğine dair bir mesaj yazdırıyor. Arama sonuçları doğrudan MTU'yu işaret ediyor ve bazen bu doğru. Çoğu zaman değil: yanıt hiç gönderilmemiş olabilir, çünkü istemci bir anahtar dosyasını okuyamadı ya da iki uç bir algoritma üzerinde hiç anlaşamadı. Satır, istemcinin neyi beklediğini anlatır, beklemenin neden başladığını değil. Bunu bir belirti olarak ele alın ve herhangi bir boyutu değiştirmeden önce üç nedeni ayırın.

Bir yanıtın baştan beklenip beklenmediğini görmek için izi okuyun

Ayrıntılı çıktı, sessizlikten önceki son başarılı adımı gösterir. Sunucunun protokol bannerı geldiyse TCP çalışıyor ve uzak uç canlı; açık soru, belirli bir pakete ne olduğu. Bannerdan sonraki bir dakikalık sessizlik yol sorunu gibi görünür. Eşleşen anahtar değişim yöntemi olmadığına dair mesaj bir ilke sorunudur. Sunucunun oturumu kapatmasıyla biten uzun bekleme, sunucunun pes ettiği anlamına gelir ve günlüğü nedenini açıklar.

Son durumda, istemciye dokunmadan önce sunucunun kimlik doğrulama günlüğünü okuyun. İstemci, sunucunun hiç göndermediği bir kararı göremez.

Küçük bir yanıt neden yine de çok büyük olabilir

Anahtar değişimi yanıtları genellikle çok küçüktür, bu yüzden boyutu suçlamak yanlış gelir. Ana bilgisayar sertifikalarıyla yanıt küçük değildir, çünkü sunucunun sertifika zincirini taşır. Bu onu oturumda tünelin kullanılabilir yükünü aşabilecek ilk paket yapar. Yol MTU keşfinin geri bildirimi rotanın bir yerinde kaybolduğunda, gönderici sığmayan paketi tekrar tekrar gönderir ve istemci aynı satırda sonsuza kadar bekler.

Boyutu varsaymak yerine belirleyin. Tünelin MTU'sunu ip link show tun0 ile okuyun, ardından parçalanmaması gereken sondalar gönderin: ping -4 -M do -s 1352 host, daha küçük yüklerle tekrarlayın. Belirli bir boyutta başarısızlıktan başarıya geçiş kanıttır; tekdüze başarısızlık ICMP'nin filtrelendiğini gösterir ve size hiçbir şey söylemez.

Geçici bir düşürme teoriyi hızla doğrular ve kalıcı sürüm profile ya da tüneli ileten yönlendiricideki bir MSS sınırlamasına aittir:

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

Boyut sorununu taklit eden iki neden

İstemcinin okuyamadığı bir anahtar dosyası aynı beklemeyi yaratır, ayrıntılı çıktıda bile uyarı vermez. Bir known_hosts deseni bunu kolaylaştırır: yalnızca bir hesabın okuyabildiği bir CA ortak anahtarına işaret eden @cert-authority girdisi. Dosyanın sahibi olan hesap bağlanır, diğer her hesap takılır. Arıza ana bilgisayarı değil kullanıcıyı izliyorsa, paket boyutlarından önce dosya izinlerini kontrol edin.

Bir yükseltme, iki ucun önceden paylaştığı algoritmayı da kaldırabilir. Sunucunun hâlâ sunduğu tek bir yöntemi tanı olarak sabitleyin: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Hemen başarılı olan bir bağlantı yolun iyi olduğunu ve düzeltmenin iki tarafın müzakere ilkesinde olduğunu kanıtlar.

Yazmaya değer üç gerçek

Herhangi bir değişiklikten önce ve sonra tünelin MTU'sunu, büyük bir dosya kopyasının tekrarlanabilir bir boyutta başarısız olup olmadığını ve aynı tüneldeki sertifikasız bir ana bilgisayarın da aynı şekilde takılıp takılmadığını kaydedin. Bu üç gözlem, boyutu izinlerden ve müzakereden bir komut yığınından daha hızlı ayırır.

Ayrıca bir sonraki kişinin hiçbir zaman boyutla ilgili olmayan bir arıza yüzünden MTU'yu düşürmesini engeller.

Resim hâlâ net değilse, aynı tüneldeki ikinci bir istemciden test edin. Bağlanan istemci arızayı yoldan ilk makinenin yapılandırmasına taşır.