گیر کردن 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 که به کلید عمومی CA اشاره می‌کند و فقط یک حساب می‌تواند آن را بخواند. حسابی که مالک فایل است متصل می‌شود و هر حساب دیگری گیر می‌کند. اگر شکست به‌جای میزبان کاربر را دنبال کند، پیش از اندازه بسته‌ها حالت‌های فایل را بررسی کنید.

به‌روزرسانی می‌تواند الگوریتمی را هم که دو طرف پیش‌تر مشترک داشتند حذف کند. یک روش را که سرور هنوز ارائه می‌دهد به‌عنوان تشخیص ثابت کنید: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. اتصالی که فوراً موفق شود ثابت می‌کند مسیر درست است و اصلاح به سیاست مذاکره در هر دو طرف تعلق دارد.

سه واقعیتی که ارزش نوشتن دارند

MTU تونل را پیش و پس از هر تغییر ثبت کنید، اینکه کپی یک فایل بزرگ در اندازه‌ای تکرارپذیر شکست می‌خورد یا نه، و اینکه میزبان بدون گواهی در همان تونل به‌شکل یکسان گیر می‌کند یا نه. آن سه مشاهده اندازه را از مجوزها و از مذاکره سریع‌تر از انبوهی از فرمان‌ها جدا می‌کند.

همچنین مانع می‌شوند که نفر بعدی MTU را به‌خاطر نقصی که هرگز درباره اندازه نبود کاهش دهد.

اگر تصویر هنوز روشن نیست، از کلاینت دومی در همان تونل آزمایش کنید. کلاینتی که وصل می‌شود نقص را از مسیر به پیکربندی ماشین اول منتقل می‌کند.