كيفية مشاركة بيانات دخول SSH برابط تنتهي صلاحيته بأمان

يحتاج أحدهم إلى الدخول إلى خادم الليلة، وبيانات الدخول يجب أن تصله الآن. والإغراء هو لصق المفتاح الخاص أو كلمة مرور root في Slack. لكن كل رسالة يمر بها المفتاح تحتفظ بنسخة منه، ولهذا فالطريق الأفضل رابط لمرة واحدة تنتهي صلاحيته: يُستلم المحتوى السري مرة واحدة ثم يختفي.

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

ما نوع بيانات دخول SSH التي تشاركها فعلًا؟

يمكن أن يقوم الوصول عبر SSH على أربعة أشياء مختلفة، ولكل منها قواعد مشاركة مختلفة جدًا.

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

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

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

حدّد صلاحيات بيانات الدخول قبل مشاركتها

أيًا كان ما ترسله، اجعله في أضيق حدود تسمح بها المهمة:

• حساب واحد وخادم واحد. أضف المفتاح إلى حساب الخدمة المسؤول عن العمل، لا إلى root، وعلى الجهاز المعني وحده.
• قيّد ما يستطيع المفتاح فعله بخيارات authorized_keys مثل from="203.0.113.5" أو no-port-forwarding، أو بغلاف command= حين تكون المهمة سكربتًا واحدًا.
• اجعل لكلمة المرور عمرًا محدودًا. إذا كنت تشارك كلمة مرور، فاستخدم passwd -e أو ما يعادله في المنصة حتى يُضطر المستلم إلى تغييرها عند أول تسجيل دخول، وخطط لتعطيل الحساب في تاريخ محدد.
• دوّن تاريخ النهاية قبل أن ترسل أي شيء. فعبارة «حين ينتهي العمل» ليست تاريخًا.

كيفية مشاركة بيانات دخول SSH برابط تنتهي صلاحيته بأمان

1. تأكد من المستلم عبر قناة تثق بها أصلًا: التذكرة، أو سلسلة بريد معروفة، أو مكالمة. فمعظم بيانات الدخول التي تصل إلى الشخص الخطأ سببها عنوان شبيه أو اسم أكمله الإكمال التلقائي.
2. الصق المحتوى السري وحده في أداة الرابط السري لمرة واحدة. وفي حالة المفتاح الخاص يعني ذلك كتلة PEM كاملة ولا شيء غيرها. مع LinkPilot يُشفَّر النص في متصفحك قبل تخزينه، فلا تحتفظ الخدمة إلا بالنص المشفر، ويبقى مفتاح فك التشفير في جزء من عنوان URL لا ترسله المتصفحات إلى الخوادم.
3. اجعل مدة الصلاحية بقدر نافذة الاستلام. ساعة واحدة إن كان المستلم ينتظره، و24 ساعة إن كان في منطقة زمنية أخرى، وسبعة أيام فقط حين يوجد سبب حقيقي. ويُحذف الرابط أيضًا عند أول فتح، فانتهاء الصلاحية خط دفاع احتياطي لا وسيلة التحكم الأساسية.
4. أضف عبارة مرور مع حساب Pro حين تكون بيانات الدخول حساسة، وأوصل عبارة المرور عبر قناة مختلفة. ويبيّن لك سجل التدقيق في خطة Pro أيضًا متى حدث الإظهار.
5. أرسل الرابط مع ملاحظة من سطر واحد عن الغرض منه، دون أي بيانات اتصال.
6. أرسل بيانات الاتصال في رسالة منفصلة: اسم الخادم أو عنوانه، والمنفذ، واسم المستخدم، وطريقة المصادقة. لا شيء منها سري وحده، لكنها مع المفتاح تكوّن بيانات الدخول كاملة.

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

رابط لمرة واحدة لمشاركة بيانات الوصول إلى الخادم

سؤال ما يوضع داخل المحتوى السري يتكرر في كل مرة. والقاعدة الجيدة أن يحمل الرابط ما لا يستطيع المهاجم تخمينه، وأن تحمل الرسالة العادية ما يستطيع تخمينه.

في الرابط لمرة واحدة:

• المفتاح الخاص، أو كلمة المرور المؤقتة
• عبارة مرور المفتاح إن ضُبطت عند إنشائه
• لا شيء آخر

في رسالة عادية تُرسل منفصلة:

• اسم الخادم أو عنوان IP والمنفذ
• الحساب الذي يُسجَّل الدخول به
• هل يُستخدم مفتاح أم كلمة مرور
• بصمة مفتاح الخادم، حتى يتحقق المستلم من الخادم عند أول اتصال
• ملاحظة قصيرة عن الغرض من الوصول ومتى ينتهي

أبقِ لقطات الشاشة وسجلات الطرفية خارج الاثنين. فلقطة الشاشة لجلسة عمل كثيرًا ما تتضمن رموزًا وعناوين داخلية وأسماء مستخدمين آخرين لم يكن من المفترض أن تنتقل.

ساعد المستلم على حفظ المفتاح بأمان

يفشل التسليم الآمن رغم ذلك إذا استقر المفتاح في مجلد Downloads بأذونات تسمح لأي مستخدم بقراءته. أرسل هذه التعليمات مع بيانات الاتصال:

# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5

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

تحقّق ثم أغلق النافذة

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

وحين ينتهي العمل:

1. أزل المفتاح العام من authorized_keys، أو عطّل الحساب، أو دع الشهادة تنتهي في موعدها.
2. غيّر كل ما انتقل مع بيانات الدخول، بما في ذلك كلمة المرور المؤقتة التي كان يجب تغييرها عند أول تسجيل دخول ولم تُغيَّر.
3. راجع auth.log أو مصدر التدقيق لديك في SSH بحثًا عن اتصالات خارج الوقت المتفق عليه أو من عناوين غير متوقعة.
4. دوّن من حصل على ماذا، ومن متى إلى متى. السجل يبقى، أما بيانات الدخول فلا.

انتهاء صلاحية الرابط يحدد المدة التي كان يمكن فيها استلام المحتوى السري، وانتهاء صلاحية بيانات الدخول يحدد المدة التي يمكن فيها استخدامها. تحتاج إلى الاثنين، والثاني هو الذي ينساه الناس.

قراءات ذات صلة

• مشاركة الروابط بأمان للمطورين
• طريقة مشاركة مفاتيح API بأمان
• الروابط المنتهية الصلاحية: المحتوى السري يُحذف ولا يُعاد توجيهه فقط
• ماسحات الروابط والأسرار لمرة واحدة