ما هو SSH وكيف يعمل؟ شرح الاتصال الآمن بالخوادم

ما هو SSH؟

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

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

المشكلة التي صُمّم SSH لحلها

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

كتب Tatu Ylönen أول إصدار من SSH في عام 1995 في Helsinki University of Technology، بعد هجوم لالتقاط كلمات المرور على شبكة الجامعة. يحافظ التصميم على الجزء المفيد من Telnet، وهو تدفق بايتات بين الطرفية وshell عن بُعد، ويضيف الأمرين اللذين لا يملك Telnet حلاً لهما: تشفير التدفق، وإثبات أن الخادم الموجود في الطرف الآخر هو الخادم الذي قصدت الوصول إليه.

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

آلية عمل نموذج العميل والخادم

هناك برنامجان. على الخادم، يعمل sshd باستمرار وينتظر الاتصالات. وعلى جهازك، ينشئها ssh. هذان برنامجان منفصلان بملفي إعداد منفصلين، والخلط بينهما هو السبب الأكثر شيوعاً لعدم تأثير التعديل.

• يقرأ الخادم /etc/ssh/sshd_config. في هذا الملف يُعطَّل تسجيل الدخول بكلمة المرور ويُحدَّد منفذ الاستماع.
• يقرأ العميل /etc/ssh/ssh_config للإعدادات الافتراضية للنظام، ثم يقرأ ~/.ssh/config لإعداداتك الخاصة بكل مضيف.

في Debian وUbuntu، تُسمّى وحدة الخدمة ssh. وفي RHEL وRocky وFedora، تُسمّى sshd. تثبّت إصدارات Ubuntu الحديثة هذه الخدمة بحيث تُفعَّل عبر المقبس، لذلك قد يعرض systemctl status ssh القيمة inactive (dead) بينما يكون الجهاز قابلاً للوصول بشكل طبيعي، لأن ssh.socket هي الوحدة التي تستمع للاتصالات وتبدأ الخدمة عند الطلب.

لا يشترط أن يكون العميل OpenSSH. فـPuTTY على Windows، وTermius على الهاتف، وميزات الدعم عن بُعد المضمّنة في المحررات، كلها تستخدم البروتوكول نفسه مع sshd نفسه. ويتضمن Windows 10 و11 أيضاً عميل OpenSSH، لذلك يعمل ssh you@server في PowerShell دون تثبيت أي شيء.

لماذا يستخدم SSH المنفذ 22؟

المنفذ هو رقم يحدد للنواة البرنامج الذي يستمع للاتصال الوارد، وتعمل المنافذ في Linux بالطريقة نفسها مع كل خدمة. يستخدم SSH المنفذ 22 لأن IANA خصصته له في 1995. طلب Ylönen رقماً متاحاً بجوار البروتوكولات التي كُتب SSH ليحل محلها: كان 21 مخصصاً لـFTP، و23 لـtelnet، بينما كان 22 غير مستخدم.

بما أن 22 هو الإعداد الافتراضي، تفترضه كل الأدوات. يحاول مستودع Git النصي، والبرنامج النصي للنسخ الاحتياطي، ولوحة التحكم لدى مزودك استخدام 22 أولاً. وينطبق الأمر نفسه على كل ماسح آلي على الإنترنت. يبدأ خادم جديد مع تفعيل تسجيل الدخول بكلمة المرور في جمع أسطر مثل هذا السطر في /var/log/auth.log خلال دقائق من الإقلاع:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

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

يمكنك مراقبة رد الخادم قبل تسجيل الدخول إليه:

nc 203.0.113.10 22

في Ubuntu 24.04، يطبع ذلك شيئاً قريباً من SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13. تُرسل الرسالة التعريفية بنص واضح، قبل تفعيل أي تشفير، لأن الطرفين يحتاجان إليها للاتفاق على إصدار البروتوكول. اضغط على Ctrl+C لإغلاق الاتصال.

ماذا يحدث على الشبكة عند الاتصال

