أساسيات إدارة مفاتيح SSH: إنشاء المفتاح وإلغاؤه

كيف تعمل مفاتيح SSH

مفتاح SSH هو زوج من الملفات: مفتاح خاص يبقى على جهازك، ومفتاح عام تنسخه إلى كل خادم تريد تسجيل الدخول إليه. عند الاتصال، يستخدم الخادم المفتاح العام لإرسال تحدٍّ لا يستطيع الإجابة عنه إلا المفتاح الخاص المطابق. لا يغادر المفتاح الخاص جهازك، لذلك لا ينتقل أي سر عبر الشبكة، ولا يملك الخادم المخترق شيئاً مفيداً لسرقته. لهذا تتفوق المفاتيح على كلمات المرور. وتعتمد إدارة مفاتيح SSH جيداً على أربع عادات: استخدام مفتاح واحد لكل جهاز، وضبط أذونات الملفات التي يطلبها sshd، وإنشاء ملف ~/.ssh/config حتى تتوقف عن كتابة الخيارات يدوياً، ومعرفة كيفية إزالة مفتاح في اليوم الذي يُفقد فيه حاسوب محمول.

يغطي هذا الدليل كل عادة من هذه العادات على Ubuntu 24.04، مع أن كل ما يرد هنا تقريباً ينطبق على أي خادم Linux وعلى أي إصدار حديث من OpenSSH.

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

إنشاء مفتاح: ed25519 هو الخيار الافتراضي المناسب

نفّذ الأمر التالي على جهازك، وليس على الخادم:

ssh-keygen -t ed25519 -C "laptop"

يحدّد -t ed25519 نوع المفتاح. يُعد Ed25519 الخيار الافتراضي الحديث: مفاتيحه قصيرة وسريعة، وتدعمه جميع إصدارات OpenSSH منذ 2014. استخدم ssh-keygen -t rsa -b 4096 فقط عندما تحتاج إلى الاتصال بجهاز قديم لا يفهم ed25519. يضيف -C "laptop" تعليقاً. لا يؤدي التعليق وظيفة تشفيرية، لكنه يساعدك على التعرّف إلى هذا المفتاح في ملف authorized_keys على الخادم بعد عامين، لذلك سمِّ الجهاز الذي يوجد عليه المفتاح.

يطلب ssh-keygen تحديد مكان حفظ المفتاح. اقبل القيمة الافتراضية، ~/.ssh/id_ed25519. سيطلب منك بعد ذلك عبارة مرور. عيّن عبارة مرور؛ يوضّح قسم عبارات المرور أدناه سبب عدم تسببها في أي تكلفة يومية عليك. سينتهي بك الأمر إلى ملفين: ~/.ssh/id_ed25519 هو المفتاح الخاص، و~/.ssh/id_ed25519.pub هو المفتاح العام. اعرض الجزء العام:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

إنه سطر واحد يتكوّن من نوع المفتاح، وبيانات المفتاح، وتعليقك. هذا السطر هو ما سيُضاف إلى خوادمك.

مفتاح واحد لكل جهاز، وليس مفتاحاً واحداً لكل خادم

السؤال الذي يطرحه الجميع أولاً هو: هل أحتاج إلى مفتاح جديد لكل خادم؟ لا. أنشئ مفتاحاً واحداً لكل جهاز تكتب منه، وضع ذلك المفتاح العام على كل خادم يحتاج الجهاز إلى الوصول إليه. يعرّف المفتاح الجهاز. وملف authorized_keys على كل خادم هو قائمة الأجهزة المسموح لها بالدخول.

هذا هو النموذج القابل للتوسع، أما البدائل فتفشل بطرق متوقعة. إذا استخدمت مفتاحاً لكل خادم، فسيحمل حاسوب محمول يتصل بـ20 خادماً 20 مفتاحاً خاصاً، وستفقد القدرة على تمييزها بسهولة. أما مشاركة مفتاح واحد بين جميع أجهزتك فهي أسوأ. عند سرقة الحاسوب المحمول، لن تتمكن من إلغاء وصوله من دون منع حاسوبك المكتبي من الوصول أيضاً، لأن الجهازين يحتويان على المفتاح الخاص نفسه. لذلك ستضطر إلى استبدال المفتاح على كل الخوادم وإعادة توزيعه على كل الأجهزة في الوقت نفسه.

