الفرق بين Connection refused و Connection timed out في SSH

ماذا يعني "Connection refused" و "Connection timed out" في SSH

فشل الاتصال بـ SSH بسبب "Connection refused" و "Connection timed out" هما حالتان متناقضتان، لذا فإن حل إحداهما لا يصلح للأخرى أبداً. تعني "Refused" أن حزمتك وصلت إلى الخادم وأن نواة الخادم ردت بأن "لا يوجد شيء يستمع هنا". بينما تعني "Timed out" أن حزمتك لم تصل إلى أي جهة تجيب، فانتظر العميل ثم استسلم. "Refused" هي مشكلة في الخدمة على الخادم، بينما "Timed out" هي مشكلة في المسار أمام الخادم.

اقرأ السطر الدقيق الذي طبعه عميلك، لأن الصياغة هي التشخيص الكامل.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

التوقيت هو الدليل الثاني. تظهر "Refused" فوراً، في غضون وقت رحلة ذهاب وإياب واحدة تقريباً. أما "Timed out" فتنتظر لعدة ثوانٍ قبل أن تظهر، لأن العميل يستمر في إعادة الإرسال قبل أن يتوقف. يطبع نظام macOS رسالة Operation timed out لنفس الحالة. إذا كان البروتوكول نفسه جديداً عليك، فإن كيف يعمل SSH وماذا يفعل sshd هو الخلفية التي يفترضها هذا الدليل.

لماذا يُعدّ "Connection refused" خبراً جيداً

رسالة Refused هي استجابة إعادة ضبط (reset) لبروتوكول TCP. يرسل عميلك حزمة SYN إلى المنفذ 22. تعبر هذه الحزمة الإنترنت وتصل إلى مكدس الشبكة في الخادم، حيث يجد النواة (kernel) أنّه لا يوجد مقبس (socket) يستمع على هذا المنفذ، فيردّ بحزمة RST (إعادة ضبط). يحوّل عميل SSH الخاص بك هذه الحزمة إلى العبارة Connection refused.

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

• sshd لا يعمل، لأنه فشل في البدء أو لم يتم تفعيله مطلقاً.
• sshd يستمع على منفذ آخر، وعادة ما يحدث هذا بعد تغييرات لتعزيز الأمان.
• sshd مرتبط بعنوان واحد فقط، مثل ListenAddress 127.0.0.1، لذا لا يمكن الوصول إليه إلا من الخادم نفسه.
• جدار الحماية مضبوط على الرفض (reject) بدلاً من الإسقاط (drop)، لذا يرسل جدار الحماية حزمة RST نيابة عن المضيف. كلاً من إجراء reject في ufw وقاعدة nftables التي تنتهي بـ reject with tcp reset يقومان بذلك.

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

كيفية إصلاح خطأ Connection refused

لا يمكنك إصلاح هذا الخطأ عبر SSH، لأن خدمة SSH نفسها هي التي تعطلت. افتح وحدة التحكم (web console) أو وحدة التحكم التسلسلية (serial console) الخاصة بمزود الخدمة، وسجّل الدخول هناك، ثم نفّذ الأوامر التالية.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

يستخدم systemctl status ssh اسم الوحدة (unit) على توزيعتي Ubuntu وDebian. أما على RHEL وتوزيعاتها المشتقة مثل AlmaLinux، فإن الوحدة هي sshd. يسرد الأمر ss -tlnp كل مقبس TCP في حالة الاستماع (listening) مع العملية التي تملكه، وهو المرجع الأساسي: إذا لم يظهر أي سطر يذكر sshd، فهذا يعني أنه لا يوجد شيء يستمع للاتصالات، بغض النظر عما يذكره ملف الإعداد. يطبع sshd -T الإعدادات الفعلية بعد دمج كل ملفات Include، وهنا يظهر المنفذ المنسي في /etc/ssh/sshd_config.d/ بوضوح.

