(تم تغيير العنوان الأولي لمقالة "خوارزمية تشغيل بروتوكول SSH" وفقًا لتوصيات Vindicar و Karroplan وأعضاء آخرين في مجتمع habro).أثناء قراءة المقالات بشكل دوري على SSH ، لاحظت أن مؤلفيهم في بعض الأحيان ليس لديهم فكرة عن كيفية عمل هذا البروتوكول. في معظم الحالات ، يقتصر الأمر على النظر في موضوع توليد المفاتيح ووصف خيارات الأوامر الرئيسية. حتى أن مسؤولي النظام المتمرسين غالبًا ما يأخذون هراء كامل عند مناقشة مشكلات SSH ، ويصدرون اعتراضات في الأسلوب: يتم تشفير البيانات المرسلة باستخدام مفتاح SSH العام للعميل وفك تشفيرها باستخدام المفتاح الخاص ، أو: يتم استخدام خوارزمية RSA لتشفير البيانات أثناء الإرسال.
سأحاول أن أضفي بعض الوضوح على تشغيل بروتوكول SSH ، وفي الوقت نفسه فكر في دور خوارزمية RSA ومفاتيح ترخيص المستخدم ...
يمكن تقسيم خوارزمية بروتوكول SSH إلى ثلاثة مستويات ، يقع كل منها فوق المستوى السابق: النقل (فتح قناة آمنة) ، الاستيقان ، الاتصال. من أجل سلامة الصورة ، سأضيف أيضًا مستوى إعداد اتصال الشبكة ، على الرغم من أن هذا المستوى رسميًا أقل من SSH.
1. إنشاء اتصال TCP
لن أسهب في الحديث عن مبدأ مكدس TCP / IP ، حيث أن هذا الموضوع موثق جيدًا في Runet. إذا لزم الأمر ، يمكنك العثور على المعلومات بسهولة.
عند هذه النقطة ، يتصل العميل بالخادم على منفذ TCP المحدد في خيار المنفذ (افتراضي: 22) في ملف تكوين الخادم / etc / ssh / sshd_config.
2. فتح قناة آمنة
2.1 تبادل الهويةبعد إنشاء اتصال TCP ، يتبادل العميل والخادم (المشار إليهما فيما بعد بالأطراف) إصدارات بروتوكول SSH والبيانات الداعمة الأخرى اللازمة لتحديد توافق البروتوكول وتحديد خوارزميات التشغيل.
2.2 اختيار الخوارزميات: تبادل المفاتيح والتشفير والضغط ، إلخ.عند العمل مع SSH ، يتم استخدام عدد غير قليل من الخوارزميات ، يتم استخدام بعضها للتشفير ، والثاني لتبادل المفاتيح ، والثالث لضغط البيانات المرسلة ، إلخ. في هذه الخطوة ، يرسل الطرفان بعضهما البعض قوائم الخوارزميات المدعومة ، والخوارزميات في أعلى كل قائمة لها الأولوية القصوى. بعد ذلك ، تتم مقارنة الخوارزميات في القوائم التي تم الحصول عليها مع الخوارزميات المتاحة في النظام ، ويتم تحديد أول خوارزمية متطابقة في كل قائمة.
يمكن عرض قائمة خوارزميات تبادل المفاتيح المتوفرة من جانب العميل (المستخدمة للحصول على مفتاح جلسة) باستخدام الأمر:
ssh -Q kex
قائمة الخوارزميات المتماثلة المتاحة في النظام (المستخدمة لتشفير القناة):
ssh -Q cipher
قائمة الأنواع الرئيسية للتفويض لدى العميل:
ssh -Q key-cert
تم التحديث بالملاحظة onix74 :جميع الأوامر المستخدمة في المنشور ذات صلة بـ OpenSSH الإصدار 7.6 من Ubuntu 18.04 LTS.
2.3 الحصول على مفتاح تشفير الجلسةقد تختلف عملية الحصول على مفتاح جلسة اعتمادًا على إصدار الخوارزمية ، ولكنها بشكل عام تتلخص في ما يلي:
يتم إنشاء مفتاح جلسة حصريًا طوال عمر القناة ويتم إتلافه عند إغلاق الاتصال.
3. مصادقة العميل
والآن فقط ، عندما يقوم العميل والخادم بإنشاء قناة لنقل البيانات المشفرة ، يمكنهم المصادقة باستخدام كلمة مرور أو مفاتيح.
بشكل عام ، تتم المصادقة الرئيسية على النحو التالي:
- يرسل العميل إلى الخادم اسم مستخدم (اسم مستخدم) ومفتاحه العام.
- يقوم الخادم بالتحقق من الملف /home/username/.ssh/authorized_keys للمفتاح العام الذي يرسله العميل. إذا تم العثور على المفتاح العام ، يقوم الخادم بإنشاء رقم عشوائي وتشفيره باستخدام المفتاح العام للعميل ، وبعد ذلك يتم إرسال النتيجة إلى العميل.
- يقوم العميل بفك تشفير الرسالة بمفتاحه الخاص وإرسال النتيجة إلى الخادم.
- يتحقق الخادم من نتيجة المطابقة مع الرقم الذي تم تشفيره في الأصل باستخدام المفتاح العام للعميل ، وإذا كان مطابقًا ، فإنه يعتبر أن المصادقة ناجحة.
4. مستوى الاتصال
بعد تنفيذ جميع الإجراءات المذكورة أعلاه ، يحصل المستخدم على فرصة إرسال أوامر إلى الخادم أو نسخ الملفات.
على هذا المستوى ، يتم توفيره: مضاعفة القنوات (القدرة على تشغيل قنوات متعددة لخادم واحد من خلال دمجها في قناة واحدة) ، والأنفاق ، إلخ.
من النظرية إلى الممارسة
حسنًا ، الآن ، أعتقد أن القراء لديهم سؤال منطقي تمامًا: لماذا تحتاج إلى معرفة كل هذه التفاصيل من بروتوكول SSH ، إذا كان هناك عمل يومي كافٍ لأوامر إنشاء المفاتيح (ssh-keygen) ، وفتح جلسة طرفية (ssh) ، ونقل الملفات ( scp)؟
كإجابة ، يمكننا أن نتذكر موضوع تغيير منفذ SSH القياسي إلى البعض الآخر ، والذي يصبح باستمرار سبب holivar على Habr ...
في ممارستي الخاصة ، لا أتذكر خادمًا واحدًا ينظر إلى الشبكة الخارجية التي لن يتم النقر عليها يوميًا في المنفذ 22. في الحالة التي يعمل فيها SSH من أجلك على منفذ قياسي (ولا يكون محميًا بأي شيء) ، حتى إذا كانت المصادقة عن طريق المفاتيح فقط ولا توجد تخمينات لكلمة المرور مخيفة ، فعندئذ بسبب الطلبات الكاذبة باستمرار من العملاء غير النزيهين ، لا يزال الخادم مضطرًا للقيام بالكثير من العمل غير المجدي: إنشاء اتصال TCP وتحديد الخوارزميات وإنشاء مفتاح جلسة وإرسال طلبات المصادقة وكتابة ملف سجل.
في الحالة التي لا يوجد فيها شيء على المنفذ 22 ، أو يكون المنفذ محميًا باستخدام iptables (أو الوظائف الإضافية مثل fail2ban) ، سيسقط المهاجم في مرحلة إنشاء اتصال TCP.
الوصف الأكثر إثارة للاهتمام يشبه الجدول *
| التكوين | فرصة القرصنة | خسائر الفيضانات ** |
|---|
22 ميناء
ترخيص كلمة المرور ،
بدون حماية | عالية | عالية |
22 ميناء
إذن رئيسي ،
بدون حماية | المتوسط *** | عالية |
22 ميناء
إذن رئيسي ،
الحماية على أساس تقييد محاولات الترخيص الفاشلة | منخفض | متوسط **** |
منفذ غير قياسي ،
ترخيص كلمة المرور ،
بدون حماية | عالية | منخفض |
منفذ غير قياسي ،
إذن رئيسي ،
بدون حماية | المتوسط *** | منخفض |
منفذ غير قياسي ،
إذن رئيسي ،
الحماية على أساس تقييد محاولات الترخيص الفاشلة | منخفض | منخفض |
* - قيم المعلمات (عالية ، متوسطة ، منخفضة) ذات طبيعة نسبية ولا تستخدم إلا لمقارنة المؤشرات.
** - هذا يعني استهلاك موارد الخادم (المعالج ، القرص ، قناة الشبكة ، إلخ) لمعالجة سيل هائل من الطلبات التي تذهب عادةً إلى المنفذ 22.
*** - القرصنة إذا تم استخدام مفاتيح RSA للتفويض أمر صعب للغاية ، ولكن عددًا غير محدود من محاولات التفويض يجعل ذلك ممكنًا.
**** - عدد محاولات التفويض محدود ، ولكن لا يزال يتعين على الخادم معالجتها من عدد كبير من المتطفلين.
مواد إضافية