بررسی وضعیت SSH پساکوانتومی در اوبونتو

تغییرات در SSH پساکوانتومی

SSH پساکوانتومی برای اکثر کاربران فعال شده است و نیازی به پیکربندی دستی توسط کسی نبوده است. یک کلاینت OpenSSH امروزی هنگام برقراری ارتباط با یک سرور OpenSSH امروزی، به‌صورت پیش‌فرض از یک تبادل کلید هیبریدی پساکوانتومی استفاده می‌کند؛ بنابراین کلید نشست در برابر مهاجمی که ترافیک شما را امروز ضبط کرده و قصد دارد سال‌ها بعد آن را رمزگشایی کند، مقاوم است. این محافظت واقعی است، اما محدودتر از آن چیزی است که عبارت "SSH امن در برابر کوانتوم" القا می‌کند.

ابتدا دو اصطلاح را تعریف می‌کنیم. SSH (مخفف secure shell) پروتکلی است که با آن به یک سرور وارد می‌شوید. تبادل کلید که معمولاً به صورت "kex" نوشته می‌شود، اولین گام در هر اتصال SSH است: دو طرف بر سر یک راز مشترک به توافق می‌رسند و آن راز، تمام داده‌های بعدی را رمزگذاری می‌کند. بخشی که تغییر کرده، همین تبادل کلید است. هیچ چیز دیگری تغییر نکرده است.

به این صفحه اعتماد نکنید، دستورات را اجرا کنید

هر نام الگوریتمی که در ادامه می‌آید، خروجی دستوری است که می‌توانید خودتان اجرا کنید. این موضوع عمدی است. تنظیمات پیش‌فرض با هر نسخه از OpenSSH تغییر می‌کند؛ بنابراین راهنمایی که دو سال پیش نوشته شده، الگوریتمی را نام می‌برد که ماشین شما دیگر آن را ترجیح نمی‌دهد و راهی برای اطلاع‌رسانی به شما ندارد. این دستورات را یاد بگیرید تا دیگر نیازی به مقالات در این زمینه، از جمله همین مقاله، نداشته باشید.

با آنچه build شما قادر به انجام آن است، شروع کنید.

ssh -V
ssh -Q kex

ssh -V یک خط نسخه را چاپ می‌کند که با OpenSSH_ شروع می‌شود و پس از آن پسوند بسته Ubuntu و نسخه OpenSSL قرار دارد. ssh -Q kex در هر خط یک الگوریتم تبادل کلید را چاپ می‌کند. در یک build با پشتیبانی از پساکوانتوم (post-quantum)، نام‌هایی مانند mlkem768x25519-sha256 و sntrup761x25519-sha512@openssh.com را در آن لیست خواهید یافت که در کنار نام‌های کلاسیک مانند curve25519-sha256 قرار گرفته‌اند.

تفاوت میان قابلیت‌های ساخت و آنچه ارائه می‌شود

این همان تمایزی است که اکثر مطالب از آن می‌گذرند. ssh -Q kex به یک پرسش پاسخ می‌دهد: این فایل باینری چه کاری می‌تواند انجام دهد. این دستور به پرسشی که برای شما اهمیت دارد پاسخ نمی‌دهد: این اتصال در عمل چه چیزی را پیشنهاد خواهد کرد. این دو لیست با هم متفاوت هستند و شکاف میان آن‌ها همان جایی است که توصیه‌های قدیمی آسیب واقعی وارد می‌کنند.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> پیکربندی مؤثر کلاینت برای آن میزبان را، پس از اعمال ~/.ssh/config و /etc/ssh/ssh_config، چاپ می‌کند. sshd -T همین کار را برای سرور انجام می‌دهد. هر کدام یک خط kexalgorithms را به ترتیب اولویت چاپ می‌کنند و اولین نام در آن، نخستین انتخاب آن سمت است. همان خط است که روی شبکه ارسال می‌شود.

