ما الذي تغيّر في SSH على Ubuntu بعد الحوسبة الكمّية؟

ما الذي تغيّر في SSH بعد الحوسبة الكمّية

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

لنوضّح مصطلحين أولاً. SSH ‏(secure shell) هو البروتوكول الذي تستخدمه لتسجيل الدخول إلى خادم. أما تبادل المفاتيح، ويُكتب عادةً "kex"، فهو الخطوة الأولى في كل اتصال SSH: يتفق الطرفان على سر مشترك، ثم يشفّر ذلك السر كل ما يأتي بعده. الجزء الذي تغيّر هو تبادل المفاتيح. ولم يتغيّر أي شيء آخر.

لا تثق بهذه الصفحة؛ نفّذ الأوامر

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

ابدأ بما يعرفه إصدار OpenSSH لديك.

ssh -V
ssh -Q kex

يطبع ssh -V سطر إصدار يبدأ بـ OpenSSH_، يليه لاحقة حزمة Ubuntu وإصدار OpenSSL. يطبع ssh -Q kex خوارزمية واحدة لتبادل المفاتيح في كل سطر. في إصدار يدعم التشفير ما بعد الكمي، ستجد في القائمة أسماء مثل 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، إلى جانب Diffie-Hellman للمنحنى الإهليلجي X25519، ثم تدمج كلا الناتجين في مفتاح الجلسة.

عند الاتصال بخادم أقدم، قد ترى هذا بدلاً من ذلك:

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 جعل التبادل الهجين هو الإعداد الافتراضي

توضح ملاحظات الإصدار upstream التسلسل بوضوح. التواريخ أهم من أرقام الإصدارات، لأنها تبيّن المدة التي ظل فيها هذا الأمر يعمل بهدوء.

• الإصدار 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 أن تتذكره. فأي زوج من الأجهزة التي تعمل بالإصدار 9.0 أو إصدار أحدث من OpenSSH يجري تبادل مفاتيح ما بعد كمومي منذ ذلك الحين، من دون إعداد أو إعلان للشخص الذي يكتب ssh.

أي إصدار من Ubuntu يتضمنه

يثبّت Ubuntu إصداراً من OpenSSH عند إصدار التوزيعة، ثم ينقل إليه إصلاحات الأمان دون تغيير رقم الإصدار. لذلك يحدد إصدار Ubuntu الذي تستخدمه الخوارزمية الافتراضية لديك. افحص الجهاز الموجود أمامك باستخدام ssh -V بدلاً من الاعتماد على قائمة. اعتباراً من August 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، كما يصدر تحذيراً بشأن الاتصالات التي لا تستخدم تبادل مفاتيح ما بعد الكم.

طبّق ذلك على زوج حقيقي من الأجهزة. يتصل حاسوب محمول يعمل بالإصدار 26.04 بخادم يعمل بالإصدار 24.04. لا يوجد خيار العميل الأول، mlkem768x25519-sha256، ضمن قائمة خادم الإصدار 9.6. أما خيار العميل التالي لتبادل المفاتيح ما بعد الكم، والموجود فعلاً لدى الخادم، فهو sntrup761x25519-sha512@openssh.com، وهذا هو الاسم الذي يعرضه ssh -v. تستخدم الجلسة تبادل مفاتيح ما بعد الكم، رغم أن الخادم مبني في 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 إلى إزالة الرسالة، ولا يغيّر شيئاً في الاتصال.

لماذا نستخدم الوضع الهجين، وما المقصود بفكرة «اجمع الآن وفك التشفير لاحقاً»؟

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

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

يعني الوضع الهجين تشغيل كلتا الخوارزميتين وإدخال النتيجتين معاً في مفتاح الجلسة. ولكي يستعيد المهاجم السر الموجود خلف mlkem768x25519-sha256، يجب عليه كسر ML-KEM 768 وX25519 معاً. هذا الاقتران مقصود: خوارزمية ML-KEM أحدث بكثير من X25519، ولم تتعرض لهجمات محللي الشفرات إلا لفترة أقصر بكثير، ولذلك فإن اكتشاف ثغرة في الخوارزمية الجديدة لا يفقدك الحماية التي كانت متوفرة لديك مسبقاً.

ما الذي تحميه وما الذي لا تحميه

