تغيير منفذ SSH من أكثر الخطوات التي يُغلق بها أصحاب السيرفرات الباب على أنفسهم: غيّر الرقم، وأعاد التشغيل، ثم لم يعد يستطيع الدخول. هذا الدليل يغيّره بطريقة لا تقطعك أبدًا، إذ يعمل المنفذ الجديد بجانب القديم حتى تتأكد منه. ثم يشرح فخًّا يقع فيه كثيرون: حاويات Docker تفتح منافذها للعالم حتى لو لم تسمح بها في جدار ufw. جرّبنا كل خطوة على سيرفر Ubuntu 24.04 حقيقي من مرام.
⚡ الإجابة المختصرة
في Ubuntu 24.04 يحدَّد منفذ SSH في ssh.socket لا في sshd_config. أضف المنفذ الجديد بجانب القديم في ملف override، ثم أعد تشغيل ssh.socket، واسمح به في ufw، ثم في جدار لوحة مرام. اختبر الدخول من نافذة جديدة، وبعدها فقط احذف القديم وحدّث fail2ban. وفي Docker انشر المنافذ على 127.0.0.1 لأن المنافذ المنشورة تتجاوز ufw.
⚠️ ثلاث قواعد لا تُكسر
- لا تغلق جلسة SSH الحالية حتى تنجح بالدخول من المنفذ الجديد في نافذة ثانية.
- أضف المنفذ الجديد أولًا، ولا تحذف القديم إلا بعد نجاح الاختبار.
- إن انقطعت رغم كل شيء، فادخل من كونسول المتصفح (noVNC) في اللوحة، فهو لا يحتاج SSH ولا شبكة، ومنه تصلح الإعداد.
أين يُحدَّد منفذ SSH في Ubuntu 24.04؟
في الإصدارات القديمة كان يكفي تعديل سطر Port في /etc/ssh/sshd_config. أما منذ Ubuntu 22.10 فخدمة SSH تعمل بطريقة «socket activation»: النظام نفسه يستمع على المنفذ ويشغّل SSH عند الحاجة، فيصبح المنفذ المعتمد هو المكتوب في ssh.socket. لذلك يغيّر كثيرون sshd_config ولا يتغيّر شيء. في سيرفرات مرام يأتي SSH على المنفذ 2026 بدل 22، ومضبوطًا في ملف override خاص.
الخطوة 1: أضف المنفذ الجديد بجانب القديم
اخترنا 2222 للتجربة، واختر أنت رقمًا بين 1024 و65535 لا يستعمله برنامج آخر:
sudo nano /etc/systemd/system/ssh.socket.d/override.conf
# أضف سطرين للمنفذ الجديد تحت الموجود:
# ListenStream=0.0.0.0:2222
# ListenStream=[::]:2222
sudo systemctl daemon-reload && sudo systemctl restart ssh.socket
sudo ss -tlnp | grep -E ':2026|:2222' # يجب أن يظهر المنفذان
sudo ufw allow 2222/tcp comment 'SSH new port'السطر الفارغ ListenStream= في أول الملف مقصود، فهو يلغي المنفذ الافتراضي 22 قبل إضافة منافذك. لا تحذفه.
الخطوة 2: افتح المنفذ في جدار اللوحة
سيرفرك خلف جدارين: ufw داخله، وجدار اللوحة أمامه، وهذا الأخير يمنع أي منفذ ليست له قاعدة. من صفحة الخدمة افتح Firewall ثم Create Firewall Rule:
الخطوة 3: اختبر من نافذة جديدة
اترك جلستك الحالية مفتوحة، وافتح طرفية جديدة على جهازك. هذه نتيجتنا قبل قاعدة اللوحة وبعدها، ثم الدخول الفعلي على المنفذ الجديد:
الخطوة 4: أزل المنفذ القديم وحدّث fail2ban
بعد نجاح الدخول بالمنفذ الجديد فقط:
- احذف سطري 2026 من ملف override، ثم نفّذ
sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. - احذف السماح القديم:
sudo ufw delete allow 2026/tcp، واحذف قاعدته من جدار اللوحة. - حدّث fail2ban: في قالب مرام تحمي fail2ban منفذ SSH، والمنفذ مكتوب فيها صراحة (
port = 2026في/etc/fail2ban/jail.local). إن لم تغيّره فستحظر fail2ban المخمّنين على المنفذ القديم وحده، ويبقى الجديد بلا حماية. غيّره إلى رقمك ثم نفّذsudo systemctl restart fail2ban. - غيّر سطر
Portفي/etc/ssh/sshd_configإلى الرقم الجديد أيضًا حتى يبقى الإعداد متّسقًا، وحدّث المنفذ في برنامجك (Termius أو ملف~/.ssh/config).
فخّ Docker: منافذ مفتوحة رغم ufw
هذا يفاجئ حتى المحترفين. عندما تشغّل حاوية بـ-p 8080:80 يضيف Docker قواعد تحويل خاصة به في جدار النظام، وهذه القواعد تُطبَّق قبل ufw. النتيجة: المنفذ مفتوح للإنترنت حتى لو لم تسمح به في ufw، ويبقى ufw status يوحي لك بأنه مغلق. جرّبناها:
في تجربتنا لم يمنع الوصول إلا جدار اللوحة، لأنه خارج السيرفر ولا يستطيع Docker تغييره. فلما أضفنا له قاعدة للمنفذ 8080 وصلنا إلى الحاوية من الخارج (200) مع أن ufw لا يسمح به. لذلك:
- انشر على
127.0.0.1كل حاوية لا يجب أن يصلها العالم مباشرة:-p 127.0.0.1:8080:80، أو في docker-compose:"127.0.0.1:8080:80". ثم اجعل الموقع يصل إليها عبر Nginx مع شهادة SSL. - قواعد البيانات تحديدًا (MySQL أو Postgres أو Redis) لا تنشر منافذها أبدًا، فالحاويات تتصل ببعضها عبر شبكة Docker الداخلية دون أي
-p. - جدار اللوحة هو خط الدفاع الثابت: لا تفتح فيه إلا المنافذ التي تريدها عامة فعلًا.
ملخص الخطوات
أسئلة شائعة
غيّرت المنفذ وانقطع الاتصال، ماذا أفعل؟
ادخل من noVNC Console في صفحة الخدمة باسم المستخدم وكلمة المرور، ثم أعد ملف override كما كان أو صحّح الرقم، ونفّذ sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. وتأكد من وجود قاعدة مفعّلة للمنفذ في جدار اللوحة.
هل تغيير المنفذ يكفي للحماية؟
لا. هو يقلّل محاولات التخمين الآلية، أما الحماية الحقيقية فهي مفاتيح SSH بدل كلمة المرور، ثم fail2ban الذي يحظر المخمّنين (كيف يعمل وكيف تفكّ الحظر).
عدّلت sshd_config ولم يتغيّر المنفذ
هذا متوقّع في Ubuntu 22.10 وما بعده، لأن المنفذ يُحدَّد في ssh.socket. استعمل ملف override كما في الخطوة 1.
هل أحتاج ufw مع وجود جدار اللوحة؟
وجودهما معًا أفضل: جدار اللوحة يحمي من الخارج ولا يتأثر بأخطاء السيرفر، أما ufw فيحمي داخل السيرفر ويسجّل المحاولات. لكن تذكّر أن Docker يتجاوز ufw، فلا تعتمد عليه وحده لحماية الحاويات.
