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

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

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

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

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

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

با آنچه نسخه نصب‌شده شما پشتیبانی می‌کند، شروع کنید.

ssh -V
ssh -Q kex

ssh -V یک خط نسخه را چاپ می‌کند که با OpenSSH_ شروع شده و پس از آن پسوند بسته Ubuntu و نسخه OpenSSL قرار می‌گیرد. ssh -Q kex در هر خط یک الگوریتم تبادل کلید را چاپ می‌کند. در نسخه‌ای که از پشتیبانی پساکوانتومی (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 نشنیده است، ارتقا یابد.

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

یک اپراتور منطقی اکنون چه می‌کند

OpenSSH را به‌روز نگه دارید و فقط همین کار را انجام دهید. این تمام استراتژی برای این مشکل است. sudo apt update && sudo apt upgrade شما را در نسخه‌ای که توزیع Ubuntu شما ارائه می‌دهد نگه می‌دارد و ارتقا به نسخه جدیدتر Ubuntu، شما را به نسخه جدیدتر OpenSSH می‌برد. فعال‌سازی ارتقاهای امنیتی خودکار باعث می‌شود این وصله‌ها بدون نیاز به یادآوری شما اعمال شوند. کامپایل کردن OpenSSH از سورس برای دنبال کردن نام یک الگوریتم، معامله بدی است؛ زیرا شما به‌روزرسانی‌های امنیتی توزیع را برای آسیب‌پذیرترین سرویس روی سرور خود از دست می‌دهید. اگر به هر حال سورس را دریافت کردید، پیش از کامپایل کردن، فایل دانلود شده را با checksum منتشر شده تطبیق دهید.

خط KexAlgorithms را به‌صورت دستی ننویسید. این تنها کاری است که به‌طور قطع اوضاع را بدتر می‌کند. یک راهنمای مقاوم‌سازی (hardening) مربوط به سال 2018 لیستی را به شما می‌دهد که در سال 2018 درست بوده است و چسباندن آن در sshd_config، لیست پیش‌فرض را جایگزین می‌کند، نه اینکه به آن اضافه شود. تمام الگوریتم‌های اختراع‌شده پس از آن تاریخ اکنون حذف شده‌اند؛ بنابراین سروری که می‌توانست به‌طور خودکار mlkem768x25519-sha256 را مذاکره کند، بی‌سروصدا به هر آنچه در لیست محدود شما باقی مانده است تنزل می‌یابد. روی هر سروری که به ارث برده‌اید، sudo sshd -T | grep -i '^kexalgorithms' را اجرا کنید. اگر آن خط کوتاه‌تر از خط موجود در یک نصب تازه از همان نسخه باشد، یعنی کسی آن را محدود (pin) کرده است.

اگر دلیل موجهی برای تغییر لیست دارید، به‌جای جایگزینی، به آن اضافه کنید. OpenSSH کاراکتر + در ابتدای خط را به معنای افزودن، - را به معنای حذف و ^ را به معنای انتقال به ابتدای لیست تفسیر می‌کند.

KexAlgorithms ^mlkem768x25519-sha256

پیش از تکیه بر فایل، آن را تست کنید. sudo sshd -t پیکربندی را تحلیل می‌کند و در صورت معتبر بودن، چیزی چاپ نمی‌کند. وجود یک خط KexAlgorithms که نام الگوریتمی را می‌برد که در build شما وجود ندارد، مانع از شروع به کار sshd می‌شود؛ و در یک سرور از راه دور، این یعنی دیگر نمی‌توانید وارد شوید. بنابراین هنگام کار، یک نشست (session) دوم باز نگه دارید. وقتی لیست‌های دو طرف دیگر هم‌پوشانی نداشته باشند، کلاینت این موضوع را به‌وضوح اعلام می‌کند:

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

ادعاهای بازاریابی درباره "امنیت کوانتومی" را به عنوان ادعایی درباره یک لایه خاص در نظر بگیرید. فروشنده‌ای که محصولی را امن در برابر کوانتوم می‌نامد، در حال توصیف همان لایه‌ای است که نام برده و آن لایه معمولاً یک تبادل کلید در جایی است. نام الگوریتم و پروتکلی که به آن اعمال می‌شود را بپرسید. برای OpenSSH در اوت 2026، نسخه صادقانه این ادعا این است که تبادل کلید از نوع hybrid post-quantum است، در حالی که امضاها کلاسیک هستند. هر چیزی فراتر از این باید با نامی همراه باشد که بتوانید در خروجی ssh -Q kex پیدا کنید.

بخش‌های خسته‌کننده را ادامه دهید. یک تبادل کلید post-quantum هیچ تأثیری بر رمز عبور قابل حدس زدن یا کلید خصوصی که روی لپ‌تاپی کپی شده و بعداً دزدیده شده است، ندارد. این‌ها مواردی هستند که واقعاً باعث نفوذ به سرورها می‌شوند و مقاوم‌سازی استاندارد SSH روی یک VPS همچنان تقریباً تمام بار امنیتی را به دوش می‌کشد. اگر مراحل مذاکره در اینجا برایتان ناآشنا بود، آنچه SSH هنگام اتصال انجام می‌دهد مراحلی را پوشش می‌دهد که این صفحه فرض می‌کند شما می‌دانید.

FAQ

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

دستور ssh -v yourserver 2>&1 | grep 'kex: algorithm' را اجرا کنید و نامی که چاپ می‌کند را بخوانید. mlkem768x25519-sha256 و sntrup761x25519-sha512@openssh.com تبادل‌های ترکیبی (hybrid) پساکوانتومی هستند. 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 چنین نوع کلیدی ندارد. تلاش‌های پساکوانتومی تاکنون تبادل کلید را پوشش داده است که نیازی به فایل کلید از سمت شما و هیچ‌گونه پیکربندی ندارد. کلیدهای میزبان (host keys) و کلیدهای ورود همچنان امضاهای کلاسیک مانند Ed25519 و RSA هستند و تیم توسعه اعلام کرده است که امضاهای پساکوانتومی در نسخه‌های آینده ارائه خواهند شد. به استفاده از کلید Ed25519 ادامه دهید و از محل ذخیره‌سازی آن محافظت کنید.

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

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