أساسيات إدارة مفاتيح 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 على كل خادم هو قائمة الأجهزة المسموح لها بالدخول.

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

مع مفتاح واحد لكل جهاز، لا يكلفك الحاسوب المحمول المفقود سوى سطر واحد لكل خادم: احذف سطر الحاسوب المحمول من 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؛ ويوجد السطر نفسه في الـ journal: 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. يحتفظ الوكيل (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، هو النصف الوحيد الذي يُشارَك أبدًا.

بمجرد أن يصبح مفتاحك موثوقًا في تسجيل دخولك، اتخذ الخطوة التالية وعطّل مصادقة كلمة المرور، حتى لا تنجح محاولات التخمين المستمرة على خادمك أبدًا. الإعداد الجاهز لذلك موجود في تحصين 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 في سجل المصادقة أو الـ journal الخاص بالخادم.

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

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

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

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