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

اجمع معلومات اتصال واحد

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

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

سجّل أول رسالة فشل والمرحلة السابقة لها. راجع المخرجات قبل مشاركتها؛ قد تكشف أسماء حسابات ومسارات وعناوين. لا ترسل المفتاح الخاص.

فرّق بين انتهاء المهلة ورفض الاتصال والمفتاح

مرّر الجدول أفقيًا لعرض جميع الأعمدة عند الحاجة.

إذا تم اتصال TCP ثم توقف التفاوض، فالمسار وصل إلى مرحلة مختلفة عن انتهاء المهلة قبل الاتصال. استخدم تفاصيل -vvv لتحديدها، ولا تطبق علاج جدار عام على كل خطأ.

عند انتهاء المهلة افحص الشبكة دون قطع الوصول

قارن العنوان العام الحالي بما تستخدمه. تأكد من مسار البوابة والجدار ومصدر /32 إذا كان اتصال الإدارة مقيدًا بعنوانك؛ قد يتغير عنوان المنزل أو VPN. راجع قوائم الأمان وNSG وكل طبقة فعلية.

استخدم وحدة التحكم للتحقق من شبكة الضيف. لا تمسح قواعد الجدار ولا تفتح كل المنافذ للتجربة. على Ubuntu في OCI حافظ على قواعد الصورة وiSCSI؛ تفعيل UFW فوقها ليس علاجًا عامًا.

عند رفض الاتصال افحص المنفذ والخدمة

داخل الخادم من جلسة متاحة أو وحدة تحكم، نفذ الفحوص التالية:

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

قارن عنوان الاستماع والمنفذ بالقيم التي تستخدمها. قد تعمل الصورة بتفعيل الخدمة عند اتصال socket؛ لذلك حالة ssh.service غير النشطة وحدها لا تثبت غياب الاستماع.

اختبار sshd -t يفحص صلاحية الإعداد، لكنه لا يختبر اتصال الإنترنت أو قواعد المزود. أصلح السبب الذي يظهر في السجل قبل إعادة تحميل خدمة، واحتفظ بمسار إدارة آخر.

عند رفض المفتاح افحص المستخدم والهوية المعروضة

اسم المستخدم يحدده المزود والصورة؛ في Ubuntu على OCI يكون ubuntu، بينما تستخدم صور أخرى أسماء مختلفة. لا تجرب root لمجرد أن لديك صلاحيات sudo.

على حاسوبك افحص بصمة المفتاح العام والمفاتيح المحملة:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

حدد المفتاح المقصود عند تجربة الاتصال:

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

خيار IdentitiesOnly يقيّد الهويات إلى المهيأة، لكنه لا يلغي كل IdentityFile في ملف إعداد العميل. راجع الهوية المعروضة في -vvv.

على الخادم طابق المفتاح العام مع authorized_keys للحساب الصحيح، وراجع ملكية المجلد وصلاحياته. احتفظ بالمفاتيح الموجودة للعاملين الآخرين؛ لا تستبدل الملف كاملًا. لا تعطل StrictModes ولا تفتح دخول كلمات المرور لتجاوز تشخيص غير مكتمل.

عند تغير هوية المضيف توقف وتحقق

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

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

قارن نوع الخوارزمية وبصمة SHA256 بما يعرضه العميل. بصمة بوابة اتصال وحدة التحكم ليست بالضرورة بصمة SSH داخل الضيف. لا تعتمد على ssh-keyscan من الشبكة وحده لإثبات الهوية.

بعد توثيق التغير، حدّث سجل known_hosts المتعلق بهذا المضيف فقط. لا تحذف الملف كله ولا تعطل StrictHostKeyChecking. إذا لم تتطابق الهوية فابقَ خارج الاتصال وافحص العنوان والجهاز.

اختبر جلسة جديدة قبل إغلاق الأصلية

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

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