مع استخدام مفتاح واحد لكل جهاز، تقتصر تكلفة فقدان الحاسوب المحمول على حذف سطر واحد من كل خادم: احذف سطر الحاسوب المحمول من authorized_keys، وستواصل جميع الأجهزة الأخرى العمل. والتعليق الذي تحدده باستخدام -C هو ما يجعل العثور على هذا السطر سهلاً.

القاعدة التي يقوم عليها هذا النموذج هي: يُنشأ المفتاح الخاص على جهاز، وينتهي بانتهاء ذلك الجهاز. لا تنسخ مفتاحاً خاصاً إلى جهاز ثانٍ، ولا ترفع مفتاحاً خاصاً إلى خادم. عندما يحتاج جهاز جديد إلى الوصول، أنشئ مفتاحاً جديداً عليه.

ضع المفتاح العام على الخادم

المسار الأسهل هو ssh-copy-id، وهو يأتي مع OpenSSH:

ssh-copy-id matt@10.0.0.10

يسجّل الدخول باستخدام وسيلة المصادقة التي ما تزال تعمل، وغالباً تكون كلمة مرور، ثم يضيف مفتاحك العام إلى ~/.ssh/authorized_keys على الخادم. كما ينشئ الدليل والملف بالأذونات الصحيحة إذا لم يكونا موجودين. اختبر ذلك بفتح جلسة SSH جديدة. يجب أن يسمح لك الخادم بالدخول دون طلب كلمة مرور الحساب. إذا كان مفتاحك محمياً بعبارة مرور، فقد يطلب جهازك هذه العبارة بدلاً من ذلك. هذا الطلب محلي وليس كلمة مرور الخادم.

عندما يكون تسجيل الدخول باستخدام كلمة المرور معطلاً مسبقاً، لا يستطيع ssh-copy-id الدخول. لذلك أضف السطر يدوياً. سجّل الدخول عبر جلسة ما تزال تعمل، أو عبر وحدة تحكم الويب التي يوفرها مزود الخدمة، ثم نفّذ هذا الأمر على الخادم:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

ألصق مفتاحك العام الفعلي داخل علامتي الاقتباس، وهو السطر الكامل المفرد من id_ed25519.pub. يحتوي authorized_keys على مفتاح عام واحد في كل سطر، وتشكل هذه الأسطر قاعدة بيانات الوصول بالكامل: إضافة جهاز تعني إلحاق سطر، وإلغاء وصول جهاز يعني حذف سطر. على خادم جديد، تُنفَّذ هذه الخطوة ضمن أول 10 دقائق على VPS جديد، مباشرة قبل تعطيل تسجيل الدخول باستخدام كلمة المرور.

الصلاحيات التي تعطل تسجيل الدخول بالمفتاح

هذه هي الطريقة الأكثر شيوعاً لفشل تسجيل الدخول بالمفتاح، ويفشل ذلك بصمت من جهة العميل. يعمل sshd باستخدام StrictModes yes افتراضياً على Ubuntu 24.04، ولذلك يرفض استخدام ملف authorized_keys يمكن لمستخدمين آخرين تعديله. إذا كان الملف أو الدليل ~/.ssh أو الدليل المنزلي الخاص بك قابلاً للكتابة من أي مستخدم غيرك، فإن sshd يتجاهل مفتاحك ويعود إلى طلب كلمة مرور، من دون عرض أي تفسير على العميل. (يتسامح OpenSSH في Ubuntu مع حالة ضيقة واحدة فقط: أن يكون الملف قابلاً للكتابة من مجموعة خاصة بك، على ألا يكون أي مستخدم آخر عضواً فيها. لا تعتمد على هذه الحالة؛ التزم بالأوضاع أدناه.) يظهر السبب فقط في سجل الخادم:

sudo grep 'Authentication refused' /var/log/auth.log

في صورة نظام مصغّرة لا تحتوي على rsyslog، لا يوجد auth.log؛ ويظهر السطر نفسه في السجل التشغيلي عبر: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

القاعدة التي يجب تذكرها: 700 على الدليل .ssh، و600 على كل ما بداخله. تنطبق الأرقام نفسها على حاسوبك، لأن العميل يتحقق أيضاً. إذا كان بإمكان مستخدمين آخرين قراءة مفتاح خاص، فإن ssh يرفض المفتاح مباشرة، ويكون الخطأ هذه المرة واضحاً:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