اقرأ عمود العنوان بعناية. يعني 0.0.0.0:22 كل عناوين IPv4 على الخادم. ويعني [::]:22 كل عناوين IPv6. أما 127.0.0.1:22 فيعني الاستماع على واجهة الاسترجاع (loopback) فقط، لذا سيتم رفض أي اتصال بعيد، بينما يعمل أمر ssh localhost محلياً بشكل مثالي.

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

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

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

فخ تفعيل المقبس (socket activation) في Ubuntu

تُشحن نسخة Ubuntu 24.04 بوحدة مقبس systemd لخدمة OpenSSH. عندما تكون هذه الوحدة مفعّلة، يحتفظ systemd بمنفذ الاستماع ويبدأ sshd لكل اتصال على حدة، لذا فإن أي تعديل في Port 2222 داخل sshd_config لن يغير شيئاً وسيستمر الخادم في الاستجابة على المنفذ القديم. تحقق من وضع التشغيل لديك قبل إجراء أي تعديل.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

إذا كان المقبس مفعّلاً، اضبط المنفذ في وحدة المقبس بدلاً من sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

سطر ListenStream= الفارغ مطلوب، لأن إعدادات القوائم في systemd تُضاف إلى ما تم تكوينه مسبقاً. إذا حذفت هذا السطر، سيستمع الخادم على كلا المنفذين. طبّق التغيير باستخدام sudo systemctl daemon-reload و sudo systemctl restart ssh.socket، ثم تأكد باستخدام sudo ss -tlnp من أن المنفذ الجديد هو الذي يتم حجزه. يُعد تغيير المنفذ خطوة معتادة عند تحصين SSH على خادم VPS، وهي الخطوة التي تتسبب في حجب المستخدمين عن خوادمهم في أغلب الأحيان.

لماذا يعني "Connection timed out" أن لا شيء أجاب

المهلة الزمنية (Timeout) تعني الصمت. أرسل عميلك حزمة SYN، وأعاد إرسالها عدة مرات على مدار دقيقة أو دقيقتين، ولم يتلقَّ أي حزمة في المقابل. لا شيء مؤكد بخصوص الخادم هنا، لأنك لم تسمع شيئاً منه على الإطلاق.

الصمت هو بالضبط ما تنتجه قاعدة DROP، والإسقاط (dropping) إجراء متعمد. الرفض (rejection) يخبر أي شخص يقوم بالمسح أن المضيف موجود، لذا تقوم ufw وجدار حماية الشبكة الخاص بكل مزود سحابي بإسقاط الحزم غير المرغوب فيها وعدم إرسال أي رد. مهلتك الزمنية عادة ما تكون جدار حماية يقوم بعمله على منفذ كنت ترغب في فتحه.

• العنوان خاطئ: سجل DNS لا يزال يشير إلى خادم أعدت بناءه، أو خطأ مطبعي يؤدي إلى عنوان لا يستخدمه أحد.
• المضيف لا يعمل: متوقف عن التشغيل، أو في منتصف عملية إعادة التشغيل. تعليق الحساب من قبل المزود بسبب الفواتير يبدو متطابقاً من الخارج.
• جدار حماية المضيف يسقط المنفذ 22، غالباً لأن ufw enable تم تشغيله قبل وجود أي قاعدة سماح.
• جدار حماية المزود أمام المثيل (instance) يسقط الحزمة، ولا يرى نظام التشغيل الحزمة على الإطلاق.
• شبكتك الخاصة تحظر المنفذ 22 الصادر، وهو أمر شائع في اتصالات المكاتب والفنادق.

أجرِ الاختبار من الطرف الآخر للاتصال

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

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

يعرض getent hosts العنوان الذي سيستخدمه جهازك فعلياً، مما يكشف عن سجلات DNS القديمة في ثوانٍ. يطبع ssh -G الإعدادات التي يطبقها عميلك بعد قراءة ~/.ssh/config، وبذلك يكشف عن أي كتلة Host قديمة تقوم بإعادة كتابة اسم المضيف أو المنفذ أو المستخدم بصمت. يوضح ssh -vvv إلى أي مدى وصلت المحاولة: السطر الأخير الذي يشير إلى الاتصال بالعنوان متبوعاً بتوقف طويل يعني حدوث مهلة (timeout)، بينما السطر الذي يبلغ عن إصدار OpenSSH البعيد يعني أن اتصال TCP قد نجح بالفعل وأن مشكلتك الحقيقية تكمن في المصادقة. على نظام Windows، استبدل nc بالأمر Test-NetConnection 203.0.113.10 -Port 22 في PowerShell.

