SSH Linux: مفاتيح Ed25519، config، tunnels وhardening — درس خطوة بخطوة

🔝 الدليل الرئيسي: أساسيات Linux 2026

SSH هو باب الدخول لأي خادم Linux بعيد. سيء الإعداد، هو أيضًا الباب الأكثر مهاجمةً على الإنترنت — VPS طازج يرى وسطيًا عدة مئات من محاولات الاتصال الآلية يوميًا، من scanners تجوب باستمرار نطاقات IP للمُضيفين العامين. يأخذك هذا الدرس من الاتصال بكلمة مرور (ممارسة شائعة لكن خطرة) إلى إعداد مُقَوَّى يعتمد على مفاتيح Ed25519، ssh-agent، ملف ~/.ssh/config، tunnels والعادات الجيدة. المرجع البرمجي هو OpenSSH 10.3، المنشور في 2 أبريل 2026 من قبل مشروع OpenBSD.

المتطلبات

• آلة Linux أو macOS كعميل (OpenSSH مُثبَّت افتراضيًا)، أو Windows 11 الذي OpenSSH ميزة أصلية فيه الآن
• خادم Linux قابل للوصول مع وصول root أو sudo
• معرفة أساسية بسطر الأوامر والصلاحيات
• المستوى: متوسط مبتدئ
• الوقت المُقدَّر: 90 دقيقة

الخطوة 1 — فهم كيفية مصادقة SSH

SSH يُقدّم عدة آليات مصادقة. على VPS حديث، الترتيب الافتراضي عادةً مفتاح عام، ثم كلمة مرور، ثم تفاعلي keyboard. الخادم يُجرّبها واحدة تلو الأخرى ويقبل الأولى التي تنجح.

مصادقة كلمة المرور تبدو بسيطة لكن لها عيبان حاسمان في الإنتاج. من جهة، عرضة لـ brute force: الـ scanners تختبر باستمرار أزواج user/password كلاسيكية. من جهة أخرى، تُجبر على حل مستحيل: كلمة مرور طويلة معقدة صعبة الحفظ، فنُعيد استخدامها. الحل الحديث: مصادقة بمفتاح عام. نُولّد على الآلة العميلة زوجًا رياضيًا خاص/عام، نُودع العام على الخادم، ونُثبت ملكية الخاص في كل اتصال دون نقله.

الخطوة 2 — توليد زوج مفاتيح Ed25519

المرجع في 2026 هو Ed25519، curve elliptique صمّمها Daniel J. Bernstein، قصيرة (32 octets)، سريعة، ومقاومة لعدة فئات هجمات معروفة على RSA وECDSA.

ssh-keygen -t ed25519 -C "votre@email.com"
# Enter file in which to save the key (/home/user/.ssh/id_ed25519): [Entrée]
# Enter passphrase (empty for no passphrase): [tapez une phrase de passe robuste]
# Enter same passphrase again: [confirmez]

ثلاثة اختيارات تستحق التفكير. المكان الافتراضي ~/.ssh/id_ed25519 هو الصحيح — agent SSH وغالبية الأدوات تجده تلقائيًا. التعليق -C معلوماتي بحت. passphrase مُوصى به بقوة: يُشفّر المفتاح الخاص على القرص.

ls -l ~/.ssh/
# -rw------- 1 user user 411 May 5 09:00 id_ed25519     ← clé privée, à protéger
# -rw-r--r-- 1 user user 102 May 5 09:00 id_ed25519.pub ← clé publique, à diffuser

cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM... votre@email.com

المفتاح الخاص يجب أن يكون في 600 وdirectory ~/.ssh في 700. SSH يرفض استخدام مفتاح بصلاحيات أكثر تساهلًا. chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub يُعيد كل شيء.

الخطوة 3 — دفع المفتاح العام للخادم

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@adresse-du-serveur
# vous tapez votre mot de passe une dernière fois, la clé est ajoutée
# Number of key(s) added: 1

# Test : la connexion ne doit plus demander de mot de passe
ssh user@adresse-du-serveur

إذا ssh-copy-id غير متاح، النسخة اليدوية:

