خطوات تأمين سيرفرات VPS: تغيير منفذ SSH الافتراضي وتفعيل مفاتيح SSH Keys لمنع هجمات التخمين

يُعد SSH من أهم وسائل إدارة خوادم VPS عن بُعد، ولذلك فإن أي إعداد ضعيف في خدمة SSH قد يزيد من محاولات تسجيل الدخول الآلية وهجمات التخمين. من الخطوات المفيدة لتقوية الخادم استخدام SSH Keys بدلاً من الاعتماد على كلمات المرور، وتقييد الوصول، واستخدام جدار ناري، ومراجعة إعدادات OpenSSH بعناية.
في هذا الدليل نشرح خطوات تأمين سيرفر VPS وتغيير منفذ SSH الافتراضي وتفعيل مفاتيح SSH Keys على خوادم Linux. كما نوضح ما الذي يحققه تغيير المنفذ فعلياً، وكيفية تجنب فقدان الوصول إلى السيرفر أثناء تعديل الإعدادات.
لماذا تتعرض خوادم SSH لمحاولات تسجيل دخول مستمرة؟
الخوادم المتصلة بالإنترنت تتعرض عادةً لعمليات فحص آلية تبحث عن خدمات متاحة، ومن بينها SSH. وقد تحاول برمجيات آلية تجربة أسماء مستخدمين وكلمات مرور شائعة.
لهذا لا ينبغي الاعتماد على سرية عنوان الخادم أو رقم المنفذ وحدها. الحماية الأساسية تأتي من مصادقة قوية، وتحديثات مستمرة، وجدار ناري، وتقليل الحسابات والصلاحيات.
هل تغيير منفذ SSH يمنع الاختراق؟
لا. تغيير المنفذ الافتراضي يمكن أن يقلل جزءاً من الضوضاء ومحاولات التخمين الآلية التي تستهدف المنفذ 22 مباشرة، لكنه ليس حاجزاً أمنياً قوياً بمفرده، لأن خدمة SSH يمكن اكتشافها على منفذ آخر.
اعتبر تغيير المنفذ إجراءً تنظيمياً إضافياً، وليس بديلاً عن SSH Keys وتعطيل تسجيل الدخول بكلمة المرور عند التأكد من عمل المفاتيح.
قبل أي تعديل: لا تغلق جلسة SSH الحالية
من أهم قواعد تعديل SSH أن تبقي الجلسة الحالية مفتوحة حتى تختبر اتصالاً جديداً بنجاح. خطأ في ملف الإعداد أو الجدار الناري قد يمنعك من العودة إلى الخادم.
تأكد أيضاً من وجود وسيلة استرداد عبر لوحة مزود VPS، مثل Web Console أو Serial Console، إذا كانت متاحة.
تحديث النظام أولاً
على Ubuntu أو Debian يمكن مراجعة تحديثات النظام:
sudo apt update
sudo apt upgrade
على خادم إنتاج، راجع تأثير التحديثات المهمة وخطة إعادة التشغيل قبل تطبيقها.
معرفة إصدار OpenSSH
يمكن التحقق من عميل SSH باستخدام:
ssh -V
كما يمكن مراجعة حزمة خادم OpenSSH عبر مدير الحزم. استخدام إصدار مدعوم ومحدث جزء أساسي من حماية الخدمة.
إنشاء مستخدم إداري بدلاً من العمل اليومي بحساب root
إذا كانت بيئتك تعتمد على root مباشرة، فمن الأفضل في كثير من الحالات إنشاء مستخدم إداري عادي ومنحه صلاحيات sudo المناسبة.
مثال على Ubuntu/Debian:
sudo adduser adminuser
sudo usermod -aG sudo adminuser
استبدل adminuser باسم مناسب، وتأكد من أن sudo يعمل لهذا الحساب قبل تغيير إعدادات root.
ما هي SSH Keys؟
تعتمد مصادقة المفاتيح على زوج من المفاتيح: مفتاح خاص يبقى على جهاز المستخدم، ومفتاح عام يُضاف إلى حساب المستخدم على الخادم.
لا ترسل المفتاح الخاص إلى السيرفر ولا تشاركه مع الآخرين. المفتاح العام فقط هو الذي يُنسخ إلى ملف authorized_keys.
إنشاء مفتاح SSH حديث
على جهازك المحلي يمكن استخدام خوارزمية Ed25519 عندما تكون مدعومة:
ssh-keygen -t ed25519 -a 64
اتبع التعليمات واختر عبارة مرور قوية للمفتاح الخاص، خصوصاً إذا كان الجهاز المحمول أو الحاسوب قد يتعرض للسرقة.
أين يتم حفظ المفاتيح؟
تُحفظ المفاتيح عادةً داخل مجلد ~/.ssh في جهاز العميل. ستجد ملفاً خاصاً وملفاً عاماً ينتهي غالباً بـ .pub.
لا تنشر محتوى المفتاح الخاص ولا تضعه في مستودع Git أو مساحة تخزين عامة.
نسخ المفتاح العام إلى VPS
إذا كانت أداة ssh-copy-id متاحة، يمكن استخدامها:
ssh-copy-id adminuser@SERVER_IP
استبدل اسم المستخدم وعنوان الخادم بالقيم الصحيحة. ويمكن أيضاً إضافة المفتاح العام يدوياً إلى:
~/.ssh/authorized_keys
مع التأكد من الملكية والصلاحيات الصحيحة.
ضبط صلاحيات مجلد SSH
على حساب المستخدم في الخادم، من الإعدادات الشائعة:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
وتأكد من أن الملفات مملوكة للمستخدم الصحيح. قد يرفض OpenSSH استخدام المفاتيح إذا كانت الصلاحيات غير آمنة.
اختبار تسجيل الدخول بالمفتاح
قبل تعطيل كلمات المرور، افتح نافذة Terminal جديدة واختبر:
ssh adminuser@SERVER_IP
لا تتابع إلى تعطيل Password Authentication إلا بعد نجاح الاتصال بالمفتاح من جلسة جديدة.
أين يوجد ملف إعداد SSH Server؟
يوجد الملف الرئيسي غالباً في:
/etc/ssh/sshd_config
وقد تستخدم الإصدارات الحديثة أيضاً ملفات إضافية داخل مجلد مثل sshd_config.d. راجع الإعداد الفعلي قبل التعديل، لأن قيمة في ملف إضافي قد تؤثر على النتيجة.
عمل نسخة احتياطية من إعداد SSH
قبل التعديل:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
النسخة المحلية مفيدة للتراجع السريع، لكن لا تعتمد عليها كوسيلة الاسترداد الوحيدة إذا فقدت الاتصال بالخادم.
تغيير منفذ SSH الافتراضي
اختر منفذاً غير مستخدم ومسموحاً به في بيئتك، ثم عدّل إعداد Port. مثال:
Port 2222
الرقم 2222 مجرد مثال وليس منفذاً “سرياً”. افحص تعارضه مع الخدمات الأخرى وسياسات مزود الاستضافة.
افتح المنفذ الجديد في الجدار الناري قبل إعادة تشغيل SSH
إذا كنت تستخدم UFW، اسمح بالمنفذ الجديد أولاً:
sudo ufw allow 2222/tcp
ثم تحقق:
sudo ufw status
إذا كان مزود VPS يستخدم Cloud Firewall أو Security Groups، يجب تحديثها أيضاً. فتح UFW وحده لا يكفي إذا كانت طبقة الشبكة الخارجية تمنع المنفذ.
اختبار صياغة إعداد SSH
قبل تطبيق التغييرات استخدم:
sudo sshd -t
إذا لم يظهر خطأ، يمكن إعادة تحميل أو إعادة تشغيل الخدمة حسب نظامك:
sudo systemctl reload ssh
وفي بعض الأنظمة قد يكون اسم الوحدة sshd.
اختبار المنفذ الجديد
من نافذة جديدة:
ssh -p 2222 adminuser@SERVER_IP
احتفظ بالجلسة القديمة مفتوحة حتى تتأكد أن الاتصال الجديد يعمل بالمفتاح وبالمنفذ الجديد.
تعطيل تسجيل الدخول بكلمة المرور
بعد نجاح SSH Keys، يمكن تقوية المصادقة بإيقاف كلمات المرور. في إعداد OpenSSH:
PasswordAuthentication no
PubkeyAuthentication yes
راجع أيضاً أي إعدادات إضافية أو آليات مصادقة قد تؤثر على السلوك. ثم نفذ sshd -t قبل Reload واختبر جلسة جديدة.
تقييد تسجيل دخول root
إذا كنت تستخدم حساباً إدارياً مع sudo، يمكن تقييد تسجيل الدخول المباشر لـ root. أحد الإعدادات الممكنة:
PermitRootLogin no
لا تطبق هذا قبل التأكد أن الحساب الإداري البديل يستطيع تسجيل الدخول بالمفتاح واستخدام sudo بنجاح.
تقليل المستخدمين المسموح لهم عبر SSH
يمكن استخدام إعدادات مثل AllowUsers لتحديد الحسابات التي يُسمح لها بالدخول عبر SSH:
AllowUsers adminuser
استخدم هذا فقط إذا كنت تعرف جميع الحسابات الإدارية المطلوبة، خصوصاً في الخوادم التي يديرها أكثر من شخص.
تقييد SSH بعنوان IP عند الإمكان
إذا كنت تدير الخادم دائماً من عنوان IP ثابت أو شبكة إدارية معروفة، يمكن للجدار الناري السماح بالاتصال من هذا المصدر فقط.
هذا يقلل مساحة التعرض بشكل كبير، لكنه غير مناسب إذا كان عنوان اتصالك يتغير باستمرار ما لم يكن لديك VPN أو طريقة وصول إدارية مستقرة.
Fail2ban كطبقة إضافية
يمكن لـ Fail2ban مراقبة محاولات تسجيل الدخول وتطبيق حظر مؤقت على مصادر تتجاوز حدوداً محددة. لكنه ليس بديلاً عن مفاتيح SSH وتعطيل كلمات المرور.
إذا كانت Password Authentication معطلة ولا توجد حسابات ضعيفة، يقل تأثير كثير من هجمات التخمين التقليدية أصلاً.
لا تحظر نفسك باستخدام Fail2ban
اضبط القواعد بعناية واختبرها. إعدادات شديدة قد تحظر عنوانك الإداري بسبب أخطاء متكررة. احتفظ دائماً بمسار استرداد عبر لوحة مزود VPS.
استخدام SSH Agent
يساعد SSH Agent على إدارة المفتاح الخاص دون كتابة عبارة المرور في كل اتصال. لكن حماية الجهاز المحلي تبقى ضرورية، لأن اختراق جهاز الإدارة قد يعرّض جلساتك ومفاتيحك للخطر.
استخدام عبارة مرور للمفتاح الخاص
المفتاح الخاص المحمي بعبارة مرور يوفر طبقة إضافية إذا تم نسخ ملف المفتاح من جهازك. اختر عبارة قوية وفريدة ولا تخزنها بجانب المفتاح كنص واضح.
إنشاء مفتاح منفصل لكل مسؤول أو جهاز
لا تشارك مفتاحاً خاصاً واحداً بين فريق كامل. استخدم مفاتيح منفصلة، بحيث يمكن إلغاء مفتاح جهاز أو مستخدم محدد دون التأثير على الجميع.
راجع authorized_keys دورياً واحذف المفاتيح التي لم تعد مستخدمة.
إلغاء مفتاح SSH قديم
لحظر مفتاح لم تعد تثق به، احذف السطر الخاص بمفتاحه العام من authorized_keys للحساب المعني، ثم اختبر أن المفاتيح الصحيحة ما زالت تعمل.
إذا اشتبهت بتسريب مفتاح خاص، اعتبره غير موثوق وأنشئ زوجاً جديداً.
مراقبة محاولات تسجيل الدخول
راجع سجلات المصادقة باستخدام أدوات النظام المناسبة. في الأنظمة التي تعتمد systemd يمكن استخدام journalctl لخدمة SSH، كما توجد سجلات مصادقة تقليدية حسب التوزيعة.
راقب محاولات الدخول غير المعتادة، والحسابات المستخدمة، ومصادر الاتصال، لكن لا تعتمد على المراجعة اليدوية وحدها في بيئات مهمة.
إيقاف الخدمات غير الضرورية
تأمين SSH جزء واحد من حماية VPS. افحص الخدمات التي تستمع على الشبكة وأوقف ما لا تحتاج إليه، وقيّد قواعد الجدار الناري إلى المنافذ المطلوبة فقط.
يمكن استخدام أدوات النظام مثل ss لمراجعة المنافذ المستمعة محلياً.
لا تستخدم أوامر من الإنترنت دون فهمها
إعدادات SSH حساسة، وخطأ صغير قد يمنع الوصول إلى الخادم. لا تنسخ ملف sshd_config كاملاً من شرح قديم، لأن الخيارات المدعومة والإعدادات الافتراضية قد تختلف بين إصدارات OpenSSH.
عدّل أقل عدد ممكن من الخيارات، واختبر الصياغة والاتصال بعد كل تغيير مهم.
ترتيب آمن لتطبيق التغييرات
- تأكد من وجود Console للاسترداد لدى مزود VPS.
- حدّث النظام وOpenSSH.
- أنشئ مستخدماً إدارياً مناسباً واختبر sudo.
- أنشئ SSH Key على جهازك المحلي.
- أضف المفتاح العام إلى الخادم.
- اختبر الدخول بالمفتاح في جلسة جديدة.
- افتح منفذ SSH الجديد في كل طبقات الجدار الناري.
- غيّر Port واختبر الإعداد باستخدام sshd -t.
- أعد تحميل SSH واختبر المنفذ الجديد.
- بعد نجاح الاختبار، عطّل Password Authentication.
- قيّد root والحسابات المسموح لها وفق حاجتك.
- راقب السجلات وراجع المفاتيح والتحديثات دورياً.
أخطاء شائعة عند تأمين SSH
- إغلاق الجلسة الحالية قبل اختبار الإعداد الجديد.
- تغيير المنفذ قبل فتحه في Firewall أو Security Group.
- تعطيل كلمة المرور قبل التأكد من عمل SSH Key.
- الاعتماد على تغيير المنفذ وحده كوسيلة حماية.
- مشاركة المفتاح الخاص بين عدة مستخدمين.
- حفظ Private Key في مكان عام أو مستودع Git.
- تعديل sshd_config دون تنفيذ sshd -t.
- تعطيل root قبل تجهيز حساب sudo بديل.
- نسيان وجود إعدادات إضافية داخل sshd_config.d.
أسئلة شائعة حول تأمين SSH على VPS
هل تغيير منفذ SSH من 22 ضروري؟
ليس شرطاً للحصول على SSH آمن، لكنه قد يقلل عمليات الفحص والتخمين الآلية البسيطة. الحماية الأهم هي المفاتيح، وتعطيل المصادقة الضعيفة، والتحديثات، وتقييد الوصول.
هل SSH Keys أكثر أماناً من كلمات المرور؟
عند إنشائها وإدارتها بصورة صحيحة، توفر مفاتيح SSH مقاومة قوية لهجمات تخمين كلمات المرور. حماية المفتاح الخاص وعبارة مروره وإلغاء المفاتيح القديمة تبقى ضرورية.
ماذا أفعل إذا فقدت المفتاح الخاص؟
إذا كان لديك مفتاح إداري آخر، أضف مفتاحاً جديداً واحذف القديم عند الحاجة. إذا فقدت كل وسائل SSH، استخدم Console أو آلية الاسترداد التي يوفرها مزود VPS.
هل يمكن تعطيل root نهائياً؟
يمكن منع تسجيل دخوله مباشرة عبر SSH مع استخدام حساب إداري وsudo، لكن القرار يعتمد على تصميم النظام. تأكد من وجود طريقة إدارة واسترداد صالحة قبل التغيير.
هل Fail2ban ضروري بعد تعطيل كلمات المرور؟
قد يبقى مفيداً ضمن سياسة حماية أوسع، لكنه ليس بديلاً عن إعداد SSH السليم. قيمة استخدامه تعتمد على الخدمات الأخرى وسياسة الخادم وطريقة المصادقة.
الخلاصة
أفضل طريقة لتقوية SSH على سيرفر VPS هي الاعتماد على طبقات متعددة بدلاً من إجراء واحد. استخدم مفاتيح SSH قوية، واختبرها قبل تعطيل كلمات المرور، وقيّد حساب root والوصول الشبكي، وحافظ على تحديث OpenSSH والنظام.
أما تغيير منفذ SSH الافتراضي فيمكن أن يقلل الضوضاء ومحاولات التخمين الآلية، لكنه لا يخفي الخدمة عن الفحص المتقدم ولا يجب اعتباره بديلاً عن المصادقة القوية. والأهم أثناء كل تعديل هو إبقاء جلسة حالية مفتوحة واختبار الإعداد الجديد قبل إغلاق طريق الوصول القديم.




