إعداد الاتصال الآمن (SSH Keys) بدون كلمات مرور بين جهازك والخوادم
إعداد الاتصال الآمن SSH Keys بدون كلمات مرور بين جهازك والخوادم
يُعد الاعتماد على SSH بالمفاتيح بدلاً من كلمة المرور خطوة أساسية في أي بيئة تشغيل حديثة، سواء كنت تدير خادماً واحداً أو بنية كاملة تعتمد على CI/CD والأتمتة السحابية. هذا الأسلوب يرفع مستوى الأمان، يقلل احتمالات الهجمات المعتمدة على التخمين، ويجعل عمليات النشر والإدارة أكثر استقراراً وسرعة.
من منظور هندسي، المصادقة بالمفاتيح ليست مجرد وسيلة تسجيل دخول مريحة، بل هي طبقة تأسيسية تعتمد عليها أدوات مثل Ansible، وعمليات النشر عبر GitHub Actions، وكذلك الوصول الآمن إلى خوادم Linux داخل الشبكات الخاصة والعامة.
إذا كنت تبني مساراً احترافياً في الأتمتة، ففهم هذا الأساس يكمل ما تناولناه في مقال ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟، كما أنه ضروري قبل تطبيق النشر التلقائي كما في النشر المستمر (Continuous Deployment): رفع الكود الجديد إلى سيرفر Linux تلقائياً.
كيف تعمل مصادقة SSH Keys؟
تعتمد الفكرة على زوج من المفاتيح: مفتاح خاص Private Key يبقى على جهازك، ومفتاح عام Public Key يوضع على الخادم. عند بدء الاتصال، يتحقق الخادم من أنك تملك المفتاح الخاص المقابل للمفتاح العام المخزن لديه.
بهذا الشكل، لا تنتقل كلمة المرور عبر الشبكة، ولا تضطر إلى تخزينها داخل أدوات الأتمتة. وهذا مهم جداً عند بناء Pipelines موثوقة أو إعداد أدوات إدارة جماعية مثل ما هو Ansible؟ وكيف تتحكم في 100 سيرفر Linux من حاسوبك المكتبي؟.
لماذا يُفضّل هذا الأسلوب على كلمات المرور؟
- تقليل خطر هجمات
Brute Forceعلى منفذSSH. - سهولة الدمج مع الأتمتة دون كشف بيانات اعتماد حساسة.
- إمكانية فصل مفاتيح الوصول حسب المستخدم أو البيئة أو الخادم.
- رفع موثوقية النشر الآلي في أنظمة
Production.
لا يعني “بدون كلمة مرور” أن الوصول أصبح أقل أماناً. المقصود هو إلغاء كلمة مرور تسجيل الدخول عن بُعد، وليس ترك المفتاح الخاص بلا حماية. الأفضل دائماً حماية المفتاح بعبارة مرور
Passphraseواستخدام وكيل مفاتيح عند الحاجة.
الخطوة الأولى: توليد زوج مفاتيح على جهازك
على جهازك المحلي، أنشئ مفتاحاً جديداً باستخدام خوارزمية حديثة مثل ed25519. هذه الخوارزمية سريعة وقوية ومناسبة للاستخدامات اليومية والإنتاجية.
ssh-keygen -t ed25519 -C "admin@your-laptop"
سيُطلب منك تحديد مكان الحفظ، وغالباً يكون المسار الافتراضي داخل مجلد ~/.ssh. بعد ذلك يمكنك إضافة Passphrase لحماية المفتاح الخاص.
فهم الملفات الناتجة
id_ed25519: المفتاح الخاص، ويجب ألا يغادر جهازك.id_ed25519.pub: المفتاح العام، وهو الذي يُرسل إلى الخادم.
الخطوة الثانية: نسخ المفتاح العام إلى الخادم
الطريقة الأسهل هي استخدام أداة ssh-copy-id. ستسجّل دخولك مرة أخيرة بكلمة المرور، ثم تُضاف البصمة العامة إلى ملف authorized_keys لدى المستخدم المستهدف.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip
إذا لم تتوفر الأداة، يمكنك النسخ يدوياً. أولاً اعرض محتوى المفتاح العام:
cat ~/.ssh/id_ed25519.pub
ثم أضفه على الخادم داخل المسار الصحيح:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
الخطوة الثالثة: اختبار الاتصال بدون كلمة مرور
بعد نسخ المفتاح، اختبر تسجيل الدخول مباشرة:
ssh user@server_ip
إذا أُعد الاتصال بنجاح، فهذا يعني أن المصادقة بالمفتاح تعمل. إن ظهرت لك مطالبة بعبارة المرور Passphrase فهذا سلوك طبيعي، لأن حماية المفتاح المحلي تختلف عن كلمة مرور المستخدم على الخادم.
تسريع الاستخدام عبر ssh-agent
بدلاً من كتابة عبارة المرور في كل مرة، يمكنك تحميل المفتاح في وكيل الجلسة. هذا مفيد جداً للمطورين الذين يديرون عدداً كبيراً من الخوادم أو يشغّلون عمليات نشر متكررة خلال اليوم.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
بهذا يصبح جهازك قادراً على استخدام المفتاح طوال الجلسة الحالية دون إعادة كتابة عبارة المرور كل مرة.
ضبط الخادم لتعطيل كلمات المرور بعد نجاح الإعداد
بعد التأكد من أن الدخول بالمفتاح يعمل فعلياً، يمكنك رفع مستوى الأمان عبر تعديل إعدادات خدمة sshd. هذا يقلل سطح الهجوم بشكل كبير، خاصة على الخوادم المكشوفة على الإنترنت.
sudo nano /etc/ssh/sshd_config
تأكد من القيم التالية:
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
ثم أعد تشغيل الخدمة:
sudo systemctl restart sshd
لا تعطل
PasswordAuthenticationقبل اختبار نافذة طرفية جديدة والتأكد أن مفتاحك يعمل. كثير من حالات فقدان الوصول إلى الخوادم تنتج من تعديل مبكر لإعداداتSSHدون مسار رجوع آمن.
أفضل الممارسات في البيئات الاحترافية
1) لا تستخدم المستخدم root مباشرة
أنشئ مستخدماً عادياً ثم امنحه صلاحيات إدارية عبر sudo عند الحاجة. هذا يحسّن التتبع ويقلل مخاطر تنفيذ أوامر مدمرة بالخطأ.
2) خصص مفتاحاً لكل بيئة أو فريق
من الخطأ تشغيل كل شيء بمفتاح واحد. الأفضل فصل مفاتيح بيئة Production عن Staging وعن الأجهزة الشخصية.
3) راقب التصاريح بدقة
إذا كانت صلاحيات مجلد .ssh أو ملف authorized_keys واسعة جداً، قد يرفض الخادم المفتاح تلقائياً. هذه من أكثر مشاكل الإعداد شيوعاً.
4) استخدم المفاتيح داخل الأتمتة بطريقة آمنة
عند بناء خطوط نشر آلي، لا ترفع المفاتيح إلى المستودع البرمجي أبداً. استخدم أنظمة الأسرار كما شرحنا في إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة، ثم مرّر المفتاح وقت التشغيل فقط.
مثال عملي مع النشر المؤتمت
في كثير من المشاريع، تعتمد خطوة النشر على اتصال SSH لسحب التحديثات أو إعادة تشغيل الخدمات أو تنفيذ أوامر Docker. وهذا يرتبط طبيعياً بما تناولناه في ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ ومقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow).
مثلاً، قد تستخدم الخادم لتحديث حاويات التطبيق بعد نجاح الاختبارات، أو لتطبيق ملف docker-compose.yml كما في كتابة أول ملف docker-compose.yml خطوة بخطوة. بدون إعداد مفاتيح آمنة، تصبح عملية النشر اليدوي بطيئة وهشة وغير مناسبة للبيئات الحديثة.
أشهر المشاكل وكيفية تشخيصها
- رفض المفتاح: افحص صلاحيات الملفات على الجهاز والخادم.
- الاتصال يطلب كلمة المرور: تأكد أنك تستخدم المستخدم الصحيح وأن المفتاح العام موجود في
authorized_keys. - الخادم لا يقرأ المفتاح: راجع إعدادات
sshd_config. - مشكلات فنية مفصلة: استخدم نمط التتبع التفصيلي.
ssh -v user@server_ip
هذا الأمر يكشف أين تتوقف المصادقة: هل المفتاح غير موجود، أم أن الخادم يرفضه، أم أن الوكيل ssh-agent لم يحمّله بعد.
الخلاصة
إعداد اتصال SSH بالمفاتيح ليس رفاهية تقنية، بل معيار أساسي لأي مهندس يدير خوادم أو يبني بنية نشر موثوقة. فهو يجمع بين الأمان، السرعة، وإمكانية التوسع، ويشكّل حجر الأساس لكل ما يأتي بعده من أتمتة، إدارة جماعية، ونشر مستمر.
كلما كانت مفاتيحك منظّمة، وصلاحياتك مضبوطة، وتعطيل كلمات المرور مدروساً، أصبحت بيئة الخوادم أكثر صلابة وأقل عرضة للأخطاء أو الاختراقات. وهذه خطوة عملية لا غنى عنها قبل التوسع نحو أدوات مثل Ansible وعمليات النشر الآلي وبيئات الحاويات الحديثة.
10 comments