اختبر المنفذ، لا المضيف. فشل ping لا يثبت شيئاً، لأن العديد من مزودي الخدمة يقومون بتصفية ICMP (بروتوكول رسائل التحكم في الإنترنت) عند الحافة. كما أن نجاح الـ ping لا يثبت شيئاً أيضاً، لأنه لا يقدم أي معلومة حول المنفذ 22.

بعد ذلك، غيّر المتغير الوحيد الذي لا يمكن لأي أمر تغييره نيابة عنك: شبكتك. أعد المحاولة باستخدام نقطة اتصال هاتفية (hotspot). إذا نجح الاتصال عبر نقطة الاتصال وفشل من مكتبك، فالحظر يقع في جانبك من الإنترنت، أو أن عنوان مكتبك قد تم حظره على الخادم.

جدار حماية المزوّد الذي لا يمكنك رؤيته من الخادم

توفّر معظم لوحات تحكّم الـVPS جدار حماية شبكي، يُسمى أحياناً مجموعة أمان (security group) أو جدار حماية سحابي، يعمل قبل وصول الاتصال إلى مثيلك (instance) ويحتفظ بقائمة قواعد خاصة به. ufw status الموجود على الخادم لا يمكنه رؤية هذه القواعد، ولهذا السبب تعد جملة "لكنني سمحت بالفعل بالمنفذ 22" شائعة جداً. افتح لوحة التحكّم واقرأ تلك القائمة قبل أن تعيد كتابة أي قاعدة واحدة داخل الخادم.

هناك أمر واحد يحسم المسألة، وهو يتطلب الوصول إلى وحدة التحكّم (console). ابدأ تشغيله على الخادم، ثم حاول الاتصال من حاسوبك المحمول أثناء عمله.

sudo tcpdump -ni any tcp port 22

إذا لم يظهر أي شيء أثناء محاولة العميل الاتصال، فهذا يعني أن الحزم (packets) يتم إسقاطها قبل وصولها إلى نظام التشغيل، وبالتالي فإن الخلل يكمن في جدار حماية المزوّد أو في مسار الوصول إلى المضيف. إذا وصلت حزم SYN ولم يخرج أي رد، فإن الإسقاط محلي ويخص ufw أو nftables. هذا الاختبار الفردي يقسم احتمالات انقضاء المهلة (timeout) إلى نصفين، ولهذا السبب يستحق الأمر عناء الوصول إلى وحدة التحكّم.

ترتيب قواعد ufw، وبروتوكول IPv6، وحظر نفسك عن طريق الخطأ

يؤدي خطأ ترتيب قواعد ufw إلى حظر المستخدمين أكثر من أي سبب آخر هنا. يطبّق sudo ufw enable سياسة افتراضية برفض جميع الاتصالات الواردة فوراً، لذا إذا لم تكن قد أضفت قاعدة لـ SSH، فستستمر جلستك الحالية بفضل حالة الاتصال القائمة، بينما ستنتهي مهلة كل اتصال جديد. اسمح بالاتصال أولاً، ثم فعّل الجدار الناري.

sudo ufw allow OpenSSH
sudo ufw status verbose

يغطي ملف تعريف التطبيق OpenSSH المنفذ 22 فقط. إذا كنت تخطط لنقل SSH إلى المنفذ 2222، فالقاعدة التي تحتاجها هي sudo ufw allow 2222/tcp، ويجب إضافتها قبل تغيير المنفذ وليس بعده. تغطي أساسيات جدار الحماية ufw لخادم VPS مجموعة القواعد الأوسع، ويعد الترتيب الآمن جزءاً من ما يجب فعله في الدقائق العشر الأولى على خادم VPS جديد.

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

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

