تفعيل SSH على Ubuntu: تثبيت OpenSSH وتحصينه

تفعيل SSH على Ubuntu: التثبيت والتشغيل وفتح الجدار الناري

يأتي SSH على Ubuntu من حزمة openssh-server. يعرض Ubuntu Server تثبيتها أثناء الإعداد، وتكاد كل صور السحابة وخوادم VPS تأتي بها جاهزة للاستماع؛ أما Ubuntu Desktop فلا يثبّتها إطلاقاً.

1. تثبيت openssh-server

sudo apt update
sudo apt install -y openssh-server

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

2. تفعيل الخدمة وتشغيلها

sudo systemctl enable --now ssh
systemctl status ssh

على Ubuntu تُسمّى الوحدة ssh، وsshd اسم مرادف لها. يشغّل enable --now العفريت فوراً وعند كل إقلاع. ومنذ Ubuntu 22.10 صار sshd يُفعَّل عبر المقبس: يمتلك ssh.socket المنفذ 22 ويبدأ ssh.service عند أول اتصال وارد، لذا فظهور الحالة inactive (dead) مع TriggeredBy: ssh.socket بعد التثبيت مباشرة أمر طبيعي؛ فالمنفذ مفتوح. وللصورة الأشمل، راجع سرد الخدمات باستخدام systemctl.

3. السماح لـ SSH عبر UFW

يأتي UFW معطّلاً في Ubuntu. وإذا فعّلته، فاسمح لـ SSH أولاً؛ فتفعيل الجدار الناري قبل إنشاء القاعدة هو الطريقة الكلاسيكية لحبس نفسك خارج جهاز بعيد.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

يستخدم ufw allow OpenSSH ملف تعريف التطبيق ويفتح 22/tcp. وإذا نقلت sshd لاحقاً، فاسمح بالمنفذ الجديد عبر sudo ufw allow 2222/tcp ثم احذف القاعدة القديمة. اعثر على عنوان الخادم بـhostname -I.

الاتصال من Windows أو macOS أو Linux

كل أنظمة سطح المكتب الحديثة تتضمن عميل OpenSSH مدمجاً، والصياغة واحدة في كل مكان:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 و11: افتح PowerShell أو Windows Terminal واكتب الأمر؛ فعميل OpenSSH مرفق مع Windows منذ 2018 (الإصدار 1809). وإذا لم يُتعرَّف على ssh، فأضفه من Settings > Apps > Optional features.
• macOS: من Terminal، بالأمر نفسه.
• Linux: أي طرفية؛ فحزمة openssh-client مثبّتة افتراضياً على Ubuntu.

عند الاتصال الأول، اقبل بصمة مفتاح مضيف الخادم بكتابة yes؛ تُخزَّن في ~/.ssh/known_hosts وستُنبَّه إن تغيّرت يوماً. ثم اكتب كلمة مرور الحساب، والقسم التالي يستبدلها بمفتاح.

الانتقال إلى المصادقة بالمفاتيح

الدخول بكلمات المرور هو ما تحاول شبكات البوت كسره على مدار الساعة؛ أما المفاتيح فتجعل تلك المحاولات بلا جدوى. أنشئ زوج مفاتيح Ed25519 على جهازك أنت، لا على الخادم:

ssh-keygen -t ed25519 -C "laptop-2026"

اقبل المسار الافتراضي (~/.ssh/id_ed25519) واضبط عبارة مرور؛ فهي تشفّر المفتاح الخاص على القرص، ووكيل SSH يجعلك تكتبها مرة واحدة لكل جلسة. ولا يغادر جهازك سوى ملف .pub.

نسخ المفتاح العام إلى الخادم

على macOS وLinux، يقوم ssh-copy-id بذلك في خطوة واحدة، مستخدماً كلمة مرورك للمرة الأخيرة:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

لا تتضمن نسخة OpenSSH على Windows الأداة ssh-copy-id؛ مرّر المفتاح من PowerShell بدلاً من ذلك:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

