تقوية SSH: مفاتيح ed25519 وتعطيل كلمات المرور خطوة بخطوة
استبدل الدخول بكلمة مرور بمفتاح ed25519، ثم عطّل PasswordAuthentication ودخول root نهائياً. هذا يقفل الباب أمام محاولات التخمين الآلية التي تقصف كل سيرفر عام بعشرات الآلاف من المحاولات شهرياً.
أهم خطوة أمنية على أي سيرفر لينكس هي إلغاء الدخول بكلمة المرور عبر SSH والاعتماد على مفاتيح التشفير. السبب مباشر: كل سيرفر بعنوان عام يتلقّى محاولات تخمين آلية مستمرة، عشرات الآلاف شهرياً من عناوين حول العالم تجرّب أسماء مستخدمين وكلمات مرور شائعة. طالما الدخول بكلمة المرور مفعّل، يبقى بابك مفتوحاً بقدر قوة كلمة مرورك، وكلمة واحدة مسرّبة أو ضعيفة تكفي لاختراقك. المفتاح يغيّر المعادلة: يولّد زوجاً، خاصاً يبقى عندك وعاماً تضعه على السيرفر، ولا يمكن الدخول إلا لمن يملك المفتاح الخاص، وهو مفتاح يستحيل عملياً تخمينه. الجواب المباشر بأربع خطوات: ولّد مفتاح ed25519، انشر العام على السيرفر، اختبر الدخول به، ثم عطّل PasswordAuthentication ودخول root في إعداد SSH وأعد تشغيل الخدمة. بعدها تصير محاولات التخمين بلا معنى لأن السيرفر لا يقبل كلمات مرور أصلاً.
لماذا ed25519 أفضل من RSA
حين تولّد مفتاحاً، تختار خوارزميته. ed25519 هو الخيار الحديث الموصى به، وهو أفضل من RSA التقليدي لعدة أسباب عملية. مفتاح ed25519 قصير جداً (نحو 68 محرفاً للعام) مقارنة بمفتاح RSA بطول 4096 بت، ومع ذلك يوفّر أماناً مكافئاً أو أعلى. توليده أسرع، والتحقق منه أسرع، وهو أقل عرضة لأخطاء الإعداد التي تضعف مفاتيح RSA القصيرة. القاعدة البسيطة: استخدم ed25519 دائماً في المفاتيح الجديدة، ولا تولّد RSA بأقل من 3072 بت إن اضطررت لاستخدامه لتوافق نظام قديم. الجدول يوضّح المقارنة:
| المعيار | RSA | ed25519 |
|---|---|---|
| طول المفتاح العام | طويل (سطور) | قصير (سطر واحد) |
| سرعة التوليد والتحقق | أبطأ | أسرع |
| الأمان عند الطول الافتراضي | يحتاج 3072 بت فأكثر | قوي افتراضياً |
| حساسية الإعداد | أعلى | أقل |
توليد المفتاح ونشره
تولّد المفتاح على جهازك أنت لا على السيرفر، لأن المفتاح الخاص يجب ألا يغادر جهازك أبداً. أمر التوليد ينشئ ملفين: الخاص (يبقى سرياً بأذونات صارمة) والعام بامتداد .pub. احمِ المفتاح الخاص بعبارة مرور (passphrase) قوية، فحتى لو سُرق جهازك يبقى المفتاح مقفلاً. النشر يعني إضافة المفتاح العام إلى ملف authorized_keys في حساب المستخدم على السيرفر، وأداة ssh-copy-id تفعل ذلك بأمر واحد. بعد النشر، جرّب الدخول بالمفتاح قبل أي شيء آخر، هذه خطوة حرجة: تأكد فعلياً أنك تدخل بالمفتاح بنجاح قبل أن تعطّل كلمة المرور، وإلا قد تقفل نفسك خارج السيرفر. هذه الحماية أساس تشغيل أي خادم سحابي يحمل نظامك المخصّص.
تعطيل كلمة المرور ودخول root
بعد أن تتأكد أن الدخول بالمفتاح يعمل، تعدّل ملف إعداد SSH لتقفل الأبواب الأخرى. اضبط PasswordAuthentication على no ليرفض السيرفر أي محاولة دخول بكلمة مرور نهائياً، فتصبح كل هجمات التخمين بلا جدوى. اضبط PermitRootLogin على no لتمنع الدخول المباشر بحساب root، فالمهاجم لو حاول لا يعرف حتى اسم المستخدم الصحيح، وتصير كل عملية إدارية عبر مستخدم عادي يرفع صلاحياته بـ sudo، ما يترك أثراً في السجلّات. اضبط أيضاً PubkeyAuthentication على yes للتأكيد. بعد كل تعديل أعد تشغيل خدمة SSH، واحتفظ بجلسة مفتوحة أثناء الاختبار حتى تتأكد أنك لم تقفل نفسك، ثم افتح جلسة جديدة للتحقق.
دور تغيير المنفذ الحقيقي
ينصح كثيرون بتغيير منفذ SSH من 22 إلى رقم آخر، ومن المهم فهم ما يفعله هذا وما لا يفعله. تغيير المنفذ لا يزيد أمانك الحقيقي، فمن يملك أداة مسح يكتشف المنفذ الجديد في ثوانٍ. فائدته الوحيدة عملية: يقلّل الضجيج في سجلّاتك، لأن أغلب محاولات التخمين الآلية تستهدف المنفذ 22 فقط، فبنقلك عنه تختفي آلاف محاولات الضجيج من السجلّ، ما يسهّل رصد التهديد الجاد. اعتبره تنظيفاً لا حماية، والحماية الفعلية من المفاتيح وتعطيل كلمة المرور. لا تعتمد على إخفاء المنفذ كطبقة أمان لأنه ليس كذلك.
ربط ذلك بحظر التخمين على مستوى السيرفر
تعطيل كلمة المرور يقفل باب التخمين، لكن يبقى مفيداً أن تحظر العناوين التي تحاول بإصرار، لتخفيف الحمل والضجيج. هنا يدخل دور أداة مثل CrowdSec أو fail2ban التي ترصد محاولات الدخول الفاشلة المتكرّرة وتحظر مصدرها على مستوى الجدار الناري. الجمع قوي: المفاتيح تجعل التخمين مستحيلاً، وأداة الحظر تطرد الماسحات المزعجة قبل أن تستهلك موارد أو تملأ سجلّاتك. أضف إلى ذلك تحديث النظام بانتظام، وتقييد المستخدمين المسموح لهم بـ SSH عبر AllowUsers، فتبني دفاعاً متعدّد الطبقات حول أهم باب في سيرفرك.
حماية المفتاح الخاص نفسه
أمانك كله معلّق بسرّية المفتاح الخاص. احمِه بعبارة مرور، ولا تنسخه إلى سيرفرات أو خدمات مشتركة، ولا ترفعه إلى مستودع كود أبداً. استخدم مفتاحاً مختلفاً لكل جهاز إن أمكن، حتى لو تلوّث جهاز تُلغي مفتاحه وحده دون أن تعيد توليد كل شيء. حين يغادر موظف، احذف مفتاحه العام من authorized_keys على السيرفرات، فإلغاء الوصول يتم بحذف مفتاح لا بتغيير كلمة مرور مشتركة.
إدارة المفاتيح في فريق يكبر
حين ينتقل سيرفرك من إدارة فرد إلى فريق، تصير إدارة المفاتيح مسألة تنظيم لا مجرد أمان. كل عضو يولّد مفتاحه الخاص على جهازه ويعطيك العام فقط، فلا يوجد مفتاح مشترك يتنقّل بين الأجهزة أبداً. تجمع المفاتيح العامة لكل من يحتاج وصولاً وتضيفها إلى authorized_keys، فتعرف بالضبط من يملك وصولاً بالاسم. حين يغادر عضو، تحذف مفتاحه العام وحده، فينتهي وصوله فوراً دون أن تُربك البقية أو تغيّر شيئاً لهم. هذا الفصل هو ما يجعل نموذج المفاتيح أنظف بمراحل من كلمة مرور مشتركة يعرفها الجميع ويصعب تغييرها عند رحيل أحدهم.
في الفرق الأكبر يصير التوزيع اليدوي متعباً، فتلجأ إلى أداة إدارة إعدادات تنشر ملف authorized_keys على كل السيرفرات من مصدر واحد. تعدّل قائمة المفاتيح في مكان مركزي، فتنتشر على عشرات السيرفرات باتساق، وتلغي وصول شخص من كل مكان بخطوة واحدة. هذا يزيل خطر أن تنسى حذف مفتاح على سيرفر منسي يبقى باباً مفتوحاً بعد رحيل صاحبه.
وكيل المفاتيح وإعادة التوجيه
وكيل SSH يحتفظ بمفتاحك مفكوكاً في الذاكرة بعد أن تدخل عبارة المرور مرة، فلا تعيد كتابتها كل اتصال. مفيد، لكن انتبه لميزة إعادة توجيه الوكيل (agent forwarding): لا تفعّلها نحو سيرفرات لا تثق بها تماماً، لأن من يسيطر على ذلك السيرفر قد يستغل وكيلك للاتصال بأماكن أخرى باسمك. القاعدة: فعّل إعادة التوجيه فقط نحو سيرفرات تديرها أنت وتثق بها، واتركها معطّلة افتراضياً. الأمان الجيّد لا يعني تعقيداً، بل قرارات واضحة في المواضع الحسّاسة.
ماذا لو فقدت مفتاحك
سؤال يقلق كثيرين: ماذا لو ضاع جهازي الذي يحمل المفتاح الخاص؟ لهذا تحتفظ دائماً بأكثر من وسيلة وصول: مفتاح احتياطي على جهاز آخر آمن مضاف مسبقاً إلى authorized_keys، أو وصول عبر لوحة تحكم السيرفر التي تتيح جلسة طرفية مستقلة عن SSH. حين يضيع مفتاح، تدخل بالوسيلة الاحتياطية، تحذف المفتاح المفقود من authorized_keys فوراً لتلغي وصوله، ثم تولّد مفتاحاً جديداً. الاستعداد لهذا السيناريو قبل وقوعه هو الفرق بين مضايقة عابرة وقفل كامل خارج سيرفرك.
احتفظ أيضاً بسجلّ واضح لأي مفتاح على أي سيرفر. مع مرور الوقت وتعدّد السيرفرات، يسهل أن تنسى مفتاحاً قديماً بقي مضافاً على جهاز لم يعد يُستخدم، فيبقى باباً منسيّاً. راجع ملفات authorized_keys دورياً واحذف كل مفتاح لم تعد تعرف صاحبه أو حاجته. الأمان لا يُبنى مرة ويُترك، بل يُراجع كما تراجع حساباتك، فمفتاح منسيّ اليوم قد يصير ثغرة غداً.
الخلاصة: خطوات عملية
ولّد مفتاح ed25519 على جهازك واحمِه بعبارة مرور، انشر العام على السيرفر بـ ssh-copy-id، واختبر الدخول بالمفتاح فعلياً. عطّل PasswordAuthentication وPermitRootLogin في إعداد SSH وأعد تشغيل الخدمة مع جلسة اختبار مفتوحة. غيّر المنفذ لتقليل الضجيج فقط لا كحماية، وأضف أداة حظر تخمين مثل CrowdSec، وقيّد المستخدمين. لو تشغّل نظاماً مخصّصاً أو بريداً مؤسسياً على سيرفر سعودي بزمن استجابة نحو 8ms من الرياض، فراجع الأسعار والباقات واختر باقة تناسب حملك، أو ابدأ بـالاستضافة السحابية المُدارة حيث الوصول الآمن مضبوط من البداية.