این شکاف صرفاً نظری نیست. OpenSSH 8.5 که در تاریخ 2021-03-03 منتشر شد، sntrup761x25519-sha512@openssh.com را اضافه کرد و عمداً آن را از لیست پیش‌فرض کنار گذاشت. در آن نسخه، ssh -Q kex الگوریتم را نشان می‌دهد اما ssh -G آن را نمایش نمی‌دهد؛ این یعنی فایل باینری می‌تواند تبادل کلید پساکوانتومی انجام دهد، اما هیچ اتصالی هرگز آن را درخواست نمی‌کند.

مشاهده الگوریتم توافق‌شده در اتصال

ssh -v example.com 2>&1 | grep 'kex: algorithm'

بین یک کلاینت به‌روز و یک سرور به‌روز، خروجی به این صورت خواهد بود:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 یک الگوریتم ترکیبی است. این الگوریتم از ML-KEM (مکانیزم کپسوله‌سازی کلید مبتنی بر شبکه ماژولار که با استاندارد FIPS 203 شناخته می‌شود) با پارامتر 768، در کنار X25519 (تبادل کلید Diffie-Hellman بر پایه منحنی بیضوی) استفاده کرده و خروجی هر دو را برای تولید کلید نشست ترکیب می‌کند.

در مواجهه با یک سرور قدیمی‌تر، ممکن است خروجی زیر را مشاهده کنید:

debug1: kex: algorithm: curve25519-sha256

این نام فاقد بخش پساکوانتومی است. curve25519-sha256 صرفاً از تبادل کلید Diffie-Hellman بر پایه منحنی بیضوی استفاده می‌کند و یک کامپیوتر کوانتومی بزرگ می‌تواند آن را بشکند. دقیقاً به همین دلیل است که تنظیمات پیش‌فرض تغییر کرده است.

یک قانون در توافق‌نامه توضیح می‌دهد که چرا یک ماشین قدیمی می‌تواند سطح امنیت نشست را پایین نگه دارد. کلاینت لیست خود را به ترتیب اولویت ارسال می‌کند، سرور نیز لیست خود را می‌فرستد و الگوریتم انتخاب‌شده، اولین نامی است که در لیست کلاینت وجود دارد و در لیست سرور نیز دیده می‌شود. اولویت کلاینت تعیین‌کننده است، بنابراین طرف قدیمی‌ترِ ارتباط مشخص می‌کند که تا چه حد در لیست پیش بروید. ارتقای لپ‌تاپ شما باعث نمی‌شود نشست با سروری که نامی از ML-KEM نشنیده است، ارتقا یابد.

دانستن ssh -v فراتر از این یک خط اهمیت دارد، زیرا همین خروجی جایی است که می‌توانید خطای Permission denied (publickey) را ردیابی کنید، زمانی که ورود به‌طور کامل رد می‌شود.

با حذف grep و استفاده از ssh -v، مابقی فرآیند توافق نمایش داده می‌شود، از جمله خطی که بخش بعدی به آن می‌پردازد:

debug1: kex: host key algorithm: ssh-ed25519

کدام نسخه از OpenSSH تبادل هیبریدی را به حالت پیش‌فرض درآورد

یادداشت‌های انتشار نسخه اصلی، توالی مشخصی را ارائه می‌دهند. تاریخ‌ها از شماره نسخه‌ها اهمیت بیشتری دارند، زیرا نشان می‌دهند که این قابلیت چه مدت به‌صورت بی‌سروصدا در حال اجرا بوده است.