يُصلح chmod 600 ~/.ssh/id_ed25519 ذلك.

~/.ssh/config: لا تكتب الخيارات يدوياً كل مرة

يمنحك ملف ~/.ssh/config على جهازك اسماً مختصراً لكل خادم، ويحفظ الخيارات التي تكتبها باستمرار. أنشئه بصلاحيات 600، وأضف كتلة Host لكل خادم:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

يستبدل ssh web1 الآن ssh -p 22 matt@10.0.0.10، ويعمل الاسم المختصر نفسه في scp وrsync وgit، لأن هذه الأدوات تقرأ الملف نفسه. يحدد HostName العنوان الفعلي، ويوفر لك User كتابة اسم الحساب، ويثبت IdentityFile المفتاح الذي سيعرضه العميل.

يستحق IdentitiesOnly yes شرحاً موجزاً، لأنه يعالج فشلاً محيّراً. عندما يحتفظ وكيل المفاتيح بعدة مفاتيح، يعرضها العميل واحداً تلو الآخر، ويحتسب الخادم كل عرض محاولة فاشلة. إذا كان عدد المفاتيح المحمّلة كبيراً بما يكفي، تحصل على Received disconnect: Too many authentication failures قبل تجربة المفتاح الصحيح. يجعل IdentitiesOnly yes العميل يعرض المفتاح المحدد في IdentityFile فقط، ولذلك لا يحدث هذا الفشل.

عبارات المرور و ssh-agent

تشفّر عبارة المرور ملف المفتاح الخاص على القرص. من دونها، يمكن لأي شخص ينسخ الملف استخدامه فوراً؛ أما معها، فيصبح الملف المسروق عديم الفائدة إلى أن تُخمَّن عبارة المرور. بالنسبة إلى مفتاح موجود على حاسوب محمول، هذه هي الحماية المطلوبة تحديداً، لأن الحواسيب المحمولة قد تُسرق، وقد تتسرّب نسخها الاحتياطية.

والسبب في أن عبارة المرور لا تفرض تكلفة عملية هو ssh-agent. يحتفظ الوكيل بمفتاحك بعد فك تشفيره في الذاكرة، لذلك تكتب عبارة المرور مرة واحدة لكل جلسة تسجيل دخول، ويصبح كل اتصال لاحق فورياً. تشغّل معظم توزيعات Linux المكتبية وmacOS وكيلاً نيابةً عنك مسبقاً. حمّل مفتاحك إليه باستخدام:

ssh-add ~/.ssh/id_ed25519

يعرض ssh-add -l المفاتيح التي يحتفظ بها الوكيل حالياً. تنبيه مهم: يتيح تمرير الوكيل (ssh -A) للخادم البعيد استخدام وكيلك للمصادقة على اتصالات لاحقة أثناء اتصالك به، لذلك لا تفعّله إلا للخوادم التي تثق بها تماماً، واتركه معطلاً افتراضياً.

التدوير والإبطال: إجراء التعامل مع الحاسوب المحمول المفقود

لا يتطلب إبطال مفتاح SSH عادي أكثر من إزالة السطر الخاص به من authorized_keys في كل خادم يحتوي عليه. لا توجد جهة إصدار شهادات لإخطارها، ولا تاريخ انتهاء يجب انتظاره. وبمجرد إزالة السطر، تفشل عمليات تسجيل الدخول الجديدة باستخدام ذلك المفتاح.

نفّذ هذا الإجراء الآن، ما دام الأمر غير طارئ. اختر خادماً، وافتح ~/.ssh/authorized_keys، وابحث عن المفتاح باستخدام التعليق الخاص به. احذف السطر باستخدام محرر، أو استبعده وفقاً للتعليق:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

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

التدوير هو العملية نفسها ولكن بترتيب مختلف: أنشئ مفتاحاً جديداً على الجهاز، وثبّته باستخدام ssh-copy-id، وتحقّق من أن المفتاح الجديد يتيح تسجيل الدخول، ثم احذف السطر القديم. نفّذ ذلك عند انتقال الجهاز إلى مستخدم آخر، أو عند احتمال انكشاف المفتاح، أو عند مغادرة أحد أفراد الفريق. تنفيذ ذلك يدوياً عبر خادمين أمر مقبول؛ أما عبر عشرين خادماً فهو مهمة مناسبة للأتمتة، ويوضح إدارة عدة خوادم Linux كيفية دفع حالة authorized_keys نفسها إلى مجموعة خوادم كاملة.