التسلسل التالي هو ما ينفّذه أحد ssh you@server قبل أن يظهر لك موجه الأوامر.

1. يحل العميل اسم المضيف إلى عنوان IP، ثم يفتح اتصال TCP بالمنفذ 22.
2. يرسل الطرفان ترويسة الإصدار الخاصة بهما بنص واضح.
3. يرسل الطرفان قوائم الخوارزميات التي يدعمانها: تبادل المفاتيح، والتشفير، ومصادقة الرسائل، والضغط. وتبقى هذه البيانات بنص واضح. ويُختار أقوى خيار يعرفه كلا الطرفين.
4. يُجرى تبادل المفاتيح. يفضّل OpenSSH حالياً curve25519-sha256. وينتهي الطرفان إلى امتلاك السر المشترك نفسه من دون أن يعبر هذا السر الشبكة مطلقاً، لذلك لا يستطيع من سجّل المحادثة كاملةً استنتاجه لاحقاً.
5. يوقّع الخادم نتيجة ذلك التبادل باستخدام مفتاحه الخاص بالمضيف. ويتحقق العميل من التوقيع بمقارنته بمفتاح المضيف العام المحفوظ لديه. تمنع هذه الخطوة جهازاً موجوداً بين الطرفين من انتحال هوية خادمك.
6. يبدأ التشفير. يُعد chacha20-poly1305@openssh.com التشفير الافتراضي في إصدارات OpenSSH الحالية.
7. عندها فقط يصادق العميل عليك باستخدام كلمة مرور أو مفتاح. وينتقل اسم المستخدم وكلمة المرور داخل القناة المشفّرة.
8. يفتح العميل قناة ويطلب shell.

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

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

مفتاح المضيف، ومطالبة بصمة الاتصال الأول

عند تثبيت openssh-server، ينشئ أزواج مفاتيح المضيف للجهاز ويكتبها في /etc/ssh/، مثل ssh_host_ed25519_key وssh_host_ed25519_key.pub. لا يغادر الجزء الخاص الخادم أبداً. أما الجزء العام فهو هوية الخادم، وتُتحقق التوقيعة في الخطوة 5 بمقابلته.

في المرة الأولى التي تتصل فيها بخادم جديد، لا يملك العميل شيئاً يقارنه به، لذلك يطلب منك:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

البصمة هي تجزئة SHA256 للمفتاح العام للمضيف، وتُطبع بترميز base64، ولذلك تكون قصيرة بما يكفي لمقارنتها بصرياً. يؤدي إدخال yes إلى كتابة ذلك المفتاح في ~/.ssh/known_hosts على جهازك. في كل اتصال لاحق بالعنوان نفسه، يقارن العميل المفتاح الذي يقدمه الخادم بالمفتاح المخزّن. عند تطابقهما، لا يُطبع شيء وتنتقل مباشرة إلى موجه الأوامر.

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

يطبع ذلك سلسلة SHA256: نفسها التي عرضتها المطالبة. وُجد خيار [fingerprint] في المطالبة لهذا الغرض تحديداً: ألصق البصمة المتوقعة، ولن يواصل العميل إلا إذا طابقت ما قدّمه الخادم.

في Debian وUbuntu، تكون known_hosts مجزأة افتراضياً، لذلك يحتوي الملف على أسطر تبدأ بـ |1| بدلاً من أسماء المضيفين المقروءة. شغّل ssh-keygen -F 203.0.113.10 للعثور على الإدخال الخاص بأحد المضيفين.

لماذا يقول SSH إن مفتاح المضيف تغيّر؟

ستصادف عاجلاً أم آجلاً هذه الكتلة الطويلة من النص:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

تنتهي الرسالة بـ Host key verification failed.، ويرفض العميل الاتصال. كما تطبع Password authentication is disabled to avoid man-in-the-middle attacks.، لأن إدخال كلمة مرورك في جهاز غير معروف هو بالضبط الضرر الذي وُجد هذا التحقق لمنعه.