إذا كان -4 يتصل بينما -6 لا يتصل، فالحل يكمن في قواعد IPv6 على الخادم، ويشرح مقال فتح نفس المنفذ لـ IPv6 في ufw كيفية القيام بذلك.

قد تكون حظرت نفسك أيضاً. يراقب fail2ban سجل المصادقة ويضيف قاعدة جدار حماية ضد العناوين التي تفشل في تسجيل الدخول بشكل متكرر، لذا فإن مفتاحاً خاطئاً أو سكربت يعمل في الخلفية قد يؤدي إلى حظر عنوان مكتبك بالكامل. يبدو الحظر الذي يسقط الحزم (drop) كأنه انتهاء مهلة. أما الحظر الذي يرفض الاتصال (reject) فيعيد رسالة No route to host. من وحدة التحكم (console):

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

تعد إضافة عنوانك الخاص إلى ignoreip جزءاً من إعداد fail2ban بشكل صحيح على Ubuntu 24.04.

أخطاء لا تندرج تحت الرفض أو انتهاء المهلة

No route to host تعني وصول رسالة ICMP تفيد بأن الوجهة غير قابلة للوصول. إما أن جهازك لا يملك مساراً نحو تلك الشبكة، أو أن هناك عنصراً على المسار رد برفض إداري، وهو ما ترسله قاعدة REJECT في iptables.

Network is unreachable تعني أن جهازك هو من أصدر الخطأ. لا يملك الجهاز مساراً لعائلة العناوين هذه على الإطلاق، وهي النتيجة المعتادة عندما يتم حل اسم المضيف إلى عنوان IPv6 فقط بينما يكون الاتصال مقتصراً على IPv4.

kex_exchange_identification: Connection closed by remote host تعني أن اتصال TCP تم بنجاح ثم قام الخادم بقطع الاتصال قبل اكتمال تبادل المفاتيح. المنفذ مفتوح وخدمة sshd تعمل، لذا تحقق من حمل الخادم، أو من MaxStartups، أو من حظر (ban) تم تطبيقه أثناء محاولتك الاتصال.

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

كيفية استعادة الوصول وتجنب الإغلاق مجدداً

يوفر كل مزود خادم افتراضي (VPS) جاد وحدة تحكم (console) لا تعتمد على شبكة النظام الضيف: إما وحدة تحكم تسلسلية (serial console) أو شاشة VNC عبر المتصفح. تُعد وحدة التحكم هذه مسار الاسترداد لكلا فرعي هذا الدليل، لأنها تظل تعمل حتى عند إيقاف sshd أو عند قيام قاعدة جدار ناري بإسقاط جميع الاتصالات. ابحث عنها في لوحة التحكم، وسجّل الدخول بصفتك root أو كمستخدم عادي، ثم نفّذ الفحوصات المذكورة أعلاه. إذا لم تقم بتعيين كلمة مرور لـ root، فيمكن لمعظم اللوحات إعادة تعيينها لك.

في حال عدم وجود وحدة تحكم، يكون البديل هو وضع الإنقاذ (rescue mode) الخاص بالمزود. يقوم هذا الوضع بإقلاع نظام استرداد مصغر وتثبيت (mount) القرص الخاص بك، مما يتيح لك تعديل /etc/ssh/sshd_config أو حذف قاعدة جدار ناري دون اتصال ثم إعادة التشغيل.

هناك عادتان تمنعان حدوث إغلاق مستقبلي. أبقِ جلسة SSH ثانية مفتوحة دائماً عند تعديل sshd أو جدار الناري، لأن تلك الجلسة تظل قائمة بفضل الحالة المثبتة (established state) بينما تختبر جلسة جديدة. وامنح نفسك خيار تراجع تلقائي قبل إجراء تغيير محفوف بالمخاطر في جدار الناري.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

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

ترتيب العمل