cat ~/.ssh/id_ed25519.pub | ssh user@adresse "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

بمجرد وضع المفتاح، افتح جلسة SSH جديدة لتأكيد العمل. لا تُغلق الجلسة السابقة قبل هذا التأكيد: إذا كان لديك خطأ في authorized_keys وفشل الاتصال بالمفتاح، الجلسة المفتوحة تُتيح لك التصحيح.

الخطوة 4 — تقوية sshd_config على جانب الخادم

sudo nano /etc/ssh/sshd_config

# ajouter ou modifier :
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

# tester la syntaxe avant de recharger
sudo sshd -t

# recharger sans couper la session courante
sudo systemctl reload ssh        # Debian/Ubuntu
sudo systemctl reload sshd       # Alma/Rocky/RHEL

PermitRootLogin no يمنع الاتصال المباشر كـ root. PasswordAuthentication no يقطع كليًا المصادقة بكلمة مرور؛ فعّل هذا السطر بعد التأكد من عمل مفتاحك. sshd -t مكافئ nginx -t: يتحقق من الصياغة.

للمزيد، AllowUsers deploy malick يُقَيِّد الاتصال بحسابات مُسماة؛ MaxAuthTries 3 يقطع الجلسة بعد 3 إخفاقات؛ ClientAliveInterval 300 وClientAliveCountMax 2 يُغلقان الجلسات الخاملة تلقائيًا. تجنّب تغيير المنفذ 22 إلى 2222: أمن غامض لا يوقف scanners حديثة ويُعقّد أدوات audit.

الخطوة 5 — إعداد العميل بـ ~/.ssh/config

nano ~/.ssh/config
chmod 600 ~/.ssh/config

# contenu :
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    HashKnownHosts no

Host prod
    HostName 1.2.3.4
    User deploy
    IdentityFile ~/.ssh/id_prod
    Port 22

Host bastion
    HostName bastion.exemple.com
    User malick
    IdentityFile ~/.ssh/id_ed25519

Host db-via-bastion
    HostName 10.0.0.5
    User dba
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

مع هذا الملف، ssh prod يكفي. ssh db-via-bastion يقفز تلقائيًا عبر bastion بفضل ProxyJump، دون كشف القاعدة على الإنترنت. كتلة Host * تنطبق على كل الاتصالات وترسل keep-alive كل 60 ثانية.

الخطوة 6 — تحميل المفتاح في ssh-agent

# Démarrer l'agent (sur la plupart des systèmes, lancé automatiquement par le bureau)
eval "\$(ssh-agent -s)"

# Ajouter la clé
ssh-add ~/.ssh/id_ed25519
# Enter passphrase for /home/user/.ssh/id_ed25519: [tapez une fois]
# Identity added: /home/user/.ssh/id_ed25519

# Lister les clés chargées
ssh-add -l

# Vider l'agent (par exemple en quittant le bureau)
ssh-add -D

على macOS، trousseau النظام يخزّن passphrase بين إعادات التشغيل: ssh-add --apple-use-keychain ~/.ssh/id_ed25519. على Windows 11، خدمة OpenSSH Authentication Agent يجب أن تكون مُشغَّلة. عندما يعمل الـ agent، ssh prod لا يعرض أي طلب — هذا الراحة تُحرّر إنتاجية حقيقية.

الخطوة 7 — Tunnels وport forwarding

# Local forward : exposer un port distant sur la machine locale
# Cas : se connecter à PostgreSQL distant (port 5432) sans l'exposer sur Internet
ssh -L 5432:localhost:5432 deploy@prod
# puis dans un autre terminal :
psql -h localhost -p 5432 -U app

# Remote forward : exposer un port local sur le serveur
# Cas : laisser un collègue tester un service en dev local via le serveur public
ssh -R 8080:localhost:3000 deploy@prod

# Dynamic forward : proxy SOCKS5 à travers SSH
# Cas : naviguer comme si vous étiez sur le serveur
ssh -D 1080 deploy@prod
# puis configurer le navigateur en SOCKS5 localhost:1080

