الخلاصة

  • يحمل طلب التوقيع في RFC 9987 مفتاحًا عامًا وبيانات وأعلامًا، ثم يعيد الوكيل توقيعًا أو فشلًا. لا توجد حقول إلزامية للعملية الطالبة أو الشخص أو المضيف المقصود أو الحساب أو الأمر أو الغرض.
  • لا يوفر بروتوكول الوكيل مصادقة العميل أو حماية النقل بنفسه. يكفي عادة الوصول إلى نقطة النهاية المحلية لطلب عمليات المفتاح، ويمنح تمرير الوكيل مضيفًا بعيدًا قدرة الاستخدام من دون نقل مادة المفتاح الخاص.
  • التأكيد والمدة والقفل ونتيجة الوكيل ومصادقة الخادم وتفويض التطبيق أحكام منفصلة. يقترح Daniel Kade إيصال نية من ست مراحل يربطها ببيانات دنيا وبصمات تجزئة من دون حفظ الأسرار.

ما الذي لا يقوله اللون الأخضر؟

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

نُشر RFC 9987 في مايو/أيار 2026 بصفته معيارًا مقترحًا من IETF، وهو يحدد الحوار بين عميل ووكيل يحتفظ بالمفاتيح الخاصة أو يفوض عملياتها. يستطيع العميل إضافة الهويات وإزالتها وتعدادها، وطلب التواقيع، وقفل الوكيل، واستعمال الامتدادات. تمنح هذه الحدود واجهة قديمة صيغة مشتركة قابلة للتشغيل البيني. لكنها لا تجعل الوكيل جهة تفهم المقصد المؤسسي لكل سلسلة بيانات.

يضم SSH_AGENTC_SIGN_REQUEST كتلة المفتاح العام وسلسلة البيانات والأعلام. ويضم النجاح SSH_AGENT_SIGN_RESPONSE والتوقيع. لا يفرض البروتوكول اسم الملف التنفيذي، أو صاحب القرار البشري، أو المضيف والحساب البعيدين، أو الأمر، أو تذكرة التغيير، أو قاعدة التفويض. قد تكون البيانات رسالة مصادقة SSH، لكن رسالة الوكيل العامة لا تحصر استخدامها بهذا السياق ولا تعرف النتيجة التي سيمنحها النظام المعتمد.

ليس ذلك عيبًا في المعيار؛ فالواجهة الضيقة أوضح وأسهل حماية. يظهر الخلل حين تحول الإدارة واقعة «استخدم المفتاح لتوقيع هذه البايتات» إلى ادعاء «وافق المستخدم على النتيجة». يدعو Why BTW Media Exists إلى الفصل بين ما أمكن رصده وما نُسب إليه. عملية المفتاح مرصودة، أما الرضا والتفويض فلكل منهما مصدر إثبات آخر.

حماية السر لا تحمي حق استدعائه تلقائيًا

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

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

توضح الرموز العتادية الفرق بين المخزونات. إضافة هوية من الرمز إلى الوكيل تفوض العمليات المستقبلية إلى الجهاز؛ إزالتها من الوكيل لا ينبغي أن تمحو المفتاح من الرمز. يجب أن يقول تقرير الاحتواء من أي طبقة أزيلت الهوية، وأي حقبة تحميل انتهت، وهل بقي مسار لإضافتها مجددًا. عبارة «حُذف المفتاح» بلا طبقة قد تغلق التحقيق قبل إلغاء القدرة.

تقتضي فكرة The Policy Mirror أن تعكس السياسة موضع السيطرة الفعلية. يقرر نظام التشغيل من يصل إلى القناة. يطبق الوكيل القيود. يحمي الرمز مادة المفتاح وقد يتطلب حضورًا محليًا. يقرر الخادم إن كان المفتاح مقبولًا للحساب المطلوب. ويقرر التطبيق ما يمكن للجلسة المصادق عليها فعله. لا يمنح التوقيع إحدى هذه الجهات حكم الجهات الأخرى.

القيود حالة مرتبطة بزمن

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

