بقلم تأمين SSH على VPS: مفاتيح فقط وتعطيل root
أمّن VPS خطوة بخطوة: اختبر دخول المفاتيح أولاً، ثم عطّل root وكلمات المرور عبر drop-in config، وأضف Fail2ban وVPN لتقليل محاولات التخمين.
لماذا يجب أن يكون SSH أول ما تؤمّنه
SSH هو الطريقة التي تتحكم بها في خادمك، ولذلك فهو نقطة الدخول التي يحاول كل مهاجم استهدافها أولاً. وبمجرد اتصال VPS بالإنترنت، تبدأ أدوات الفحص بتخمين أسماء المستخدمين وكلمات المرور على المنفذ 22. ويمكنك مراقبة ذلك في السجلات خلال دقائق. يهدف تأمين SSH إلى إزالة الأمور التي يمكن للمهاجمين تخمينها: عطّل تسجيل الدخول باستخدام كلمة المرور بالكامل، وعطّل تسجيل الدخول إلى حساب root، واسمح فقط باستخدام المفاتيح التشفيرية. بعد تنفيذ ذلك، لن تنجح محاولات التخمين المستمرة ببساطة، لأنه لا توجد كلمة مرور يمكن العثور عليها.
يفترض ذلك أن SSH يعمل لديك مسبقاً. إذا كان بإمكانك تسجيل الدخول، فيمكنك تأمينه. نفّذ الخطوات بالترتيب، وأبقِ جلستك الحالية مفتوحة حتى تنجح جلسة جديدة، حتى لا يؤدي أي خطأ إلى منعك من الوصول.
الخطوة 1: تأكد أولاً من عمل المصادقة بالمفاتيح
تستبدل المصادقة بالمفاتيح كلمة المرور بزوج من المفاتيح: مفتاح خاص يبقى على جهازك، ومفتاح عام تضعه على الخادم. يثبت الخادم أنك تملك المفتاح الخاص من دون أن يغادر هذا المفتاح جهازك. قبل تعطيل كلمات المرور، تأكد من عمل المفاتيح، وإلا فقد تمنع نفسك من الوصول إلى الخادم.
على جهازك، أنشئ مفتاحاً إذا لم يكن لديك مفتاح:
ssh-keygen -t ed25519انسخ الجزء العام إلى الخادم:
ssh-copy-id user@your-serverثم افتح جلسة SSH جديدة. إذا سمح لك بالدخول من دون طلب كلمة مرور، فهذا يعني أن مفتاحك يعمل ويمكنك تعطيل كلمات المرور بأمان. إذا أوقفك بالخطأ Permission denied (publickey)، فإن هذا الخطأ الواحد يخفي خمسة أعطال مختلفة، ويخبرك ناتج ssh -v بأي عطل لديك قبل أن تغيّر أي شيء آخر. إذا كانت المفاتيح جديدة عليك، أو كنت تستخدم أكثر من جهاز، فإن أساسيات إدارة مفاتيح 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 على VPS.
يمثل SSH بنداً واحداً ضمن قائمة تحقق أكبر: يضع أول 10 دقائق على VPS جديد الخطوات بالترتيب، وتحافظ التحديثات الأمنية التلقائية على Ubuntu على تحديث الخادم بعد ذلك. لا يحمي إغلاق هذا الباب الخدمات الموجودة خلفه، لذلك إذا كان VPS نفسه يشغّل خزنة كلمات مرور، فإن مراجعة تحصين Vaultwarden تغطي الأمرين اللذين لا تتعامل معهما المصادقة بالمفاتيح: رمز المسؤول وملف النسخ الاحتياطي.
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 عملية الاستماع، لذلك يترك reload عادي sshd مستمعاً على المنفذ 22.
هل أحتاج إلى Fail2ban إذا كنت أستخدم مفاتيح SSH؟
استخدامه اختياري، لكنه يظل مفيداً. مع تفعيل المصادقة بالمفاتيح فقط، لا يمكن أن تنجح محاولات تخمين كلمات المرور، لذلك ليس Fail2ban هو ما يمنع المهاجمين من الدخول. فهو يحد معدل الإخفاقات المتكررة من عنوان واحد، مما يقلل ضجيج أدوات الفحص في سجلاتك ويطرد المهاجمين المتكررين مبكراً. أما الهجوم البطيء والموزع فيبقى دون حد الحظر الخاص به على أي حال. شغّله إلى جانب المصادقة بالمفاتيح، ويفضل أن تُبقي SSH خلف VPN.
كيف أستعيد الوصول إذا منعت نفسي من تسجيل الدخول عبر SSH؟
استخدم وحدة التحكم على الويب التي يوفرها مزودك. فهي تصل إلى الخادم عبر اتصال تسلسلي أو VNC لا يمر عبر SSH. من هناك، يمكنك تسجيل الدخول وإصلاح ملف drop-in sshd ثم إعادة تحميل الخدمة. لهذا السبب تحديداً تختبر إعداد SSH الجديد في طرفية ثانية قبل إغلاق جلستك الأولى. ولهذا يجب أن تكون المصادقة بالمفاتيح تعمل مسبقاً قبل تعطيل كلمات المرور.