الخلاصة

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

اتصال واحد وعمران مختلفان

قد تبقى الطرفية البعيدة مفتوحة ساعات، وقد تحمل قنوات الملفات والتحويل حالة لا يريد المستخدم خسارتها. أما المادة المشفّرة التي تحمي الحزم فلا يلزم أن تعيش العمر نفسه.

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

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

المعرّف حُسب ولم يُمنح

يرسل العميل والخادم SSH_MSG_KEXINIT. تحمل الرسالة cookie عشوائية وقوائم مرتبة لطرق تبادل المفاتيح ومفتاح المضيف والتشفير والسلامة والضغط. يختار البروتوكول أول خيار يفضله العميل ويشترك في دعمه الطرفان وفق شروط الطريقة.

تحسب الطريقة المختارة سراً مشتركاً K وتجزئة تبادل H. في بناء Diffie–Hellman الأصلي لـSSH 2 تدخل في H سلاسل تعريف البروتوكول، ورسالتا KEXINIT الخام، ومفتاح المضيف العام، والقيم المؤقتة، والسر المشترك.

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

تجعل قيم cookie النتيجة أصعب توقعاً، لكن معرّف الجلسة ليس سراً. يمكن كشفه من غير كشف K أو امتلاك القدرة على صناعة حماية مرور صحيحة. قيمته في كونه سياقاً، لا في كونه رمز دخول.

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

أول H وحدها أصبحت هوية الاتصال

تستخدم RFC 4253 K وH لاشتقاق المفاتيح والمتجهات. وفي التبادل الأول فقط تؤدي H وظيفة إضافية هي session_id. بعد حسابها لا تتغير طوال الاتصال.

يمكن أن يكون rekey واسعاً. يبدأه أي طرف؛ تتبدل الخوارزميات وربما مفتاح المضيف؛ يعاد حساب مفاتيح المرور والمتجهات؛ وتبدأ سياقات التشفير والضغط من جديد عند حدود SSH_MSG_NEWKEYS. ينتج التبادل الجديد سراً وتجزئة جديدين للحماية الجديدة، لكنه لا يمنح الطبقات العليا معرّفاً بديلاً.

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

إعادة الاتصال حالة مختلفة. أول تبادل في الاتصال الجديد يولّد معرّفاً جديداً. قد يستأنف التطبيق نقلاً أو مهمة بآليته الخاصة، لكن عليه ربط جلستين كتعافٍ، لا دمجهما في هوية SSH واحدة.

التوقيع أدخل الاتصال في نص الطلب

لم تجعل RFC 4252 توقيع publickey مقتصراً على اسم المستخدم. تبدأ البيانات الموقعة بمعرّف الجلسة، ثم تأتي رسالة SSH_MSG_USERAUTH_REQUEST واسم المستخدم والخدمة والطريقة والقيمة المنطقية وخوارزمية المفتاح والمفتاح العام.

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

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

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

نجاح المصادقة لم يكن تفويضاً شاملاً

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

تظل هذه القرارات للسياسة المحلية. وبعضها لا يمكن تقريره أثناء المصادقة لأن العميل لم يطلب القناة بعد. يتيح معرّف الجلسة للطبقات القول إن هذا الإثبات يعود إلى المحادثة المحمية نفسها؛ ولا يتيح لها القول إن كل فعل مقبل مسموح.

وينطبق الحد على التدقيق. تسجيل المعرّف مع «نجحت مصادقة المفتاح العام» يربط حدث الدخول بالنقل. من دون طلبات القنوات وقراراتها، لا يثبت أي أمر نُفّذ أو أي تحويل فُتح.

شاخت الخوارزميات وبقي توزيع المسؤولية

لم تكن كل اختيارات 2006 صالحة إلى الأبد. أضافت RFC 8332 توقيعات RSA مع SHA-256 وSHA-512 لمصادقة الخادم والعميل. أمكن للمفتاح العام القديم الاحتفاظ بصيغة ssh-rsa بينما يختار اسم جديد إجراء توقيع أقوى. بقيت مادة المفتاح والخوارزمية والنص الموقع عناصر منفصلة.

حدّثت RFC 9142 لاحقاً توصيات طرق KEX ودفعت إلى ترك الخيارات المبنية على SHA-1. أمكن تغيير طريقة أول تبادل من دون نقل الحد المعماري: تجزئته الأولى تبقى سياق البراهين العليا.

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

أدلة متعددة تحت اسم واحد مضلل

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

لا يجوز جمعها في خانة «هوية SSH» واحدة. تثبت وثائق RFC المعنى وتطور الخوارزميات، ولا تقيس تحقق العملاء من المفاتيح أو توقيت rekey أو انتشار SHA-1 أو تنفيذ أمر بعينه.

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