تبادل المفاتيح محمي. أتى السر المشترك الذي يشفّر جلستك من تبادل هجين، لذلك لا تصبح جلسة سُجّلت اليوم قابلة للقراءة عند ظهور الحواسيب الكمّية.

مفتاح المضيف غير محمي. يسمّي السطر 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 وخادم الويب لديك، لذلك افحص هذه المجموعة بمعزل عن OpenSSH.

ما يفعله المشغّل الحريص الآن

حافظ على تحديث OpenSSH، وتوقف عند ذلك. هذه هي الاستراتيجية كاملةً لهذه المشكلة. يضمن لك sudo apt update && sudo apt upgrade استخدام الإصدار الذي يأتي مع إصدار Ubuntu لديك، بينما ينقلك الترقية إلى إصدار أحدث من Ubuntu إلى إصدار أحدث من OpenSSH. يؤدي تفعيل ترقيات الأمان غير التفاعلية إلى تطبيق هذه التصحيحات من دون الحاجة إلى تذكّر ذلك. إن بناء OpenSSH من المصدر لملاحقة اسم خوارزمية محدد مقايضة غير موفقة، لأنك تتخلى عن تحديثات الأمان التي توزّعها التوزيعة لأكثر الخدمات تعرضاً على الخادم. إذا نزّلت المصدر رغم ذلك، فتحَقّق من التنزيل بمقارنته مع قيمة checksum المنشورة قبل بنائه.

لا تكتب سطر KexAlgorithms يدوياً. فهذا الإجراء هو الذي يؤدي بصورة موثوقة إلى جعل الوضع أسوأ. يقدّم دليل تقوية من عام 2018 قائمة كانت صحيحة في عام 2018، ولصقها في sshd_config يستبدل القائمة الافتراضية بدلاً من الإضافة إليها. وبذلك تُستبعد كل خوارزمية أُضيفت منذ ذلك الحين، فيتراجع خادم كان سيتفاوض تلقائياً على mlkem768x25519-sha256 بهدوء إلى أي خيار يبقى في القائمة المثبّتة. شغّل sudo sshd -T | grep -i '^kexalgorithms' على أي خادم ورثت إدارته. إذا كان هذا السطر أقصر من السطر الموجود في تثبيت جديد للإصدار نفسه، فهذا يعني أن أحدهم ثبّت قائمة محددة.

إذا كان لديك سبب فعلي لتغيير القائمة، فأضف إليها بدلاً من استبدالها. يفسّر OpenSSH الرمز + في بداية القيمة على أنه إضافة، والرمز - في بدايتها على أنه إزالة، والرمز ^ في بدايتها على أنه نقل إلى المقدمة.

KexAlgorithms ^mlkem768x25519-sha256

اختبر الملف قبل الاعتماد عليه. يحلّل sudo sshd -t الإعدادات ولا يطبع شيئاً عندما تكون صالحة. يؤدي سطر KexAlgorithms يسمّي خوارزمية غير متوفرة في عملية البناء إلى منع sshd من البدء. وعلى خادم بعيد، يعني ذلك أنك لن تتمكن من الدخول إليه مجدداً، لذا أبقِ جلسة ثانية مفتوحة أثناء العمل. عندما لا يعود هناك تداخل بين قائمتي الطرفين، يوضح العميل ذلك صراحةً:

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

تعامل مع التسويق لعبارة «آمن كمّياً» على أنه ادعاء يخص طبقة واحدة. فعندما يصف مورّد منتجاً بأنه آمن كمّياً، فإنه يتحدث عن الطبقة التي سمّاها، وتكون تلك الطبقة عادةً تبادل مفاتيح في موضع ما. اطلب اسم الخوارزمية والبروتوكول الذي تنطبق عليه. بالنسبة إلى OpenSSH في August 2026، الصياغة الدقيقة للادعاء هي أن تبادل المفاتيح هجين وما بعد كمّي، بينما تبقى التوقيعات كلاسيكية. وأي ادعاء أوسع من ذلك ينبغي أن يأتي مصحوباً باسم يمكنك العثور عليه في مخرجات ssh -Q kex.

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

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 على الخادم، أو تحقّق من عدم تثبيت أحدهم سطراً KexAlgorithms في sshd_config الخاص به يستبعد الأسماء الحديثة. يؤدي ضبط WarnWeakCrypto no إلى إخفاء الرسالة، لكنه يترك الاتصال بالضعف نفسه.