• نسخه 8.5، منتشرشده در 2021-03-03، قابلیت sntrup761x25519-sha512@openssh.com را اضافه کرد و آن را به‌صورت پیش‌فرض غیرفعال گذاشت.
• نسخه 9.0، منتشرشده در 2022-04-08، آن را فعال کرد. یادداشت‌ها بیان می‌کنند که OpenSSH «به‌طور پیش‌فرض از روش تبادل کلید هیبریدی Streamlined NTRU Prime + x25519 استفاده خواهد کرد». این همان نسخه‌ای است که در آن تبادل کلید پساکوانتومی به حالت عادی تبدیل شد.
• نسخه 9.9، منتشرشده در 2024-09-19، قابلیت mlkem768x25519-sha256 را به‌عنوان گزینه دوم اضافه کرد. همین نسخه به روش قدیمی‌تر، نام ثبت‌شده در IANA یعنی sntrup761x25519-sha512 را اختصاص داد، بنابراین بیلد‌های جدیدتر آن را با هر دو نام فهرست می‌کنند.
• نسخه 10.0، منتشرشده در 2025-04-09، قابلیت mlkem768x25519-sha256 را به گزینه پیش‌فرض برای توافق کلید تبدیل کرد.
• نسخه 10.1، منتشرشده در 2025-10-06، یک هشدار کلاینت اضافه کرد که هنگام مذاکره برای تبادل کلید بدون بخش پساکوانتومی نمایش داده می‌شود. این قابلیت توسط گزینه WarnWeakCrypto در ssh_config کنترل می‌شود و به‌صورت پیش‌فرض فعال است.

آوریل 2022 تاریخی است که ارزش به‌خاطر سپردن دارد. هر جفت ماشینی که OpenSSH 9.0 یا جدیدتر را اجرا می‌کنند، از آن زمان تاکنون بدون نیاز به پیکربندی و بدون اطلاع به کاربری که دستور ssh را تایپ می‌کند، تبادل کلید پساکوانتومی انجام می‌دهند.

کدام نسخه Ubuntu آن را ارائه می‌دهد

Ubuntu نسخه OpenSSH را در زمان انتشار ثابت نگه می‌دارد و سپس اصلاحات امنیتی را بدون تغییر شماره نسخه، به آن backport می‌کند. بنابراین، نسخه Ubuntu که اجرا می‌کنید، الگوریتم پیش‌فرض شما را تعیین می‌کند. به‌جای اعتماد به یک لیست، دستگاه مقابل خود را با ssh -V بررسی کنید. از اوت 2026، آرشیو شامل این نسخه‌ها است:

• نسخه 22.04 LTS شامل 1:8.9p1 است که قدیمی‌تر از پیش‌فرض 9.0 است، بنابراین یک نصب استاندارد از curve25519-sha256 استفاده می‌کند.
• نسخه 24.04 LTS شامل 1:9.6p1 است که پس از 9.0 و پیش از 9.9 قرار دارد، بنابراین پیش‌فرض آن sntrup761x25519-sha512@openssh.com است و فاقد ML-KEM می‌باشد.
• نسخه 25.10 شامل 1:10.0p1 است که پیش‌فرض آن mlkem768x25519-sha256 می‌باشد.
• نسخه 26.04 LTS شامل 1:10.2p1 است که به‌صورت پیش‌فرض از mlkem768x25519-sha256 استفاده می‌کند و در مورد اتصالاتی که post-quantum نیستند، هشدار می‌دهد.

یک جفت دستگاه واقعی را بررسی کنید. یک لپ‌تاپ با نسخه 26.04 به یک سرور با نسخه 24.04 متصل می‌شود. اولین انتخاب کلاینت، یعنی mlkem768x25519-sha256، در لیست سرور 9.6 وجود ندارد. انتخاب post-quantum بعدی کلاینت که سرور آن را پشتیبانی می‌کند sntrup761x25519-sha512@openssh.com است و این همان نامی است که ssh -v گزارش می‌دهد. نشست در تبادل کلید، post-quantum است؛ آن هم در برابر سروری که در سال 2024 ساخته شده و هیچ تنظیمات خاصی توسط کسی روی آن اعمال نشده است.

مورد 22.04 برعکس است و دقیقاً نشان می‌دهد که چرا ssh -Q kex به‌تنهایی گمراه‌کننده است. نسخه OpenSSH 8.9 نام sntrup761x25519-sha512@openssh.com را می‌شناسد، بنابراین ssh -Q kex در آن سیستم آن را فهرست می‌کند، اما پیشنهاد پیش‌فرض آن را نادیده می‌گیرد و مذاکره روی curve25519-sha256 نهایی می‌شود. از یک کلاینت OpenSSH 10.1 یا جدیدتر، اتصال این‌گونه گزارش می‌شود:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

