تعليق SSH عند SSH2_MSG_KEX_ECDH_REPLY: المشكلة ليست دائمًا MTU

النفق قائم، واللافتة تصل، والعميل يطبع رسالة عن انتظار رد تبادل المفاتيح. توجّه نتائج البحث إلى MTU مباشرة، وأحيانًا يكون ذلك صحيحًا. غالبًا لا يكون: فقد لا يُرسل الرد أبدًا، لأن العميل لم يستطع قراءة ملف مفتاح أو لأن الطرفين لم يتفقا على خوارزمية. السطر يصف ما ينتظره العميل، لا سبب بدء الانتظار. تعامل معه كعرض، وافصل الأسباب الثلاثة قبل تغيير أي حجم.

اقرأ التتبع لتعرف هل كان الرد متوقعًا أصلًا

يُظهر الخرج المفصّل آخر خطوة ناجحة قبل الصمت. إذا وصلت لافتة بروتوكول الخادم، فـ TCP يعمل والطرف البعيد حي؛ والسؤال المفتوح هو ما حدث لحزمة واحدة محددة. دقيقة من الصمت بعد اللافتة تبدو مشكلة مسار. ورسالة عن عدم وجود طريقة تبادل مفاتيح مطابقة مشكلة سياسة. والانتظار الطويل الذي ينتهي بإغلاق الخادم للجلسة يعني أن الخادم استسلم، وسجله يوضح السبب.

في الحالة الأخيرة، اقرأ سجل مصادقة الخادم قبل لمس العميل. لا يستطيع العميل رؤية قرار لم يرسله الخادم قط.

لماذا قد يكون الرد الصغير كبيرًا جدًا رغم ذلك

ردود تبادل المفاتيح صغيرة عادةً، لذا يبدو لوم الحجم خطأً. مع شهادات المضيف لم يعد الرد صغيرًا، لأنه يحمل سلسلة شهادات الخادم. وهذا يجعله أول حزمة في الجلسة قد تتجاوز الحمولة القابلة للاستخدام في النفق. عندما تُسقط تغذية اكتشاف MTU للمسار في مكان ما على الطريق، يظل المرسل يعيد إرسال حزمة لا يمكن أن تمر، وينتظر العميل إلى الأبد عند السطر نفسه.

أثبت الحجم بدلًا من افتراضه. اقرأ MTU النفق باستخدام ip link show tun0، ثم أرسل اختبارات يجب ألا تتجزأ: ping -4 -M do -s 1352 host، مكررة بحمولات أصغر. التحول من الفشل إلى النجاح عند حجم محدد دليل؛ أما الفشل المنتظم فيشير إلى أن ICMP مُرشَّح ولا يخبرك بشيء.

التخفيض المؤقت يؤكد النظرية بسرعة، والنسخة الدائمة مكانها في الملف الشخصي أو كحاصر MSS على الموجه الذي يمرر النفق:

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

السببان اللذان يحاكيان مشكلة حجم

ملف مفتاح لا يستطيع العميل قراءته ينتج الانتظار نفسه، دون تحذير حتى في الخرج المفصّل. أحد أنماط known_hosts يجعل ذلك سهلًا: مدخل @cert-authority يشير إلى مفتاح عام لجهة شهادة لا يستطيع سوى حساب واحد قراءته. الحساب الذي يملك الملف يتصل، وكل حساب آخر يتعلق. إذا اتبع الفشل المستخدم لا المضيف، فافحص أذونات الملف قبل أحجام الحزم.

قد تزيل الترقية أيضًا الخوارزمية التي كان الطرفان يشتركان فيها. ثبّت طريقة واحدة لا يزال الخادم يعرضها كأداة تشخيص: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. الاتصال الذي ينجح فورًا يثبت أن المسار سليم وأن الإصلاح مكانه في سياسة التفاوض عند الطرفين.

ثلاث حقائق تستحق التدوين

سجّل MTU النفق قبل أي تغيير وبعده، وهل يفشل نسخ ملف كبير عند حجم قابل للتكرار، وهل يتوقف مضيف بلا شهادة على النفق نفسه بالطريقة ذاتها. تلك الملاحظات الثلاث تفصل الحجم عن الأذونات وعن التفاوض أسرع من كومة أوامر.

وهي أيضًا تمنع الشخص التالي من خفض MTU بسبب خلل لم يكن يومًا عن الحجم.

إذا ظلت الصورة غير واضحة، فاختبر من عميل ثانٍ على النفق نفسه. العميل الذي يتصل ينقل الخلل من المسار إلى إعدادات الجهاز الأول.