> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# تأمين خادم VPS من أول دخول على Ubuntu 24.04
- URL: https://arabroot.io/articles/تأمين-خادم-vps-من-أول-دخول/
- Published: 2026-09-18T09:30:00.000Z
- Updated: 2026-10-04T20:05:38.000Z
- Description: استلمت خادمك للتو؟ قبل أن تثبت عليه أي تطبيق، اتبع هذه الخطوات لإغلاق أبرز الثغرات: الدخول بمفتاح SSH بدلاً من كلمة المرور، وجدار حماية، وتحديثات أمنية تلقائية.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, لينكس والسيرفرات, الأمن والدخول الموحد, الاستضافة الذاتية, VPS

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

وفي هذا الدليل نفترض أن السيرفر يعمل بنظام Ubuntu 24.04، وأنك ما زلت في الدقائق الأولى بعد استلامه، وإذا لم تختر سيرفرك بعد فابدأ بدليل [كيف تختار خادماً افتراضياً VPS](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%AE%D8%A7%D8%AF%D9%85%D8%A7-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7-vps/) ثم ارجع إلى هنا.

وسوف نناقش في هذا المقال ما يلي:

- إنشاء مفتاح SSH على جهازك، وتحديث النظام، وإنشاء مستخدم عادي بصلاحية sudo بدلاً من العمل بحساب root.
- تعطيل الدخول بكلمة المرور Password Authentication ومنع حساب root، ولماذا يتجاهل السيرفر إعدادك أحياناً إذا أخطأت في اسم الملف.
- مراجعة المنافذ المفتوحة، وتفعيل جدار الحماية Firewall، والتحديثات الأمنية التلقائية Automatic Security Updates.
- fail2ban وملف swap، ثم التأكد من نجاح كل خطوة، والنسخ الاحتياطي، والتحديث، وأشهر المشكلات وحلولها.

## ما تحتاجه قبل أن تبدأ Requirements