آن هشدار واقعیتی درباره سروری است که به آن متصل می‌شوید، نه درباره کلاینت شما. پاسخ، ارتقای سرور است. تنظیم WarnWeakCrypto no پیام را حذف می‌کند و هیچ تغییری در ماهیت اتصال ایجاد نمی‌کند.

چرا رویکرد ترکیبی (Hybrid) و مفهوم «اکنون ذخیره کن، بعداً رمزگشایی کن» چیست

این تهدید ماهیتی ساده دارد. مهاجمی که می‌تواند ترافیک شما را مشاهده کند، بایت‌های رمزگذاری‌شده را امروز ضبط و ذخیره می‌کند. آن‌ها نمی‌توانند امروز این داده‌ها را بخوانند. آن‌ها داده‌ها را تا زمانی که یک کامپیوتر کوانتومی با قدرت کافی برای شکستن X25519 ساخته شود نگه می‌دارند و سپس آن‌ها را می‌خوانند. به این کار «اکنون ذخیره کن، بعداً رمزگشایی کن» (Harvest now, decrypt later) یا «اکنون انبار کن، بعداً رمزگشایی کن» گفته می‌شود. این روش در زمان حال هیچ کار پیچیده‌ای از مهاجم نمی‌خواهد؛ تنها به فضای دیسک و صبر نیاز دارد.

رمزگذاری با این مشکل مواجه است اما امضاها (Signatures) خیر، و همین عدم تقارن، سایر مسائل را تعیین می‌کند. یک متن رمزگذاری‌شده (Ciphertext) ضبط‌شده، تا زمانی که داده‌های درون آن حساس باقی بمانند، ارزش خود را حفظ می‌کند. یک امضا فقط باید در لحظه بررسی، غیرقابل جعل باشد. شکستن یک الگوریتم امضا در سال 2035 به کسی اجازه می‌دهد در سال 2035 خود را به جای سرور جا بزند. این کار به آن‌ها اجازه نمی‌دهد به عقب برگردند و یک ورود (Login) مربوط به سال 2026 را جعل کنند. بنابراین، تبادل کلید باید در اولویت اصلاح قرار می‌گرفت و بخش امضا می‌تواند منتظر بماند.

رویکرد ترکیبی (Hybrid) به این معناست که هر دو الگوریتم اجرا می‌شوند و نتایج هر دو به کلید نشست (Session key) تزریق می‌شود. برای بازیابی راز پشت mlkem768x25519-sha256، مهاجم باید هم ML-KEM 768 و هم X25519 را بشکند. این جفت‌سازی آگاهانه است: ML-KEM بسیار جدیدتر از X25519 است و زمان بسیار کمتری را تحت حملات تحلیلگران رمز بوده است؛ بنابراین، اگر نقصی در الگوریتم جدید پیدا شود، امنیت شما که از قبل با الگوریتم قدیمی تأمین شده بود، به خطر نمی‌افتد.

چه چیزی محافظت می‌شود و چه چیزی نه

تبادل کلید محافظت‌شده است. راز مشترکی که نشست شما را رمزنگاری می‌کند از یک تبادل ترکیبی (hybrid) حاصل شده است، بنابراین ضبط آن نشست که امروز انجام شود، با ظهور کامپیوترهای کوانتومی قابل خواندن نخواهد بود.

کلید میزبان (host key) محافظت‌شده نیست. خط debug1: kex: host key algorithm: ssh-ed25519 یک امضای کلاسیک را نام می‌برد و همین موضوع در مورد rsa-sha2-512 و انواع ECDSA (الگوریتم امضای دیجیتال منحنی بیضوی) نیز صادق است. مهاجمی که یک کامپیوتر کوانتومی کارآمد در اختیار داشته باشد، می‌تواند آن امضا را جعل کرده و خود را به جای سرور شما جا بزند، اما این کار تنها در طول یک اتصال زنده در آن زمان آینده ممکن است و هرگز علیه ترافیک ضبط‌شده در حال حاضر کارایی ندارد.

