خلاصه سریع: اگر سرور لینوکسی شما OpenSSH جدید دارد، احتمالاً همین حالا از تبادل کلید هیبریدی پساکوانتومی پشتیبانی میکند. OpenSSH اعلام میکند که الگوریتم mlkem768x25519-sha256 از نسخه 10.0 به انتخاب پیشفرض تبدیل شده و نسخه 10.5 نیز در ۱۱ اوت ۲۰۲۶ منتشر شده است. با این حال «پشتیبانی» با «استفاده واقعی در هر اتصال» یکسان نیست؛ نسخه کلاینت، نسخه سرور، تنظیمات و سازگاری دو سمت تعیین میکنند کدام الگوریتم مذاکره شود.
SSH پساکوانتومی یعنی چه؟
در SSH، پیش از اینکه دادههای نشست رمز شود، کلاینت و سرور روی یک روش تبادل کلید توافق میکنند. نگرانی بلندمدت این است که رایانههای کوانتومی قدرتمند بتوانند بخشی از رمزنگاری کلیدعمومی رایج را تضعیف کنند. رویکرد OpenSSH استفاده از تبادل کلید هیبریدی است؛ یعنی یک سازوکار پساکوانتومی در کنار یک الگوریتم کلاسیک استفاده میشود تا امنیت اتصال تنها به یک خانواده رمزنگاری وابسته نباشد.
طبق مستند رسمی OpenSSH، پشتیبانی پیشفرض از تبادل کلید مقاوم در برابر حملات کوانتومی از OpenSSH 9.0 آغاز شد. سپس mlkem768x25519-sha256 در OpenSSH 9.9 اضافه شد و از OpenSSH 10.0 به الگوریتم پیشفرض تبدیل شد.
چرا این موضوع برای مدیر VPS مهم است؟
SSH در بسیاری از VPSها درگاه اصلی مدیریت است. اگر مهاجمی امروز ترافیک رمزشده را ذخیره کند، ممکن است در آینده و با پیشرفت محاسبات کوانتومی تلاش کند آن را رمزگشایی کند؛ سناریویی که معمولاً با عبارت harvest now, decrypt later شناخته میشود. برای اطلاعاتی که عمر محرمانگی طولانی دارند، مهاجرت زودتر به الگوریتمهای مقاومتر منطقی است.
این موضوع جایگزین اصول پایه امنیت SSH نیست. استفاده از کلید بهجای رمز عبور، محدودکردن دسترسی root، فایروال، بهروزرسانی امنیتی و مانیتورینگ لاگها همچنان اولویت دارند. برای چکلیست کاملتر میتوانید راهنمای امنسازی VPS لینوکس در سال ۲۰۲۶ را هم بخوانید.
نسخه OpenSSH را بررسی کنید
ssh -V
sshd -V 2>&1 | head -1خروجی دقیق به توزیع شما بستگی دارد. نکته مهم این است که نسخه بسته سیستمعامل را با مستندات همان توزیع مقایسه کنید؛ برخی توزیعها وصلههای امنیتی را backport میکنند و صرفاً پایینتر بودن شماره نسخه به معنی ناامن بودن بسته نیست.
الگوریتمهای تبادل کلید موجود را ببینید
ssh -Q kexاگر در خروجی mlkem768x25519-sha256 یا الگوریتمهای هیبریدی پساکوانتومی را میبینید، کلاینت شما قابلیت استفاده از آنها را دارد. برای دیدن تنظیمات مؤثر کلاینت نیز میتوانید اجرا کنید:
ssh -G example.com | grep -i kexalgorithmsچطور بفهمیم اتصال واقعاً از PQC استفاده کرده است؟
بهجای حدسزدن از روی نسخه، یک اتصال verbose بگیرید:
ssh -vv [email protected]در خروجی به خط مربوط به kex یا KEX نگاه کنید. این روش نشان میدهد دو سمت در همان اتصال روی چه الگوریتمی توافق کردهاند. اگر الگوریتم پساکوانتومی مذاکره نشده، ممکن است یکی از دو سمت قدیمی باشد یا تنظیمات سفارشی، ترتیب الگوریتمها را تغییر داده باشد.
آیا باید KexAlgorithms را دستی تغییر دهیم؟
در اغلب سرورهای بهروز، دستکاری عجولانه KexAlgorithms لازم نیست و حتی میتواند کلاینتهای قدیمی یا ابزارهای اتوماسیون را از دسترس خارج کند. مسیر کمریسکتر این است که ابتدا قابلیت دو سمت را بررسی کنید، اتصال را با -vv تست کنید و فقط زمانی policy را محدود کنید که فهرست کلاینتهای مجاز و نیازهای سازگاری را میشناسید.
قبل از هر تغییر در /etc/ssh/sshd_config یک نشست SSH دوم باز نگه دارید و کانفیگ را اعتبارسنجی کنید:
sudo sshd -tاگر دستور بدون خروجی تمام شود، معمولاً syntax کانفیگ معتبر است. سپس روش reload سرویس را مطابق توزیع خود اجرا کنید. هیچوقت اتصال فعلی را قبل از تست ورود در یک نشست دوم نبندید.
کلید ورود SSH با تبادل کلید نشست فرق دارد
یکی از خطاهای رایج این است که «کلید SSH کاربر» با «Key Exchange» یکی فرض شود. کلیدهایی مثل Ed25519 برای احراز هویت شما استفاده میشوند، در حالی که KEX برای ساخت راز مشترک نشست است. پس فعال بودن یک KEX پساکوانتومی به این معنی نیست که همه اجزای احراز هویت SSH شما پساکوانتومی شدهاند.
پیکربندی پیشنهادی امنیت SSH در ۲۰۲۶
برای یک VPS عمومی، اولویت عملی این است: سیستمعامل و OpenSSH را بهروز نگه دارید؛ ورود مبتنی بر کلید را فعال کنید؛ بعد از اطمینان از ورود با کلید، PasswordAuthentication را در صورت سازگاری سناریوی خود غیرفعال کنید؛ ورود مستقیم root را محدود کنید؛ دسترسی پورت SSH را با فایروال یا allowlist کنترل کنید؛ و لاگهای authentication را مانیتور کنید.
تغییر پورت SSH میتواند حجم نویز اسکنهای خودکار را کم کند، اما کنترل امنیتی اصلی محسوب نمیشود. امنیت واقعی باید روی احراز هویت قوی، محدودسازی سطح دسترسی و بهروزرسانی بنا شود.
OpenSSH 10.5 چه جایگاهی دارد؟
طبق Release Notes رسمی، OpenSSH 10.5 در تاریخ ۱۱ اوت ۲۰۲۶ منتشر شده است. در سرورهای production بهتر است بهجای کامپایل شتابزده نسخه upstream، ابتدا بستههای رسمی و advisory توزیع لینوکس خود را بررسی کنید. Debian، Ubuntu، AlmaLinux، Rocky Linux و سایر توزیعها چرخه انتشار و backport متفاوتی دارند.
چکلیست مهاجرت بدون قطعی
- نسخه کلاینت و سرور را ثبت کنید.
- با
ssh -Q kexقابلیتهای کلاینت را ببینید. - با
ssh -vvالگوریتم مذاکرهشده واقعی را بررسی کنید. - کلاینتهای قدیمی، CI/CD، بکاپ و مانیتورینگ متصل به SSH را شناسایی کنید.
- قبل از محدودکردن الگوریتمها، تست staging یا یک نشست دوم داشته باشید.
- بعد از تغییر،
sshd -tو ورود واقعی را تست کنید. - تنها پس از موفقیت تست، policy سختگیرانهتر را عمومی کنید.
ارتباط SSH امن با استقرار خودکار
اگر از GitHub Actions برای Deploy استفاده میکنید، تغییر policy الگوریتمهای SSH میتواند روی Runner یا Action مورد استفاده اثر بگذارد. قبل از حذف الگوریتمهای قدیمی، pipeline را تست کنید. راهنمای استقرار خودکار روی VPS با GitHub Actions و SSH برای این سناریو مفید است.
پرسشهای متداول
آیا SSH معمولی الان ناامن است؟
خیر. موضوع پساکوانتومی بیشتر مدیریت ریسک آینده است. در تهدیدهای روزمره، رمز عبور ضعیف، کلید خصوصی لورفته، نرمافزار قدیمی و دسترسی بیشازحد معمولاً خطر فوریتری هستند.
آیا OpenSSH 10.0 به بعد بهصورت خودکار PQC دارد؟
OpenSSH الگوریتم هیبریدی mlkem768x25519-sha256 را از نسخه 10.0 پیشفرض کرده است، اما الگوریتم نهایی هر اتصال با مذاکره بین کلاینت و سرور تعیین میشود. آن را با ssh -vv تأیید کنید.
آیا باید همین امروز همه الگوریتمهای کلاسیک را حذف کنیم؟
معمولاً نه. حذف بدون inventory و تست ممکن است دسترسی ابزارهای قدیمی را قطع کند. مهاجرت مرحلهای و مشاهدهپذیر انتخاب امنتری است.
آیا کلید Ed25519 همان رمزنگاری پساکوانتومی است؟
خیر. Ed25519 معمولاً برای امضای احراز هویت یا host key استفاده میشود و با الگوریتم تبادل کلید هیبریدی پساکوانتومی یک چیز نیست.
جمعبندی
مهاجرت SSH به دوران پساکوانتومی دیگر یک موضوع صرفاً آزمایشگاهی نیست. OpenSSH چند سال است KEXهای مقاوم در برابر حملات کوانتومی را ارائه میکند و در نسل 10.x استفاده از ML-KEM هیبریدی را به مسیر پیشفرض آورده است. برای مدیر سرور، بهترین اقدام امروز این نیست که کانفیگ را کورکورانه سختتر کند؛ بلکه باید نسخهها و الگوریتم واقعی اتصال را اندازه بگیرد، سازگاری را تست کند و سپس policy را مرحلهای ارتقا دهد.