SSH ما بعد الكم: ما الذي تغيّر في Ubuntu؟

ما الذي تغيّر في SSH ما بعد الكم

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

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

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

كل اسم خوارزمية يرد أدناه ناتج عن أمر يمكنك تشغيله بنفسك. وهذا مقصود. يتغير الإعداد الافتراضي مع كل إصدار من 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 من قبل.

احذف 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. فأي زوج من الأجهزة التي تشغّل OpenSSH 9.0 أو إصداراً أحدث ينفّذ تبادل مفاتيح ما بعد الكم منذ ذلك الحين، من دون إعدادات أو إعلان للشخص الذي يكتب 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، وتوقف عند ذلك. هذه هي الاستراتيجية كاملةً لهذه المشكلة. يُبقيك sudo apt update && sudo apt upgrade على الإصدار الذي يأتي مع إصدار Ubuntu لديك، والانتقال إلى إصدار أحدث من Ubuntu هو ما ينقلك إلى إصدار أحدث من OpenSSH. يؤدي تفعيل ترقيات الأمان غير التفاعلية إلى تطبيق هذه التصحيحات من دون الحاجة إلى تذكّر ذلك. إن بناء OpenSSH من المصدر لملاحقة اسم خوارزمية معينة مقايضة سيئة، لأنك تتخلى عن تحديثات الأمان التي توفّرها التوزيعة لأكثر الخدمات تعرّضاً على الخادم. وإذا جلبت المصدر رغم ذلك، فتحقق من الملف المنزّل باستخدام المجموع الاختباري المنشور له قبل بنائه.

لا تكتب سطر 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 في أغسطس 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، وقد أوضح المشروع upstream أن التوقيعات المقاومة لهجمات ما بعد الكم ستتوفر في إصدار مستقبلي. واصل استخدام مفتاح Ed25519، واحمِ المكان المخزّن فيه.

لماذا يحذّر ssh من أن اتصالي ليس منيعاً ضد هجمات ما بعد الكم؟

يطبع OpenSSH 10.1 والإصدارات الأحدث ** WARNING: connection is not using a post-quantum key exchange algorithm. عندما لا يتضمن تبادل المفاتيح المتفاوض عليه مكوّناً منيعاً ضد هجمات ما بعد الكم. يتعلق التحذير بالخادم، لا بالعميل، لأن عميلك قدّم اسماً منيعاً ضد هجمات ما بعد الكم ولم يقبل الخادم أياً منها. حدّث OpenSSH على الخادم، أو تحقّق من عدم تثبيت أحدهم سطر KexAlgorithms في ملف sshd_config الخاص به بما يستبعد الأسماء الحديثة. يؤدي ضبط WarnWeakCrypto no إلى إخفاء الرسالة، لكنه يُبقي الاتصال بالضعف نفسه.