کلید ورود شما نیز محافظت‌شده نیست. کلید موجود در ~/.ssh/id_ed25519 همان نوع امضای کلاسیک است و همان استدلال برای آن صدق می‌کند. آنچه در سال جاری از آن کلید محافظت می‌کند، محل نگهداری آن و افرادی است که به آن دسترسی دارند؛ بنابراین مدیریت معقول کلیدهای SSH ریسک واقعی شما را بسیار بیشتر از هر نام الگوریتمی در این صفحه کاهش می‌دهد.

هیچ کاری در مورد هیچ‌کدام از این دو مورد از دست شما برنمی‌آید، زیرا جایگزینی برای آن‌ها وجود ندارد. OpenSSH اعلام کرده است که پشتیبانی از امضاهای پساکوانتومی در نسخه‌های آینده ارائه خواهد شد. تا زمانی که این قابلیت عرضه نشود، OpenSSH هیچ نوع کلید میزبان یا کلید کاربری پساکوانتومی ندارد و ssh-keygen نیز چیزی برای ارائه به شما در این زمینه ندارد. راهنمایی که به شما می‌گوید یکی از این کلیدها را تولید کنید، در حال توصیف نرم‌افزاری است که هنوز وجود خارجی ندارد.

TLS روی همان سرور، پرسش جداگانه‌ای با پاسخ جداگانه است. TLS (امنیت لایه انتقال) همان چیزی است که وب‌سرور شما روی پورت 443 با آن صحبت می‌کند و این یک کدبیس متفاوت با زمان‌بندی متفاوت است. ارتقای OpenSSH هیچ تغییری در آن ایجاد نمی‌کند. اگر در حال اجرای یک گواهی خودامضا برای یک سرویس خصوصی روی همان VPS هستید، امضا و تبادل کلید آن توسط OpenSSL و وب‌سرور شما تعیین می‌شود، بنابراین در مورد آن پشته (stack) به صورت مستقل پرس‌وجو کنید.

What a sensible operator does now

Keep OpenSSH current, and stop there. That really is the whole strategy for this problem. sudo apt update && sudo apt upgrade keeps you on the version your Ubuntu release ships, and moving to a newer Ubuntu release is what moves you to a newer OpenSSH. Turning on unattended security upgrades gets those patches applied without you remembering to. Building OpenSSH from source to chase an algorithm name is a poor trade, because you give up the distribution's security updates for the most exposed service on the box. If you fetch source anyway, check the download against its published checksum before you build it.

Do not hand-write a KexAlgorithms line. This is the one action that reliably makes things worse. A hardening guide from 2018 hands you a list that was correct in 2018, and pasting it into sshd_config replaces the default list rather than adding to it. Every algorithm invented since then is now excluded, so a server that would have negotiated mlkem768x25519-sha256 on its own quietly drops to whatever survives in the pinned list. Run sudo sshd -T | grep -i '^kexalgorithms' on any server you inherited. If that line is shorter than the one on a fresh install of the same release, somebody pinned it.

If you have a real reason to change the list, add to it instead of replacing it. OpenSSH reads a leading + as append, a leading - as remove, and a leading ^ as move to the front.

KexAlgorithms ^mlkem768x25519-sha256

Test the file before you rely on it. sudo sshd -t parses the configuration and prints nothing when it is valid. A KexAlgorithms line naming an algorithm the build does not have stops sshd from starting, and on a remote box that means you cannot get back in, so keep a second session open while you work. When the two sides' lists stop overlapping, the client says so plainly:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Read "quantum-safe" marketing as a claim about one layer. A vendor calling a product quantum-safe is describing whichever layer they named, and that layer is usually a key exchange somewhere. Ask for the algorithm name and the protocol it applies to. For OpenSSH in August 2026 the honest version of the claim is that the key exchange is hybrid post-quantum while the signatures are classical. Anything wider than that should arrive with a name you can find in ssh -Q kex output.