كلتا الطريقتين تضيفان المفتاح إلى ~/.ssh/authorized_keys الخاص بذلك المستخدم. والأذونات مهمة: يتجاهل sshd الملف بصمت إذا لم يكن ~/.ssh بالوضع 700 أو كان authorized_keys قابلاً للكتابة من غير مالكه. ومن طرفية جديدة، ينبغي أن يدخلك ssh username@SERVER_IP الآن دون كلمة مرور الحساب. لا تنتقل إلى القسم التالي قبل أن يعمل ذلك.

تحصين sshd_config: لا كلمات مرور، لا جذر، مستخدمون مسموح بهم

أبقِ جلستك الحالية مفتوحة أثناء التحرير؛ فإن أعطب الإعداد الجديد شيئاً، فهي طريق عودتك. يبدأ /etc/ssh/sshd_config بـInclude /etc/ssh/sshd_config.d/*.conf، ويحتفظ sshd بأول قيمة يقرأها لكل كلمة مفتاحية، لذا يتفوق ملف الإضافة على أي شيء أسفل الملف الرئيسي. كما تتضمن صور السحابة غالباً /etc/ssh/sshd_config.d/50-cloud-init.conf مع PasswordAuthentication yes، وهذا سبب أن تعديل الملف الرئيسي يبدو كثيراً بلا أثر. الحل ملف إضافة يسبق غيره في الترتيب:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

الصق ما يلي مع استبدال username باسم دخولك:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

يفترض PermitRootLogin no أن لديك حساباً غير مميّز بصلاحيات sudo. وإذا كنت تعمل بحساب الجذر حتى الآن، فأنشئ مستخدم sudo على Linux وانسخ مفتاحك إليه قبل تطبيق الملف. ثم تحقّق من الصياغة، وأعد التحميل، وافحص القيم التي يستخدمها sshd فعلياً بعد دمج كل ملفات التضمين، وهذا ما يطبعه sshd -T:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

افتح طرفية ثانية وسجّل الدخول بمفتاحك قبل إغلاق الأولى. وإليك ما يفعله كل توجيه:

ولإبقاء الاتصال حياً جانب خاص بالعميل أيضاً: يمنع ServerAliveInterval 60 في ~/.ssh/config على جهازك موجّهات NAT من قطع الجلسات الخاملة.

تغيير منفذ SSH ليس أماناً

نقل sshd بعيداً عن المنفذ 22 نصيحة شائعة. وما تجنيه منها هو سطور سجلّ أقل. فالماسحات الجماعية تمشّط المنافذ الـ65,535 كلها وتجد sshd على 2222 خلال ساعات؛ ومن يستهدفك تحديداً سيجده في ثوانٍ عبر nmap. الأمان هو المفاتيح ومنع دخول الجذر وقائمة السماح وfail2ban؛ أما المنفذ فشكليّ. يبقى مفيداً على خادم مزدحم لأنه يُبقي سجل المصادقة قابلاً للقراءة، لكن لا تعدّه أبداً طبقة دفاع.

وإن غيّرته، فالتزم بهذا الترتيب: افتح المنفذ الجديد في UFW، غيّر المنفذ، أعد التشغيل، اختبر من طرفية ثانية، ثم احذف القاعدة القديمة. أزل التعليق عن #Port 22 في /etc/ssh/sshd_config، واضبط المنفذ الجديد، ثم:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

في الإصدارات التي تعتمد تفعيل المقبس، فإن وحدة المقبس لا sshd هي التي تحدّد المنفذ المرتبط؛ وتشحن Ubuntu مولّد systemd يقرأ Port من إعدادات sshd أثناء daemon-reload ويحدّث ssh.socket. تأكّد عبر sudo ss -tlnp | grep sshd، ويشرح دليل فحص المنافذ المفتوحة على Linux مخرجات الأمر. وإذا بقي sshd عنيداً على المنفذ 22، فعطّل تفعيل المقبس ودع الخدمة تربط المنفذ بنفسها: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. وبمجرد أن يعمل ssh -p 2222 من طرفية جديدة، نفّذ sudo ufw delete allow OpenSSH.

أضف fail2ban، وفكّر في المصادقة الثنائية

مع تعطيل كلمات المرور يستحيل نجاح الهجوم بالقوة الغاشمة، لكن كل محاولة تكلّف عملية جديدة وسطر سجل. يراقب fail2ban سجل المصادقة ويحظر العناوين التي تفشل مراراً:

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

ضع هذا في الملف:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

لا تحرّر jail.conf أبداً؛ فهو يُستبدل عند الترقيات، وjail.local يتجاوزه. وport = ssh يُحلّ عبر /etc/services، لذا اكتب port = 2222 إن نقلت العفريت. أما backend = systemd فيقرأ اليوميات مباشرة ويعمل سواء كتبت صورتك /var/log/auth.log أم لا. ويسرد fail2ban-client status sshd العناوين المحظورة؛ وsudo fail2ban-client set sshd unbanip 203.0.113.7 يرفع الحظر عن واحد. وافتراضياً تُقيَّم قواعد fail2ban قبل قواعد UFW، فيتعايش الاثنان.

المصادقة الثنائية

حين لا يكفي مفتاح مع عبارة مرور، يضيف libpam-google-authenticator رمزاً زمنياً فوق المفتاح: ثبّته، ونفّذ google-authenticator بحساب الدخول، وأضف auth required pam_google_authenticator.so إلى /etc/pam.d/sshd (مع تعليق سطر @include common-auth)، ثم اضبط KbdInteractiveAuthentication yes وAuthenticationMethods publickey,keyboard-interactive في sshd. مكسب حقيقي في مواجهة حاسوب مسروق، وشيء إضافي يمكن أن تفقده: احتفظ برموز الطوارئ خارج الخادم.

حل المشكلات: رفض الاتصال، انتهاء المهلة، رفض الإذن

Connection refused

ردّ الخادم لكن لا شيء يستمع على ذلك المنفذ: sshd متوقف، أو مرتبط بمنفذ آخر، أو كتبت المنفذ خطأً. من وحدة تحكم المزوّد، نفّذ systemctl status ssh وsudo ss -tlnp | grep ssh. وخطأ في الصياغة يمنع sshd من الإقلاع أصلاً؛ يطبع sudo sshd -t السطر المخالف، ويعرض journalctl -u ssh -n 50 آخر محاولة تشغيل.

Connection timed out

تُسقَط الحزم بدل رفضها، وهذا يعني جداراً نارياً في الغالب: UFW بلا قاعدة سماح (sudo ufw status verbose)، أو مجموعة أمان في لوحة المزوّد، أو شبكتك أنت تحجب المنفذ 22 الصادر، وتجربة نقطة اتصال الهاتف تستبعد ذلك. ويبيّن ssh -v username@SERVER_IP أين تتعثر المصافحة.

Permission denied (publickey)

الخادم متاح لكنه يرفضك. تحقّق بالترتيب: اسم المستخدم، وهل يحتوي authorized_keys لذلك المستخدم على المفتاح الذي تقدّمه (ssh -i ~/.ssh/id_ed25519 -v يفرض مفتاحاً بعينه)، وأذونات ~/.ssh، وهل اسم الدخول غائب عن AllowUsers. وعلى الخادم، يذكر journalctl -u ssh -n 30 السبب؛ ورسالة Authentication refused: bad ownership or modes هي مشكلة الأذونات الموصوفة سابقاً.

تحذير مفتاح المضيف

ظهور WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED بعد إعادة بناء الخادم أمر متوقع: نفّذ ssh-keygen -R SERVER_IP ثم أعد الاتصال. أما إن لم تُعِد تثبيت شيء، فاعرف السبب قبل أن تكتب كلمة مرور في أي مكان. وإن حُبست تماماً خارج الخادم، فوحدة تحكم المزوّد هي طريق العودة.

كل ما سبق يفترض جهازاً تملك فيه صلاحية الجذر ويمكنك أن تعطب sshd فيه ثم تصلحه من وحدة تحكم. وخادم Linux VPS من rdp.monster هو بالضبط هذا الجهاز: وصول جذر كامل، ومعالج وذاكرة مخصّصان، ونطاق ترددي غير محدود (ضمن الاستخدام العادل)، ودون KYC، ودفع بالعملات الرقمية أو النقدية، ابتداءً من ‎$8.99 شهرياً، ويكون الخادم متصلاً بعد نحو 10 ثوانٍ من تأكيد الدفع، وقت كافٍ لتجهيز المفاتيح قبل أن يعثر أول ماسح على المنفذ 22.

الأسئلة الشائعة

هل يأتي Ubuntu بخدمة SSH مفعّلة افتراضياً؟

Ubuntu Desktop لا، أما Ubuntu Server ومعظم صور السحابة فنعم.

يثبّت Ubuntu Desktop عميل SSH فقط، فلا شيء يستمع على المنفذ 22 حتى تنفّذ sudo apt install openssh-server. أما Ubuntu Server فيسألك أثناء التثبيت عمّا إذا كنت تريد تثبيت خادم OpenSSH، ويمكنه استيراد مفاتيحك من GitHub أو Launchpad في الوقت نفسه. وصور السحابة وVPS تأتي غالباً بـopenssh-server مثبّتاً ومفعّلاً ويقبل الاتصالات، لأنها الطريقة الوحيدة التي يسلّمك بها المزوّد الجهاز. تحقّق عبر systemctl status ssh.

كيف أتحقّق من أن SSH يعمل على Ubuntu؟

نفّذ systemctl status ssh ثم تأكّد من استماع المنفذ 22 باستخدام ss.

يخبرك systemctl status ssh بما إذا كانت الخدمة نشطة أو مفعّلة. ولأن Ubuntu 22.10 وما بعده تستخدم تفعيل المقبس، قد تظهر الخدمة بصورة مشروعة كـinactive (dead) مع TriggeredBy: ssh.socket حين لا يكون أحد متصلاً، لذا فالاختبار الأوثق هو sudo ss -tlnp | grep ssh: وجود سطر يعرض 0.0.0.0:22 أو [::]:22 يعني أن SSH يستمع. ومن جهاز آخر، يؤكّد ssh -v username@SERVER_IP ذلك من طرف إلى طرف.

هل من الآمن إبقاء SSH على المنفذ 22؟

نعم، شرط تعطيل كلمات المرور واستخدام المفاتيح؛ فرقم المنفذ لا يضيف حماية.

يجتذب المنفذ 22 محاولات دخول آلية متواصلة، لكن تلك المحاولات لا يمكن أن تنجح أمام خادم مضبوط على PasswordAuthentication no مع زوج مفاتيح، وfail2ban يزيل معظم الضجيج. ونقل sshd إلى 2222 أو 22222 يخفيه عن أكسل الماسحات فقط؛ فماسحات المنافذ مثل nmap وmasscan تجده خلال دقائق، والفهارس التي تمسح الإنترنت تدرجه على أي حال. عامل المنفذ غير الافتراضي كإجراء لنظافة السجلات لا كضابط أمني، ولا تتخلَّ عن المفاتيح لأنك غيّرت المنفذ.

ما الفرق بين ssh وsshd على Ubuntu؟

ssh هو برنامج العميل، وsshd هو عفريت الخادم، ووحدته على Ubuntu اسمها ssh مع sshd كاسم مرادف.

ssh هو العميل الذي تشغّله على حاسوبك لفتح اتصال؛ ويأتي من حزمة openssh-client. أما sshd فهو العفريت الذي يجيب على الخادم، من openssh-server، ويُضبط في /etc/ssh/sshd_config (بينما يقرأ العميل ssh_config). وتسمّي Ubuntu وDebian وحدة systemd باسم ssh.service وتعلن sshd.service اسماً مرادفاً، فيؤدي systemctl restart ssh وsystemctl restart sshd الشيء نفسه؛ أما على Fedora وRHEL وArch فالوحدة اسمها sshd ببساطة.