الخلاصة

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

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

حين يفتح مستخدم اتصالاً إلى مضيف وسيط ويحوّل إليه وكيل SSH، يظهر في الجهة البعيدة socket يشبه خدمة محلية. الرسائل التي تصل إليه تعود عبر قناة SSH إلى الوكيل الموجود عند المستخدم. لا يرى المضيف البعيد بذرة Ed25519 أو العوامل الخاصة لـRSA. لكنه قد يرسل بيانات ويستلم توقيعاً جديداً.

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

الوكيل خزنة وواجهة استدعاء معاً

نُشر RFC 9987 في مايو 2026 بوصفه Proposed Standard. البروتوكول قائم على طلبات العميل وردود الوكيل؛ لا يبدأ الوكيل رسالة من تلقاء نفسه، ويرد بالترتيب. يستطيع العميل إضافة الهوية أو إزالتها، طلب قائمة المفاتيح، قفل الوكيل وطلب توقيع. ويمكن للوكيل رفض نوع أو عملية أو سياق.

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

لكن RFC يصرح بأن بروتوكول الوكيل نفسه لا يوفر مصادقة ولا أمان نقل. في Unix تُستخدم أذونات socket وهوية العملية المقابلة؛ وفي Windows يمكن استخدام security descriptor على named pipe. ويعلن SSH_AUTH_SOCK غالباً مكان endpoint.

هذه التفاصيل هي حدود السلطة الفعلية. من يستطيع الوصول إلى endpoint يستطيع غالباً طلب عملية بالمفتاح. لذلك يميز RFC بين منع نسخ المفتاح ومنع سرقة استخدامه. قد يحمي العتاد المادة حماية ممتازة ويبقى متاحاً كـoracle توقيع على الإنترنت الداخلي.

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

القيود لا تعمل خارج نطاقها

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

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

لذلك لا يكفي تسجيل “تم التأكيد”. يلزم معرفة ما عُرض، ومن وافق، وأي طلب ارتبط بالقرار. وإلا بقيت الموافقة رمزاً لا تفويضاً قابلاً للمراجعة.

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

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

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

التحويل يعيد رسم الثقة

يسمح RFC بتحويل وصول الوكيل عبر اتصال SSH. يحصل المضيف الوسيط على قناة إلى الوكيل المحلي من دون الحصول على السر. ويسمي RFC ذلك صراحة علاقة ثقة متعدية؛ فلا ينبغي تفعيله افتراضياً ولا تحويله إلى مضيف غير موثوق بالكامل.

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

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

قد تكون هذه سلوكيات مشروعة، لكنها تمنع الاستنتاج السهل بأن shell معين طلب توقيعاً معيناً. يجب ربط الاتصال الخارجي وطلب التحويل وقناة الوكيل والمفتاح والقيود والتوقيع وسجل خادم الوجهة.

قرار خادم الوجهة مستقل

في مصادقة SSH بالمفتاح العام، يربط RFC 4252 التوقيع بـsession identifier واسم المستخدم والخدمة والطريقة والخوارزمية والمفتاح. ويفحص الخادم على حدة أن المفتاح مسموح للحساب وأن التوقيع صحيح. ويمكنه طلب مصادقة إضافية.

لا يصبح توقيع واحد كلمة مرور عامة قابلة لإعادة الاستخدام. لكنه لا يمنع طالباً لديه طريق حي إلى الوكيل من طلب توقيع جديد لجلسة جديدة. منع replay لا يساوي منع إساءة استخدام خدمة توقيع متاحة.

ينبغي فصل الحالات: المفتاح محمّل؛ endpoint قابل للوصول؛ الوكيل وافق على التوقيع؛ التوقيع مرتبط بالسياق؛ الخادم قبله؛ القناة مُنحت صلاحيات؛ الأثر وقع. لا يتكلم نجاح مرحلة باسم التي تليها.

كما تختلف مجموعات الخوارزميات. قد يدعم الوكيل RSA أو Ed25519، وقد يطلب العميل RSA/SHA-2، ويقبل الخادم مجموعة أخرى، وتكون سياسة المؤسسة أضيق. يسجل IANA الأسماء والقيم، ولا يثبت التفعيل أو الامتثال في نظام بعينه.

سجل واقعي للحادث

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

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

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

ثم يُراقب الأثر: أمر أو subsystem أو port forwarding أو ملف أو رفض. أما الإغلاق فيُثبت بحذف المفتاح، وإغلاق الوكيل والقنوات، وسحب تفويض الوجهة عند الحاجة، ومشاهدة فشل محاولة جديدة.

هكذا تبقى عبارة “المفتاح لم يغادر” حقيقة مفيدة، لكنها لا تحجب استخداماً وقع بالفعل.