- سيرفر افتراضي VPS يعمل بنظام Ubuntu Server 24.04 LTS، وإمكانية الدخول إليه بحساب root أو بالمستخدم الذي ينشئه المزود.
- جهاز محلي فيه عميل Client [OpenSSH](https://www.openssh.com/?ref=arabroot.io)، وهو مدمج في Linux وmacOS و[Windows 10 وما بعده](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh%5Finstall%5Ffirstuse?ref=arabroot.io).
- عنوان IP العام للسيرفر، وسوف نستخدم في هذا الدليل العنوان التوضيحي `203.0.113.10`، فضع عنوانك مكانه في كل الأوامر.

## الدخول الأول وتأمين السيرفر

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

### إنشاء مفتاح SSH على جهازك

إذا لم يكن لديك مفتاح، [فأنشئه](https://manpages.ubuntu.com/manpages/noble/man1/ssh-keygen.1.html?ref=arabroot.io) على جهازك المحلي وليس على السيرفر، والسبب أن المفتاح الخاص Private Key يجب أن يبقى عندك أنت ولا يغادر جهازك. واختر النوع `ed25519` فمفتاحه قصير وقوي، واحمه بعبارة مرور Passphrase حتى لا يستفيد منه من يصل إلى جهازك:

```bash
ssh-keygen -t ed25519 -C "admin@example.com"
```

والأفضل أن تضيف المفتاح العام Public Key، أي الملف `~/.ssh/id_ed25519.pub`، في لوحة المزود عند إنشاء السيرفر، وبالتالي يدخل root بالمفتاح من البداية ولا تمر كلمة المرور عبر الشبكة أبداً.

### ابدأ بتحديث النظام System Update

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

```bash
ssh root@203.0.113.10
apt update && apt full-upgrade -y
hostnamectl set-hostname app01
timedatectl set-timezone UTC
```

ضبط المنطقة الزمنية Time Zone على UTC يسهل مقارنة السجلات Logs بين الأنظمة، فلا تحتاج أن تحسب فروق التوقيت كلما تتبعت مشكلة بين سيرفرين. وإذا تطلب التحديث إعادة التشغيل Reboot، أي إذا وجدت الملف `/var/run/reboot-required`، فأعد التشغيل الآن قبل أن تبني أي شيء على السيرفر.

وتأكد أن ساعة السيرفر متزامنة Time Synchronization، والسبب أن السجلات وfail2ban وشهادات TLS كلها تعتمد على الوقت الصحيح. ويتولى ذلك في Ubuntu 24.04 [الخدمة systemd-timesyncd](https://ubuntu.com/server/docs/how-to/networking/timedatectl-and-timesyncd/?ref=arabroot.io)، ولاحظ أن الأمر `timedatectl` يجب أن يعرض السطرين `System clock synchronized: yes` و`NTP service: active`.

### إنشاء مستخدم عادي بصلاحية sudo

الطريقة الأسهل هي أن تعمل يومياً بحساب root، وهي أسوأ الطرق على الإطلاق، فأي خطأ مطبعي سوف ينفذ بكامل الصلاحيات، والمهاجم يعرف مسبقاً نصف بيانات الدخول وهو اسم المستخدم «root»، فلا يبقى عليه إلا أن يخمن النصف الآخر. لذلك أنشئ مستخدماً باسم من اختيارك وامنحه صلاحية `sudo`:

```bash
adduser deploy
usermod -aG sudo deploy
id deploy
```

والمخرج سوف يكون كما يلي، ولاحظ وجود المجموعة `sudo` بين مجموعات المستخدم:

```bash
uid=1001(deploy) gid=1001(deploy) groups=1001(deploy),27(sudo),100(users)
```

الآن انسخ مفاتيح root المصرح بها Authorized Keys إلى المستخدم الجديد، واضبط الملكية Ownership والصلاحيات Permissions كما في الأمر التالي، والسبب أن [سيرفر SSH يرفض المفاتيح](https://manpages.ubuntu.com/manpages/noble/man5/sshd%5Fconfig.5.html?ref=arabroot.io) إذا كانت صلاحيات المجلد أوسع من اللازم:

```bash
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
```

وإذا كان الدخول بكلمة المرور لا يزال مفعلاً، فيمكنك نسخ المفتاح من جهازك المحلي [بالأمر ssh-copy-id](https://manpages.ubuntu.com/manpages/noble/man1/ssh-copy-id.1.html?ref=arabroot.io):

```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10
```

⚠️

تذكر: قبل أن تغير أي إعداد في SSH افتح نافذة طرفية Terminal **ثانية**، وتأكد أنك تستطيع الدخول بالأمر `ssh deploy@203.0.113.10` وأن الأمر `sudo -v` يعمل، وأبق الجلسة Session الأولى مفتوحة حتى تنتهي من جميع الخطوات، والسبب أنك إذا أغلقت الباب على نفسك فلن يبقى لك إلا طرفية الطوارئ Emergency Console في لوحة المزود.

### تعطيل الدخول بكلمة المرور ومنع حساب root

الطريقة التي يبدأ بها كثيرون هي تعديل الملف الرئيسي `/etc/ssh/sshd_config` مباشرة، والأنظف أن تبقيه كما هو، لذلك لا تعدله، وإنما ضع إعداداتك في ملف مستقل داخل المجلد `sshd_config.d`. وهنا تفصيل يغفل عنه كثيرون، حيث [يأخذ sshd **أول** قيمة يقرؤها](https://manpages.ubuntu.com/manpages/noble/man5/sshd%5Fconfig.5.html?ref=arabroot.io) لكل خيار ويقرأ الملفات بالترتيب الأبجدي، وكثير من الصور السحابية Cloud Images تأتي بملف `50-cloud-init.conf` فيه `PasswordAuthentication yes`، فلو سميت ملفك `99-...` كما يفعل البعض ظناً أن الأخير يفوز، لما سرى مفعوله وبقي السيرفر يقبل كلمة المرور دون أن تنتبه، ولهذا نسميه `00-hardening.conf`. وإذا اخترت اسم مستخدم غير deploy فضعه في السطر `AllowUsers`، وإلا رفض السيرفر دخولك أنت أيضاً:

```bash
sudo tee /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers deploy
EOF
```

في الإعداد أعلاه لاحظ التالي:

- السطران PermitRootLogin وPasswordAuthentication يمنعان حساب root ويعطلان الدخول بكلمة المرور، ويغلق KbdInteractiveAuthentication الطريق الآخر الذي قد تمر منه كلمة المرور.
- السطر AuthenticationMethods يجعل المفتاح هو الطريقة الوحيدة المقبولة للدخول.
- السطران MaxAuthTries وLoginGraceTime يقللان عدد المحاولات في الاتصال الواحد والوقت المسموح لإتمام الدخول.
- السطر `AllowUsers` يقصر الدخول على المستخدمين المذكورين فيه فقط.

[افحص الصياغة Syntax أولاً](https://ubuntu.com/server/docs/how-to/security/openssh-server/?ref=arabroot.io)، ثم اعرض الإعداد الفعلي الذي سوف يعمل به `sshd` بعد دمج كل الملفات:

```bash
sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|allowusers|maxauthtries) '
```

والمخرج سوف يكون كما يلي:

```bash
maxauthtries 3
permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
allowusers deploy
authenticationmethods publickey
```

بعد ذلك أعد تحميل الخدمة، واسمها في Ubuntu 24.04 هو `ssh`، ولاحظ أن الجلسات المفتوحة لن تنقطع:

```bash
sudo systemctl reload ssh
```

ثم تأكد من جهازك أن الدخول بالمفتاح يعمل، وأن السيرفر يرفض كلمة المرور ويرفض حساب root:

```bash
ssh deploy@203.0.113.10 'whoami'
ssh -o PubkeyAuthentication=no deploy@203.0.113.10
ssh root@203.0.113.10
```

والمخرج سوف يكون كما يلي، حيث يعيد الأمر الأول اسم المستخدم ويرفض السيرفر الأمرين الآخرين:

```bash
deploy
deploy@203.0.113.10: Permission denied (publickey).
root@203.0.113.10: Permission denied (publickey).
```

💡

نقل SSH إلى منفذ آخر يقلل الضجيج في السجلات، ولكنه ليس حماية حقيقية، فالحماية تأتي من المفاتيح ومن تعطيل الدخول بكلمة المرور. وإذا قررت تغيير المنفذ في Ubuntu 24.04 فلاحظ أن SSH يعمل فيه [بآلية Socket Activation](https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189?ref=arabroot.io)، أي أن systemd هو الذي يستمع على المنفذ ثم يشغل SSH عند أول اتصال (`ssh.socket`)، لذلك يلزمك تنفيذ `sudo systemctl daemon-reload` ثم `sudo systemctl restart ssh.socket`، بعد أن تفتح المنفذ الجديد في جدار الحماية.

### مراجعة المنافذ المفتوحة Listening Ports

قبل إعداد جدار الحماية اعرف ما يستمع على السيرفر فعلاً، فلا معنى أن تغلق أبواباً لا تعرف بوجودها. ويعرض [الأمر ss](https://manpages.ubuntu.com/manpages/noble/man8/ss.8.html?ref=arabroot.io) منافذ TCP وUDP المفتوحة واسم البرنامج الذي يملك كل منفذ:

```bash
sudo ss -tulpn
```

وعلى سيرفر جديد سوف تجد غالباً المنفذ 22، وقد يظهر باسم `systemd` أو `sshd` بسبب آلية Socket Activation، وسوف تجد أيضاً `systemd-resolved` على العنوان المحلي `127.0.0.53`، وهذا لا يصل إليه أحد من الخارج. أما أي خدمة أخرى تستمع على `0.0.0.0` أو `[::]` ولا تحتاجها، فأوقفها بالأمر `sudo systemctl disable --now` متبوعاً باسمها أو احذف حزمتها، والسبب أن كل خدمة مفتوحة للإنترنت هي باب إضافي عليك أن تحرسه وتحدثه.

### إعداد جدار الحماية ufw

القاعدة مع [ufw](https://manpages.ubuntu.com/manpages/noble/man8/ufw.8.html?ref=arabroot.io) بسيطة: ارفض كل اتصال وارد Inbound إلا ما تسمح به صراحة، واسمح بكل اتصال صادر Outbound. **واسمح بـ SSH قبل التفعيل**، وإلا انقطعت جلستك ووجدت نفسك خارج السيرفر:

```bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
```

والمخرج سوف يكون كما يلي:

```bash
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)
```

وإذا كان عنوانك ثابتاً، في مكتب أو عبر VPN، فالأكثر أماناً أن تقصر الوصول إلى SSH عليه، فنفذ `sudo ufw allow from 198.51.100.7 to any port 22 proto tcp` ثم احذف القاعدة العامة بالأمر `sudo ufw delete allow OpenSSH`. ويمكنك أيضاً استخدام `sudo ufw limit OpenSSH` بدلاً من `allow`، وعندها يرفض ufw اتصالات أي عنوان يحاول فتح 6 اتصالات أو أكثر خلال 30 ثانية.

⚠️

إذا ثبت Docker لاحقاً فانتبه، لأن [المنافذ التي تنشرها ال Containers](https://docs.docker.com/engine/network/packet-filtering-firewalls/?ref=arabroot.io) (`ports:`) تتجاوز قواعد ufw، وسوف تجد التفاصيل وطريقة التعامل معها في دليل [تثبيت Docker على Ubuntu](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-docker-%D8%B9%D9%84%D9%89-ubuntu/).

### التحديثات الأمنية التلقائية

أغلب الاختراقات تستغل ثغرات Vulnerabilities صدرت تحديثاتها قبل أسابيع، فالمشكلة في الغالب ليست أن الإصلاح غير موجود، وإنما أن أحداً لم يثبته. وأداة `unattended-upgrades` [تثبت التحديثات الأمنية يومياً](https://ubuntu.com/server/docs/how-to/software/automatic-updates/?ref=arabroot.io) دون تدخل منك، والحزمة Package مثبتة عادة في صور Ubuntu Server، فيكفي أن تفعلها وتتأكد من إعدادها:

```bash
sudo apt install -y unattended-upgrades
echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
```

والمخرج سوف يكون كما يلي، حيث يعني الرقم 1 في السطرين أن تحديث قائمة الحزم Package Lists والتثبيت التلقائي يعملان كل يوم:

```bash
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
```

📌

في مارس 2017 وصل إلى Equifax تنبيه بثغرة معروفة في Apache Struts، ولكن قائمة المرسل إليهم كانت قديمة فلم يصل التنبيه إلى المسؤولين عن تثبيت الإصلاح، ولم يكتشف الفحص بعدها بأسبوع أن بوابة الاعتراضات على الإنترنت ما زالت مصابة. وفي 13 مايو 2017 استغل المهاجمون الثغرة وبقوا قرابة شهرين ونصف حتى اكتشفتهم الشركة في 29 يوليو، وكانت النتيجة الوصول إلى بيانات 145.5 مليون شخص على الأقل كما يذكر [تقرير مكتب المحاسبة الحكومي الأمريكي GAO](https://www.gao.gov/products/gao-18-559?ref=arabroot.io). والدرس أن الإصلاح الذي لا يصل إلى السيرفر لا قيمة له، لذلك لا تترك التحديثات الأمنية لذاكرتك.

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

```bash
sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF
```

ثم شغل تجربة Dry Run تعرض ما سوف يحدث دون أن تنفذه:

```bash
sudo unattended-upgrade --dry-run --debug 2>&1 | grep -E 'Allowed origins|Packages that will be upgraded'
```

والمخرج سوف يكون كما يلي، ولاحظ أن المصادر المسموحة كلها من مستودعات Ubuntu الأمنية:

```bash
Allowed origins are: o=Ubuntu,a=noble, o=Ubuntu,a=noble-security, o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-security
```

### fail2ban (اختياري)

وقد يتساءل البعض: إذا عطلنا الدخول بكلمة المرور، فما فائدة [fail2ban](https://github.com/fail2ban/fail2ban?ref=arabroot.io)؟ والإجابة أن تخمين كلمات المرور لم يعد خطراً حقيقياً على SSH بالفعل، ولكن fail2ban يبقى مفيداً، فهو يحجب العناوين المزعجة مؤقتاً ويخفف الضجيج في السجلات، ويمكنك لاحقاً توسيعه ليحمي تطبيقات أخرى تقبل كلمات المرور:

```bash
sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd

[sshd]
enabled = true
EOF
sudo fail2ban-client -t
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
```

في الإعداد أعلاه لاحظ أن أي عنوان يفشل 5 مرات خلال 10 دقائق سوف يحجب لمدة ساعة، وأن السطر `backend = systemd` يجعل fail2ban يقرأ السجلات من journald.

### إنشاء ملف swap صغير

كثير من صور VPS تأتي دون مساحة swap، وبالتالي إذا ارتفع استهلاك الذاكرة لحظة واحدة فقد يتدخل ال OOM Killer، وهو الآلية التي يوقف بها النظام برنامجاً عندما تنفد الذاكرة، فيوقف عملية Process مهمة مثل قاعدة البيانات. لذلك أنشئ ملف swap صغيراً يمتص هذه الارتفاعات العابرة:

```bash
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system
```

## كيف تتأكد أن كل خطوة نجحت Verification

الآن سوف نتأكد أن كل خطوة سرى مفعولها، وفيما يلي ما يجب أن تراه:

- يرفض السيرفر `ssh root@203.0.113.10` و`ssh -o PubkeyAuthentication=no deploy@203.0.113.10`، ويرد على كليهما بالرسالة `Permission denied (publickey)`.
- الأمر `sudo sshd -T | grep passwordauthentication` يعيد `passwordauthentication no`.
- الأمر `timedatectl` يعرض `System clock synchronized: yes`.
- الأمر `sudo ufw status` يعيد `Status: active`، والمنافذ المفتوحة هي 22 و80 و443 فقط.
- الأمر `systemctl is-active unattended-upgrades` يعيد `active`، والأمر `systemctl list-timers apt-daily-upgrade.timer` يعرض موعد التشغيل التالي، وبعد يوم سوف تجد سجلها في `/var/log/unattended-upgrades/unattended-upgrades.log`.
- إذا نفذت [nmap -Pn 203.0.113.10](https://nmap.org/?ref=arabroot.io) من جهاز خارجي، فلن ترى إلا المنافذ التي سمحت بها.
- الأمر `swapon --show` يعرض الملف `/swapfile`، والأمر `systemd-detect-virt` يعرض نوع التقنية الافتراضية Virtualization، مثل `kvm`.

## النسخ الاحتياطي Backup والاستعادة Restore

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

1. فعل النسخ الاحتياطي التلقائي من لوحة المزود إن كان متاحاً.
2. بعد إتمام التأمين خذ Snapshot يدوياً وسمها باسم واضح (`app01-base-2026-09`)، فهي نقطة الرجوع النظيفة التي سوف تحتاجها إذا أفسد تثبيت لاحق شيئاً.
3. احفظ إعداداتك في مستودع Repository خاص أو في مجلد مخصص للنسخ، والملفات المهمة هي `/etc/ssh/sshd_config.d/` و`/etc/ufw/` و`/etc/apt/apt.conf.d/52unattended-upgrades-local` و`/etc/fail2ban/jail.local`، ويكفي لذلك أرشيف Archive واحد:

```bash
sudo tar czf ~/baseline-$(hostname)-$(date +%F).tar.gz /etc/ssh/sshd_config.d /etc/ufw /etc/apt/apt.conf.d/52unattended-upgrades-local /etc/fail2ban/jail.local /etc/fstab
```

بعد ذلك انقل الأرشيف إلى جهازك بالأمر `scp deploy@203.0.113.10:baseline-*.tar.gz .`. ولاستعادته على سيرفر جديد أنشئ المستخدم نفسه أولاً وانسخ إليه مفتاحك، والسبب أن السطر `AllowUsers` لا يسمح بغيره، ثم فك الأرشيف في `/`، ولكن لا تنسخ الملف `/etc/fstab` كما هو، فهو يشير إلى أقراص السيرفر القديم وقد يمنع الإقلاع Boot، وإنما خذ منه سطر ال swap فقط. ثم نفذ `sudo sshd -t` و`sudo systemctl reload ssh` و`sudo ufw reload`. وعندما تبدأ تثبيت التطبيقات سوف تجد طريقة النسخ الاحتياطي لكل تطبيق في دليله.

## التحديث Upgrade إلى إصدار أحدث

- **التحديثات الأمنية** تتولاها أداة unattended-upgrades، فراجع سجلها كل أسبوع، وإذا لم تفعل إعادة التشغيل التلقائية فراقب الملف `/var/run/reboot-required`.
- **التحديثات العادية** مكانها نافذة صيانة Maintenance Window شهرية، تأخذ فيها Snapshot يدوياً ثم تنفذ `sudo apt update && sudo apt full-upgrade`.
- **الانتقال إلى إصدار Ubuntu LTS التالي** (إلى 26.04 مثلاً) لا يحتاج إلى عجلة، فانتظر أول إصدار تصحيحي Point Release (`.1`)، وخذ Snapshot، ثم نفذ [sudo do-release-upgrade](https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/?ref=arabroot.io) من جلسة داخل [tmux](https://github.com/tmux/tmux/wiki?ref=arabroot.io) أو `screen`، والسبب أن انقطاع اتصال SSH في منتصف الترقية لن يوقفها عندها. ولسيرفرات ال Containers بديل أنظف، وهو أن تجهز سيرفراً جديداً بالإصدار الجديد وتنقل إليه البيانات ثم توجه DNS إليه.
- **زيادة موارد السيرفر**: خذ Snapshot ثم غير الخطة من لوحة التحكم، وبعد الإقلاع تحقق بالأوامر `nproc` و`free -h` و`df -h`. ولاحظ أن بعض المزودين يقومون بزيادة حجم القرص دون أن يقوموا بتوسيع نظام الملفات Filesystem، وعندها تحتاج إلى [growpart](https://manpages.ubuntu.com/manpages/noble/man1/growpart.1.html?ref=arabroot.io) و[resize2fs](https://manpages.ubuntu.com/manpages/noble/man8/resize2fs.8.html?ref=arabroot.io).

## مشكلات شائعة وحلولها Troubleshooting

### السيرفر لا يزال يقبل كلمة المرور

السبب غالباً ملف آخر في `/etc/ssh/sshd_config.d/` يسبق ملفك في الترتيب الأبجدي كما ذكرنا، لذلك اعرض الملفات بالأمر `ls /etc/ssh/sshd_config.d/`، وتأكد أن اسم ملفك يبدأ بـ `00-`، ثم تحقق بالأمر `sudo sshd -T | grep passwordauthentication`.

### رسالة Permission denied (publickey) للمستخدم الجديد

السبب غالباً صلاحيات أو ملكية خاطئة، حيث يجب أن تكون صلاحية `~/.ssh` هي `700` وصلاحية `authorized_keys` هي `600`، وأن يملكهما المستخدم نفسه. وسجل السيرفر يوضح السبب بالأمر `sudo journalctl -u ssh -n 30`، أما على جهازك فيبين الأمر `ssh -v deploy@203.0.113.10` المفاتيح التي جربها العميل.

### فقدت الوصول إلى السيرفر عبر SSH

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

### رسالة Skipping unsupported IPv4 'limit' rule من ufw

سوف ترى هذه الرسالة عندما لا تدعم النواة أو بيئة السيرفر وحدة Module `recent` في iptables، ويحدث هذا داخل ال Containers وفي بعض أنواع التقنية الافتراضية الخفيفة، لذلك تحقق من نوع التقنية الافتراضية، واستخدم `allow` مع fail2ban بدلاً من `limit`.

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- أمن السيرفر قبل أن تثبت عليه أي تطبيق، فالبرامج الآلية تبدأ بتجربة كلمات المرور بعد دقائق من تشغيله.
- ادخل بمفتاح `ed25519` وبمستخدم عادي بصلاحية `sudo`، وعطل الدخول بكلمة المرور وحساب root.
- ضع إعدادات SSH في الملف `00-hardening.conf` وليس في الملف الرئيسي، لأن `sshd` يأخذ أول قيمة يقرؤها، وتحقق دائماً بالأمر `sshd -T`.
- أبق جلسة مفتوحة واختبر الدخول من نافذة ثانية قبل أن تغلق الأولى.
- ارفض كل اتصال وارد في ufw إلا ما تحتاجه، وفعل التحديثات الأمنية التلقائية، فأغلب الاختراقات تستغل ثغرات إصلاحها موجود.
- خذ Snapshot نظيفة وأرشيفاً للإعدادات بعد التأمين، فهما نقطة رجوعك.

## سجل التحديثات

- سبتمبر 2026: كتابة خطوات التأمين واختبارها على Ubuntu 24.04.5 LTS مع OpenSSH 9.6p1 وufw 0.36.2 وunattended-upgrades 2.9.1.
- أكتوبر 2026: فصل خطوات التأمين عن [دليل اختيار الخادم](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D8%AE%D8%A7%D8%AF%D9%85%D8%A7-%D8%A7%D9%81%D8%AA%D8%B1%D8%A7%D8%B6%D9%8A%D8%A7-vps/) في دليل مستقل.
- أكتوبر 2026: إضافة فحص تزامن الوقت ومراجعة المنافذ المفتوحة، وتصحيح مخرجات `ufw status verbose`، والتنبيه إلى ملف `/etc/fstab` عند الاستعادة.