الـ tunnels مُشفَّرة من SSH، إذن قابلة للاستخدام بلا خوف على Wi-Fi عام. الـ local tunnel أداة يومية للمطوّر الذي يجب أن يستعلم قاعدة إنتاج دون جعلها عامة. لجعل tunnel دائمًا، أضف LocalForward 5432 localhost:5432 في كتلة Host prod لـ ~/.ssh/config.

الخطوة 8 — التحقق والـ audit

ssh -V                                          # version OpenSSH côté client
ssh -G prod | grep -i "identityfile\|user\|port"   # config résolue pour l'alias prod
ssh -o "BatchMode=yes" prod true && echo "OK clé"  # connexion non-interactive

# Côté serveur (en SSH ouvert) :
sudo sshd -T | grep -iE "permitroot|password|pubkey|maxauth"
sudo grep "Failed\|Accepted" /var/log/auth.log | tail -50
sudo lastlog | head -20

مخرج sshd -T يُظهر الإعداد الفعّال بعد تطبيق كل ملفات include؛ permitrootlogin no، passwordauthentication no، pubkeyauthentication yes يجب أن تظهر. grep على auth.log يُعطي قائمة حديثة للاتصالات. عدد كبير من « Failed » من IPs مجهولة طبيعي على خادم عام، لكن « Accepted » من عنوان غير متوقّع يستحق تحقيقًا فوريًا. لـ audit أعمق، ssh-audit (مجاني، open source) يُعطي علامة A إلى F.

أخطاء شائعة

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

هل نُغيّر منفذ SSH للأمان؟
لا. تغيير 22 إلى 2222 لا يوقف مهاجمًا جادًا — scan كامل لـ IPv4 يستغرق بضع ساعات الآن مع masscan — ويُعقّد الاستخدام المشروع. الدفاع الفعّال: حذف مصادقة كلمة المرور، إضافة fail2ban، وفلترة المنفذ 22 على جانب firewall.

كيف نُشارك حساب خدمة بين مطوّرين دون مشاركة مفتاح خاص؟
كل مطوّر يُولّد زوج مفاتيحه ويضع مفتاحه العام في authorized_keys لحساب الخدمة. أثر الاتصالات يبقى شخصيًا، وإلغاء وصول يتم بحذف السطر. للمنظمات الأكبر، شهادات SSH (موقّعة من CA) تحل محل authorized_keys.

ماذا أفعل إذا فقدت مفتاحي الخاص؟
إذا لا تزال لديك جلسة مفتوحة، احذف السطر من authorized_keys وولّد زوجًا جديدًا. إذا لم يعد لك وصول، استخدم console الطوارئ من مُضيفك (KVM/VNC OVH، console Hetzner، EC2 Instance Connect).

هل OpenSSH 10.3 جلبت تغييرات غير متوافقة؟
إصدار 10.3 من أبريل 2026 يحذف التوافق مع تنفيذات قديمة جدًا. لغالبية الاستخدامات، الترقية شفافة.

كيف نتصل SSH بمفتاح عتادي (YubiKey)؟
OpenSSH يدعم مفاتيح FIDO2/U2F منذ 8.2. الأمر ssh-keygen -t ed25519-sk -C "email" يُولّد زوجًا الجزء الخاص منه يعيش في YubiKey ولا يمكن نسخه. عند كل اتصال، المفتاح الفعلي يجب أن يكون حاضرًا.

ما الفرق بين ~/.ssh/known_hosts و~/.ssh/authorized_keys؟
known_hosts يحوي بصمات الخوادم العامة التي اتصلت بها — العميل يستخدمه للتحقق أن الخادم لم يُستبدَل. authorized_keys يحوي مفاتيح عامة مُصرَّح لها بالاتصال بحساب — الخادم يستخدمه لتعرّف مستخدميه. وظيفتاهما عكسيتان.

مقالات ذات صلة

• نشر agents Wazuh على multi-VPS Linux/Windows: درس 2026
• سطر الأوامر Linux: درس خطوة بخطوة 2026
• صلاحيات Linux: chmod وchown وsudo وACL — درس خطوة بخطوة
• عمليات Linux: ps وtop وhtop وkill والإشارات — درس خطوة بخطوة