Keep doing the boring parts. A post-quantum key exchange does nothing about a guessable password, or a private key copied onto a laptop that later gets stolen. Those are what actually take servers, and standard SSH hardening on a VPS still carries almost all of the weight. If the negotiation steps here were unfamiliar, what SSH does when you connect covers the stages this page assumes you know.

FAQ

آیا اتصال SSH من در حال حاضر پساکوانتومی است؟

دستور ssh -v yourserver 2>&1 | grep 'kex: algorithm' را اجرا کنید و نامی که چاپ می‌کند را بخوانید. mlkem768x25519-sha256 و sntrup761x25519-sha512@openssh.com تبادل‌های هیبریدی پساکوانتومی هستند. curve25519-sha256، ecdh-sha2-nistp256 و هر نام diffie-hellman-group دیگری کلاسیک محسوب می‌شوند. هر دو سمت باید نسخه‌ای داشته باشند که یک نام پساکوانتومی ارائه دهد، زیرا فرآیند مذاکره، اولین انتخاب کلاینت را که توسط سرور نیز پشتیبانی می‌شود برمی‌گزیند؛ بنابراین دستگاه قدیمی‌تر سقف امنیت را تعیین می‌کند.

کدام نسخه OpenSSH تبادل کلید پساکوانتومی را به حالت پیش‌فرض درآورد؟

نسخه OpenSSH 9.0 که در تاریخ 2022-04-08 منتشر شد، sntrup761x25519-sha512@openssh.com را به تبادل کلید پیش‌فرض تبدیل کرد. نسخه OpenSSH 9.9 که در 2024-09-19 منتشر شد، mlkem768x25519-sha256 را اضافه کرد و نسخه OpenSSH 10.0 که در 2025-04-09 منتشر شد، آن را به گزینه پیش‌فرض تبدیل کرد. نسخه OpenSSH 10.1 که در 2025-10-06 منتشر شد، شروع به نمایش هشدار در صورت عدم مذاکره برای هیچ‌کدام از این موارد کرد. بررسی کنید که نسخه نصب‌شده شما با ssh -Q kex و ssh -G <host> چه عملکردی دارد، زیرا نسخه توزیع Ubuntu شما تعیین می‌کند که کدام‌یک از این موارد را در اختیار دارید.

آیا باید یک کلید SSH پساکوانتومی تولید کنم؟

خیر، زیرا OpenSSH چنین نوع کلیدی ندارد. فعالیت‌های پساکوانتومی تاکنون تبادل کلید را پوشش داده‌اند که نیازی به فایل‌های کلید از سمت شما و هیچ‌گونه پیکربندی ندارد. کلیدهای میزبان و کلیدهای ورود همچنان امضاهای کلاسیک مانند Ed25519 و RSA هستند و تیم توسعه اعلام کرده است که امضاهای پساکوانتومی در نسخه‌های آینده ارائه خواهند شد. همچنان از کلید Ed25519 استفاده کنید و از محل ذخیره‌سازی آن محافظت نمایید.

چرا ssh هشدار می‌دهد که اتصال من پساکوانتومی نیست؟

نسخه‌های OpenSSH 10.1 و جدیدتر، هنگام مذاکره‌ای که فاقد بخش پساکوانتومی باشد، ** WARNING: connection is not using a post-quantum key exchange algorithm. را چاپ می‌کنند. این هشدار مربوط به سرور است، نه کلاینت شما؛ زیرا کلاینت شما یک نام پساکوانتومی پیشنهاد داده و سرور هیچ‌کدام را نپذیرفته است. OpenSSH سرور را ارتقا دهید یا بررسی کنید که کسی در فایل sshd_config سرور، یک خط KexAlgorithms را پین نکرده باشد که نام‌های مدرن را حذف کند. تنظیم WarnWeakCrypto no این پیام را مخفی می‌کند و اتصال را دقیقاً به همان اندازه ضعیف باقی می‌گذارد که پیش‌تر بود.