من يرى حقًا كلمة مرور SSH الخاصة بك على شبكة VPN غير موثوقة؟

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

سمِّ المتلقي قبل أن تكتب أي شيء

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

أبقِ الاتجاهين منفصلين في ذهنك. مفتاح المضيف يجيب عن سؤال أي خادم بلغته. ومصادقة كلمة المرور أو المفتاح تجيب عن سؤال أي مستخدم يقبله الخادم. وتحسين الثاني لا يصلح الأول أبدًا.

افحص هوية المضيف والسجل والتفاوض

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

اقرأ الوسائل التي يقبلها الخادم فعلاً

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

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

تعامل مع تحذير مفتاح المضيف كخطوة حادثة

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

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

ما لا يغطيه هذا الدليل

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

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