عند إضافة المفتاح نفسه من جديد، ينبغي للطلب الجديد أن يحل محل القيود السابقة، أو يجوز للوكيل أن يرفض الإضافة. لذلك لا تكفي بصمة المفتاح لوصف سلطته. يلزم رقم حقبة للتحميل أو الاستبدال يربط التوقيع بالمدة والتأكيد والامتدادات ونطاق الظهور وحالة القفل في لحظة الحدث. لقطة المخزون بعد الواقعة قد تعرض سياسة لم تكن هي السياسة وقتها.

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

والقفل حكم آخر مستقل. يجب أن يوقف الوكيل المقفل عمليات التوقيع الخاصة على الأقل حتى فك القفل بالعبارة الصحيحة. فك القفل يجعل القدرة متاحة؛ لا يحدد هوية الطالب التالي ولا يوافق على كل وجهة مستقبلية. اعتباره موافقة عامة يمدد تغيير حالة محلية إلى طلبات لم تكن معروفة وقتها.

التمرير ينقل القدرة لا المفتاح

يمكّن تمرير الوكيل مضيفًا بعيدًا من استعمال مفتاح محلي من دون استلام مادته الخاصة. هذه ميزة حقيقية، وهي في الوقت ذاته تفويض. يصف RFC 9987 التمرير بأنه ثقة متعدية، ويوصي بألا يكون مفعّلًا افتراضيًا، ويحذر من تمريره إلى مضيف غير موثوق بالكامل. يستطيع مهاجم على المضيف البعيد استدعاء الوكيل المحلي عبر القناة مع بقاء المفتاح في مكانه.

توجد أيضًا فجوة في الإسناد. لا يحمل agent-connect معرفًا يميز قناة الجلسة التي أنشأت طلب الاتصال. وقد تحمل وصلة SSH واحدة جلسات متعددة، فيما يرى الوكيل اتصالات ممررة متزامنة. معرفة وسيلة النقل لا تكفي بالضرورة لتعيين shell أو عملية أو شخص بعينه.

يوجه Running Code Primary النظر إلى الحدود التي عملت فعلًا: ملكية المقبس وصلاحياته، ومعلومة النظير المتاحة، واختيار التمرير، وحقبة القيود، والتوقيت، ونتيجة جهة التحقق. قاعدة مكتوبة تمنع التمرير لا تعيد بناء طريق توقيع محدد إذا لم تسجل الأنظمة تنفيذها.

قرار المصادقة يملكه الخادم

يضع RFC 4252 مصادقة المستخدم بالمفتاح العام لدى الخادم. يغطي التوقيع معرف جلسة SSH وحقولًا منها اسم المستخدم والخدمة والطريقة والخوارزمية والمفتاح. على الخادم التحقق من التوقيع وتقرير ما إذا كان المفتاح مقبولًا للحساب. وقد يطلب عاملًا إضافيًا. لا تكتمل المصادقة إلا برسالة الخادم SSH_MSG_USERAUTH_SUCCESS، لا باستجابة الوكيل السابقة.

يحدد RFC 4253 النقل المحمي ومعرف الجلسة، وينظم RFC 4254 القنوات والخدمات اللاحقة، ويعرض RFC 4251 البنية الكاملة. وبذلك يبقى استعمال المفتاح، وقبول الحساب، وتفويض الأمر أو الخدمة نتائج منفصلة.

كما أن تسجيل الخوارزمية لا يمنح سلطة. يحدد RFC 8332 RSA مع SHA-2، ويحدد RFC 8709 ‏Ed25519 وEd448، ويشرح RFC 8308 تفاوض الامتدادات. يسجل دليل IANA لمعاملات SSH أسماء متوافقة؛ ولا يثبت نشرًا أو تعرض نقطة نهاية أو موافقة أو تفويضًا.

إيصال نية من ست مراحل

تسجل المرحلة الأولى قبول الطالب: هل المسار محلي أم ممرر، والمرجع الأدنى المتاح للنظير، وحقبة السياسة، ومعرف طلب مبهم. وتسجل الثانية حالة المفتاح: البصمة العامة ونطاق الظهور وحقبة التحميل والمدة وقيود التأكيد والامتدادات والتفويض للرمز وحالة القفل.

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

هذا الإيصال اقتراح حوكمة من Daniel Kade، وليس حقولًا يفرضها RFC 9987. لا يحول الوكيل إلى محرك سياسة أعمال، بل يمنع نجاحه الضيق من انتحال قرارات السلسلة كلها.

المصادر