ما يجب تجنّبه

• لا تستخدم مفتاحاً خاصاً واحداً على جميع أجهزتك. فهذا يجعل إبطال جهاز واحد مسروق أمراً مستحيلاً من دون استبدال المفتاح في كل مكان.

• لا تضع مفتاحاً خاصاً في مستودع git، حتى إن كان المستودع خاصاً. تراقب أدوات الفحص الآلية المستودعات العامة وتحاول استخدام المفاتيح المتسرّبة خلال دقائق من تنفيذ push، كما أن جعل المستودع عاماً لاحقاً يؤدي إلى تسريب تاريخه بالكامل.

• لا ترفع المفتاح الخاص لحاسوبك المحمول إلى خادم كي يتمكن ذلك الخادم من الوصول إلى خادم آخر. أنشئ مفتاحاً منفصلاً على الخادم نفسه، وفوّض ذلك المفتاح في المكان المطلوب تحديداً.

• لا تلصق مفتاحاً خاصاً في محادثة أو رسالة بريد إلكتروني أو تذكرة. المفتاح العام، وهو الملف .pub، هو الجزء الوحيد الذي تتم مشاركته على الإطلاق.

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

FAQ

كيف تعمل مفاتيح SSH من دون إرسال كلمة مرور؟

يحتفظ الخادم بمفتاحك العام في ~/.ssh/authorized_keys. عند تسجيل الدخول، يرسل الخادم تحدياً، ويوقّع عميلك التحدي بالمفتاح الخاص، ثم يتحقق الخادم من التوقيع باستخدام المفتاح العام. لا يغادر المفتاح الخاص جهازك، لذلك لا يوجد ما يمكن اعتراضه أثناء النقل، ولا شيء قابل لإعادة الاستخدام لسرقته من الخادم. لا يسرّب الخادم المخترق إلا المفاتيح العامة، ولا يمكن استخدامها لتسجيل الدخول إلى أي مكان.

هل ينبغي أن أستخدم مفتاح SSH نفسه مع جميع خوادمي؟

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

ما الأذونات التي ينبغي أن تكون لدليل .ssh وauthorized_keys؟

اضبط 700 على ~/.ssh، واضبط 600 على authorized_keys وعلى كل مفتاح خاص، على أن تكون ملكيتها للحساب الذي يستخدمها. يعمل sshd افتراضياً باستخدام StrictModes yes، لذلك إذا كان بإمكان أي شخص غيرك الكتابة إلى ملف أو إلى الدليل الرئيسي، فسيتجاهل مفتاحك بصمت، وسيكون الأثر الوحيد هو Authentication refused: bad ownership or modes في سجل auth أو journal على الخادم.

كيف أزيل مفتاح SSH من خادم؟

احذف سطر المفتاح من ~/.ssh/authorized_keys في الحساب الذي سُمح للمفتاح باستخدامه. اعثر على السطر الصحيح من خلال تعليقه، أي التسمية التي تأتي بعد مادة المفتاح. ستفشل عمليات تسجيل الدخول الجديدة باستخدام ذلك المفتاح فوراً، لكن الجلسات المفتوحة مسبقاً ستبقى مفتوحة. لذلك أنهِ أي جلسة نشطة تخص ذلك الجهاز أيضاً إذا كان قد سُرق. كرر ذلك على كل خادم نُسخ إليه المفتاح.

هل أحتاج إلى عبارة مرور لمفتاح SSH؟

نعم، إذا كان المفتاح على حاسوب محمول أو مكتبي. تشفّر عبارة المرور ملف المفتاح، لذلك تكون النسخة المسروقة أو المتسربة عديمة الفائدة بمفردها، ويعني ssh-agent أنك تكتبها مرة واحدة في كل جلسة بدلاً من كتابتها عند كل اتصال. لا تحتوي المفاتيح المستخدمة في الأتمتة غير التفاعلية على خادم عادةً على عبارة مرور، لأنه لا يوجد شخص لكتابتها. احمِ هذه المفاتيح بتقييد ما يمكن للحساب الهدف تنفيذه.