تبدو الرسالة كأنها حالة طارئة، لكنها في معظم الأحيان ليست كذلك. الأسباب المعتادة:

• أعدت إنشاء الخادم أو تثبيته، ولذلك أنشأ sshd مفاتيح مضيف جديدة عند الإقلاع الأول. وهذا هو السبب الأكثر شيوعاً بفارق كبير.
• حذفت VPS وأنشأت آخر، ومنح مزود الخدمة الجهاز الجديد عنوان IP القديم.
• تتصل عبر forward أو load balancer يوجّه الاتصالات الآن إلى جهاز backend مختلف.
• هناك جهة تعترض الاتصال فعلاً.

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

ssh-keygen -R 203.0.113.10

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

المصادقة بكلمة مرور مقابل المصادقة بمفتاح

ترسل مصادقة كلمة المرور كلمة مرورك داخل القناة المشفّرة مسبقاً، ثم يتحقق sshd منها مقابل قاعدة بيانات الحسابات، عادةً عبر PAM (وحدات المصادقة القابلة للتوصيل). لا تتطلب هذه الطريقة أي إعداد مسبق. لذلك يستطيع مزود الخدمة تسليمك خادماً جديداً لا يحتوي إلا على كلمة مرور root.

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

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

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

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

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

لا يخبرك العميل إلا بـ Permission denied (publickey)، وهي الرسالة نفسها لعشرات الأسباب المختلفة. لذلك يجدر بك تعلّم قراءة خطأ المفتاح العام بطريقة صحيحة قبل أن تُمنع من الوصول. تندرج المهام العملية لإنشاء المفاتيح وحمايتها بعبارة مرور وتحميلها إلى وكيل ضمن إدارة مفاتيح SSH، بينما يندرج تعطيل تسجيل الدخول بكلمة مرور من دون فقدان الوصول ضمن تأمين SSH على VPS.

يستخدم SFTP وscp وإعادة توجيه المنافذ الاتصال نفسه

هذه هي الفكرة التي توضّح بقية عالم SSH. تفتح المصادقة اتصالاً مشفراً، ويمكن لهذا الاتصال حمل عدة قنوات مستقلة في الوقت نفسه. وتُعد الصدفة نوعاً واحداً من عدة أنواع للقنوات.

• صدفة بعيدة. يفتح ssh you@server قناة جلسة ويطلب صدفة تفاعلية.
• أمر واحد. يفتح ssh you@server uptime قناة، وينفّذ أمراً واحداً، ويطبع الناتج، ثم يخرج.
• SFTP. يطلب العميل من sshd تشغيل النظام الفرعي sftp الخاص به، وتتم عملية نقل الملفات داخل الاتصال نفسه. SFTP هو بروتوكول لنقل الملفات يعمل عبر SSH، ولا يشترك في تصميمه مع FTP. أما البروتوكول الذي يُضاف إليه التشفير إلى FTP فيُسمى FTPS، وهو غير مرتبط بذلك.
• scp. ينسخ الملفات باستخدام تسجيل الدخول نفسه. منذ إصدار OpenSSH 9.0 في عام 2022، يستخدم scp بروتوكول SFTP في الخلفية افتراضياً.
• إعادة توجيه المنافذ. يحوّل ssh -L 8080:localhost:80 you@server المنفذ 8080 على حاسوبك المحمول إلى مدخل للمنفذ 80 على الخادم، عبر الاتصال المشفّر. ويعيد -R التوجيه في الاتجاه المعاكس، بينما يحوّل -D 1080 الجلسة إلى وكيل SOCKS.
• Git. المورد البعيد مثل git@github.com:user/repo.git هو تسجيل دخول عبر SSH، ويشغّل طرفه البعيد معالج أوامر بدلاً من الصدفة.
• rsync وAnsible هما أيضاً عميلان لـSSH. يفتحان قناة، وينفّذان شيئاً ما، ثم يقرآن الناتج.

