تحصين SSH على خادم VPS

لماذا SSH أول ما يجب تحصينه

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

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

الخطوة 1: تأكد أولًا من أن المصادقة بالمفتاح تعمل

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

على حاسوبك الخاص، أنشئ مفتاحًا إن لم يكن لديك واحد بالفعل:

ssh-keygen -t ed25519

انسخ الجزء العام منه إلى الخادم:

ssh-copy-id user@your-server

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

الخطوة 2: حصّن sshd بملف drop-in

لا تعدّل /etc/ssh/sshd_config مباشرة. فـ Ubuntu 24.04 يقرأ ملفات drop-in من /etc/ssh/sshd_config.d/، وملف صغير هناك أنظف، ويصمد أمام ترقيات الحزم، ويسهل حذفه إن ساءت الأمور. الاسم مهم: يحتفظ sshd بأول قيمة يقرؤها لكل إعداد، وصور Ubuntu السحابية تأتي بملف 50-cloud-init.conf وبداخله PasswordAuthentication yes في هذا الدليل ذاته. سمِّ ملفك ببادئة 00- ليُرتَّب قبل ذلك الملف ويفوز عليه؛ أما ملف ببادئة 99- فيخسر بصمت. أنشئ واحدًا:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

ضع فيه ما يلي:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

كل سطر يغلق بابًا. PasswordAuthentication no هو الأهم: فمع تعطيل كلمات المرور، لا يبقى لهجوم القوة الغاشمة شيء يهاجمه. KbdInteractiveAuthentication no يغلق مسارًا ثانيًا شبيهًا بكلمة المرور. PermitRootLogin no يعني أن على المهاجم أن يعرف اسم المستخدم لديك ويملك مفتاحك، لا أن يستهدف فقط الحساب الوحيد، root، الموجود على كل خادم.

الخطوة 3: اختبر الإعدادات، ثم أعد التحميل

تحقق من الإعدادات بحثًا عن أخطاء قبل تطبيقها، حتى لا يعطّل خطأ كتابي الخدمة:

sudo sshd -t

إن لم يطبع شيئًا، فالإعدادات صحيحة. أعد تحميل SSH:

sudo systemctl reload ssh

ثم تحقق من الإعدادات التي يستخدمها sshd فعليًا، حتى تكتشف ملف drop-in خسر أمام ملف آخر:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

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

الخطوة 4: المنفذ غير القياسي الاختياري

نقل SSH من المنفذ 22 إلى منفذ مثل 2222 لا يجعله أكثر أمانًا بأي معنى حقيقي، لأن المهاجم المصمم يمسح كل المنافذ. ما يفعله هذا الإجراء هو تقليل ضجيج السجلّات، لأن معظم أدوات المسح الآلي تجرّب المنفذ 22 فقط. إن أردت ذلك، أضف Port 2222 إلى ملف drop-in الخاص بك، واسمح بالمنفذ الجديد في جدار الحماية أولًا، ثم نفّذ sudo systemctl daemon-reload && sudo systemctl restart ssh.socket واتصل بالأمر ssh -p 2222. على Ubuntu 24.04، ssh.socket هو من يملك منفذ الاستماع، لذا فإن reload ssh وحدها تُبقي sshd على المنفذ 22؛ وإعادة تشغيل الـ socket هي ما يجعله يبدأ الاستماع على المنفذ الجديد. عامل هذا الإجراء بوصفه ترتيبًا، لا حماية.

الخطوة 5: أضف طبقات الدفاع الإضافية

مفاتيح SSH المحصّنة هي الأساس، وتوجد طبقتان إضافيتان تُبنيان فوقها.

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

والأقوى من ذلك أن تُبقي SSH خارج الإنترنت العام كليًا. فإن وضعت SSH خلف شبكة WireGuard VPN وحصرت المنفذ 22 بجدار الحماية على النفق فقط، فلن يستطيع أحد خارج الـ VPN الوصول إليه أصلًا، ويتحول التخمين بالقوة الغاشمة من صعب إلى مستحيل. وكل هذا يفترض وجود جدار حماية يرفض افتراضيًا في الأساس، وهو ما يوفره إعداد UFW على الخادم.

SSH ليس إلا بندًا واحدًا من قائمة تحقق أكبر: أول 10 دقائق على خادم VPS جديد يرتب الخطوات، والتحديثات الأمنية التلقائية على Ubuntu تبقي الخادم مُحدَّثًا بعد ذلك.

FAQ

كيف أعطّل تسجيل الدخول بكلمة المرور لـ SSH على Ubuntu 24.04؟

أنشئ ملف drop-in في /etc/ssh/sshd_config.d/00-hardening.conf (بادئة 00 تجعله يُرتَّب قبل 50-cloud-init.conf، الذي كان PasswordAuthentication yes فيه سيفوز لولا ذلك، لأن sshd يحتفظ بأول قيمة يقرؤها) يحتوي على PasswordAuthentication no وKbdInteractiveAuthentication no، ونفّذ sudo sshd -t للتحقق منه، ثم sudo systemctl reload ssh. تأكد من أن تسجيل الدخول بالمفتاح يعمل في جلسة جديدة قبل أن تعتمد عليه. تعديل ملف drop-in بدلًا من sshd_config يصمد أمام ترقيات الحزم ويسهل التراجع عنه.

هل ينبغي أن أعطّل دخول root عبر SSH؟

نعم. اضبط PermitRootLogin no حتى لا يستطيع أحد تسجيل الدخول مباشرة كـ root. سجّل الدخول بمستخدمك العادي واستخدم sudo للمهام الإدارية. root موجود على كل خادم Linux، فترك الوصول إليه متاحًا يمنح المهاجم اسم مستخدم معروفًا يستهدفه. تعطيله يعني أنه يجب أن يعرف اسم حسابك ويملك مفتاحك.

هل يجعل تغيير منفذ SSH خادمي أكثر أمانًا؟

ليس بمعنى حقيقي. الانتقال من المنفذ 22 يخفيك عن أدوات المسح الكسولة التي تفحص المنفذ 22 فقط، مما يقلل ضجيج السجلّات، لكن المهاجم الحقيقي يمسح كل المنافذ ويجدك على أي حال. المصادقة بالمفاتيح فقط هي ما يوقف الاختراقات فعليًا. إن غيّرت المنفذ، افتح الجديد في جدار الحماية أولًا، ثم نفّذ sudo systemctl daemon-reload && sudo systemctl restart ssh.socket؛ فعلى Ubuntu 24.04 الـ socket هو من يملك منفذ الاستماع، وإعادة التحميل العادية تُبقي sshd على المنفذ 22.

هل أحتاج إلى Fail2ban إن كنت أستخدم مفاتيح SSH؟

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

كيف أستعيد الوصول إن حبست نفسي خارج SSH؟

استخدم وحدة التحكم عبر الويب لدى مزوّد الخدمة، التي تصل إلى الخادم عبر اتصال تسلسلي أو VNC لا يمر عبر SSH. من هناك يمكنك تسجيل الدخول، وإصلاح ملف drop-in الخاص بـ sshd، وإعادة تحميل الخدمة. هذا بالضبط سبب اختبارك لإعدادات SSH جديدة في طرفية ثانية قبل إغلاق جلستك الأولى، وسبب ضرورة أن تعمل المصادقة بالمفتاح مسبقًا قبل أن تعطّل كلمات المرور.