1. اقرأ نص الخطأ، ولاحظ المدة التي استغرقها للظهور.
2. إذا كان الخطأ Refused: انتقل إلى وحدة التحكم (console) وتحقق باستخدام sudo ss -tlnp من وجود مقبس (socket) في حالة استماع، ومن المنفذ، والعنوان المرتبط به.
3. إذا كان الخطأ Timed out: تأكد من العنوان من جهازك الخاص، ثم تحقق من جدار حماية المزوّد في لوحة التحكم، ثم جدار حماية المضيف داخل الخادم.
4. إذا لم يظهر أي من هذين النصين: فهذا يعني أن لديك اتصال TCP قائماً بالفعل، لذا تعامل مع المشكلة كمسألة مصادقة أو حمل على الخادم، وليس كمشكلة شبكة.

FAQ

لماذا تظهر رسالة "Connection refused" عند محاولة الاتصال عبر SSH رغم أن sshd يعمل؟

لأن الرفض يأتي من المقبس (socket) وليس من الخدمة نفسها، وقد يرفض sshd الاتصال بك حتى وهو يعمل. افتح وحدة تحكم المزود (provider console) ونفّذ الأمر sudo ss -tlnp. المقبس الذي يعمل على 127.0.0.1:22 يرفض جميع العملاء عن بُعد لأنه مرتبط بـ loopback فقط. المقبس الموجود على منفذ آخر سيرفض أي شخص لا يزال يستخدم المنفذ 22. إذا كنت تستخدم تفعيل المقبس عبر systemd، فإن المنفذ يأتي من ssh.socket وليس من sshd_config، لذا تحقق من systemctl is-enabled ssh.socket أيضاً. كما أن قاعدة ufw reject تعيد رفضاً نيابة عن المضيف، لذا اقرأ sudo ufw status verbose قبل استخلاص أي نتائج.

لماذا تنتهي مهلة اتصال SSH رغم أن ufw يسمح بالمنفذ 22؟

لأن انتهاء المهلة يعني عدم وصول أي رد، وufw ليس جدار الحماية الوحيد في المسار. تشغّل معظم لوحات تحكم الـ VPS جدار حماية شبكي أمام الخادم، ولا يرى نظام التشغيل ما يسقطه جدار الحماية هذا. من وحدة التحكم، نفّذ sudo tcpdump -ni any tcp port 22 وحاول الاتصال من حاسوبك المحمول أثناء تشغيل الأمر. عدم وصول أي حزم يعني أن الإسقاط يحدث في الأعلى (upstream) ضمن لوحة التحكم. وصول الحزم دون خروج رد يعني أن الإسقاط محلي، ضمن ufw أو nftables.

هل يعني فشل اختبار ping أن الـ VPS الخاص بي متوقف؟

لا. يقوم العديد من المزودين بتصفية حزم ICMP عند حافة الشبكة، لذا قد يتجاهل الخادم الذي يعمل بشكل طبيعي كل طلبات ping التي ترسلها. اختبار ping الناجح لا يعني الكثير في الاتجاه المعاكس، فهو لا يخبرك بشيء عما إذا كان المنفذ 22 مفتوحاً أم لا. اختبر المنفذ نفسه باستخدام nc -vz -w 5 203.0.113.10 22 من جهازك الخاص، أو باستخدام Test-NetConnection 203.0.113.10 -Port 22 في PowerShell على نظام Windows.

لقد غيّرت منفذ SSH والآن لا يمكنني الاتصال بأي شيء. ما الخطأ الذي حدث؟

هناك سببان لهذا الأمر. إذا لم يتم إضافة قاعدة للمنفذ الجديد في جدار الحماية، ستنتهي مهلة المحاولات على المنفذ الجديد بينما يتم رفض الاتصال على المنفذ 22، لذا يجب تنفيذ sudo ufw allow 2222/tcp قبل تغيير المنفذ وليس بعده. إذا كان الخادم يستخدم تفعيل المقبس عبر systemd لخدمة SSH، فسيتم تجاهل Port 2222 في sshd_config وسيستمر systemd في حجز المنفذ القديم، وهو ما يمكنك تأكيده عبر systemctl is-enabled ssh.socket. استعد الوصول عبر وحدة تحكم المزود، وأصلح السبب المناسب، ثم اتصل باستخدام ssh -p 2222 user@203.0.113.10 بمجرد أن يظهر sudo ss -tlnp المقبس الجديد.