يستخدم كل عنصر في هذه القائمة المنفذ نفسه، وفحص مفتاح المضيف نفسه، وبيانات الاعتماد نفسها. لذلك فإن إعداد مصادقة المفاتيح مرة واحدة يحقق الفائدة مباشرة: ترثها كل هذه الأدوات. ولهذا السبب أيضاً فإن ملف ~/.ssh/config نفسه الذي يختصر عمليات تسجيل الدخول هو الملف الذي يتوسع استخدامه عندما تكون تدير عدة خوادم Linux من حاسوب محمول واحد.

ما الذي لا يفعله SSH

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

إلى أين تتابع من هنا

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

FAQ

ماذا يعني اختصار SSH؟

يعني SSH الصدفة الآمنة. وهو بروتوكول لتسجيل الدخول إلى حاسوب بعيد وتنفيذ الأوامر عليه عبر اتصال مشفّر، وقد عُرِّف في RFC 4251 إلى RFC 4254. أما OpenSSH فهو التطبيق الذي يستخدمه الجميع تقريباً: عميل ssh على جهازك، وخادم sshd على الجهاز البعيد. وقد حل محل telnet، الذي كان يرسل كل شيء، بما في ذلك كلمات المرور، عبر الشبكة بنص واضح.

لماذا يستخدم SSH المنفذ 22؟

خصّصت IANA المنفذ 22 لـSSH في عام 1995، بجوار FTP على المنفذ 21 وtelnet على المنفذ 23، وهما البروتوكولان اللذان صُمم SSH ليحل محلهما. لا يفرض شيء استخدام هذا الرقم: يغيّره Port في /etc/ssh/sshd_config على الخادم، ويختار ssh -p منفذاً مختلفاً على العميل. وبما أن 22 هو المنفذ الافتراضي، تفحصه الأدوات الآلية باستمرار، ولذلك يمتلئ /var/log/auth.log على الخادم الجديد بأسطر Failed password for invalid user. يؤدي تغيير المنفذ إلى تقليل هذه الضوضاء، لكنه لا يضيف حماية فعلية.

ماذا أفعل عندما يحذّر SSH من تغيّر مفتاح المضيف؟

حدّد السبب قبل أن تحذف أي شيء. السبب المعتاد غير خطير: أُعيد بناء الخادم، ولذلك أنشأ sshd مفاتيح مضيف جديدة، أو أُعطي جهاز جديد عنوان IP القديم. إذا كنت تعرف أن الجهاز أُعيد بناؤه، فنفّذ ssh-keygen -R <host> لحذف المفتاح المخزّن، ثم أعد الاتصال وقارن البصمة التي تظهر لك بالبصمة التي تعرضها وحدة تحكم مزوّد الخدمة. إذا لم يتغير شيء من جانبك، فلا تتصل ولا تكتب كلمة مرورك. يرفض OpenSSH بالفعل مصادقة كلمة المرور في هذه الحالة لهذا السبب تحديداً.

هل يختلف SFTP وscp عن SSH؟

يعملان فوقه. بعد إتمام المصادقة، يمكن لاتصال SSH حمل عدة قنوات، وتكون الصدفة واحدة منها فقط. SFTP هو بروتوكول لنقل الملفات يستخدم النظام الفرعي sftp في sshd عبر الاتصال نفسه، كما أن scp يستخدم بروتوكول SFTP في الخلفية منذ OpenSSH 9.0. ويُعد تمرير المنافذ وGit عبر SSH قنوات على الاتصال نفسه أيضاً. تستخدم هذه القنوات جميعاً المنفذ نفسه، وفحص مفتاح المضيف نفسه، وتسجيل الدخول نفسه. لاحظ أن SFTP ليس FTP مضافاً إليه التشفير؛ فهذا يسمى FTPS وهو بروتوكول منفصل.

هل المصادقة بالمفتاح أفضل فعلاً من كلمة المرور؟

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