تأمين SSH 2026: دليل Ed25519 وFIDO2

Q: كيف أعطّل المصادقة بكلمة المرور في SSH بأمان؟

أولاً تأكد أنّ مفتاحك العام موجود في ~/.ssh/authorized_keys ويعمل دون كلمة مرور، ثم احتفظ بجلسة SSH مفتوحة احتياطياً وعدّل PasswordAuthentication no في /etc/ssh/sshd_config.d/99-hardening.conf . اختبر التكوين بـ sudo sshd -t ثم نفّذ sudo systemctl reload ssh .

Q: هل مفاتيح FIDO2 (YubiKey) أفضل من المفاتيح العادية؟

نعم في معظم سيناريوهات المسؤولين والمطورين. مفاتيح ed25519-sk تحفظ النصف السري داخل الجهاز ولا تغادره، فحتى لو اخترقت محطّتك لا يمكن للمهاجم استخدام المفتاح دون لمس الجهاز فعلياً. العيب الوحيد هو ضرورة وجود الجهاز معك عند الاتصال.

Q: ما هي خوارزميات SSH التي يجب إيقافها في 2026؟

أوقف نهائياً: ssh-dss (DSA)، ssh-rsa المرتبط بـ SHA-1، arcfour ، 3des-cbc ، diffie-hellman-group1-sha1 ، وأي *-cbc . اعتمد فقط على ed25519 ، rsa-sha2-512 ، chacha20-poly1305 ، aes256-gcm ، و curve25519-sha256 .

آخر تحديث: 7 يونيو 2026

تأمين SSH على لينكس في 2026 يعني الاعتماد على مفاتيح Ed25519 أو مفاتيح FIDO2 الأجهزة، وتعطيل المصادقة بكلمة المرور، واستخدام شهادات CA لإدارة الوصول على نطاق المؤسسة، وتقييد الخوارزميات في sshd_config وفق توصيات Mozilla و OpenSSH 9.9+. هذا الدليل العملي يقدّم لك خطوات قابلة للتنفيذ مباشرة على Debian 12/Ubuntu 24.04 وRHEL 9 وAlmaLinux 9 لرفع مستوى تأمين خدمة SSH وتقليل سطح الهجوم بشكل ملموس وقابل للقياس.

بصراحة، في آخر مشروع شغّلت فيه أسطول خوادم على DigitalOcean، اكتشفت أنّ سجلات auth.log امتلأت خلال يومين بأكثر من 40 ألف محاولة دخول فاشلة. الخطوات الموجودة هنا هي نفسها التي طبّقتها لإسكات تلك الضوضاء وتأمين الوصول، وأشاركها معك مرتّبة من الأهم للأقل أهمية.

استخدم مفاتيح Ed25519 بدلاً من RSA-2048 لأنها أقصر، أسرع، وأكثر مقاومة لهجمات القنوات الجانبية.
مفاتيح FIDO2 من نوع ed25519-sk تخزّن جزء المفتاح السري داخل جهاز مادي (YubiKey/SoloKey) فتُلغي خطر سرقة المفاتيح من القرص.
شهادات SSH موقّعة من CA داخلية تستبدل authorized_keys وتمنح صلاحيات قصيرة العمر للمستخدمين.
OpenSSH 9.9 (2025) عطّل افتراضياً خوارزميات DSA و SHA-1، ولن تجد ssh-rsa مفعلاً تلقائياً في 2026.
أداة ssh-audit تكشف نقاط الضعف في تكوين sshd_config وتعطي تقريراً قابلاً للقراءة قبل وبعد التقوية.
دمج fail2ban مع nftables وتفعيل MaxAuthTries=3 يقلل محاولات القوة الغاشمة بأكثر من 95%.

لماذا تقوية SSH ضرورة وليست خياراً في 2026؟

خدمة SSH هي الباب الخلفي الافتراضي لكل خادم لينكس متصل بالإنترنت، ومحاولات الاختراق ضدها لم تتوقف، بل تطوّرت. إحصاءات شبكات honeypots التي تنشرها مؤسسات مثل The Shadowserver Foundation تُظهر أنّ خادم SSH متوسط الانتشار يتلقى ما بين 3000 و 25000 محاولة تسجيل دخول يومياً، أغلبها بأسماء مستخدمين شائعة (root, admin, git) وكلمات مرور مسرّبة من تجميعات قواعد البيانات.

الاتجاهات الجديدة في 2026 جعلت بعض الممارسات القديمة قاصرة. العدوّ بات يمتلك قدرات حاسوبية أعلى، الذكاء الاصطناعي يُستخدم لاستنباط كلمات المرور المحتملة، وبعض خوارزميات التوقيع القديمة مثل ssh-rsa المرتبطة بـ SHA-1 لم تعد مقبولة في OpenSSH الحديث. كذلك دخلت معايير الـ post-quantum الأولية على الخط مع دعم sntrup761x25519 في OpenSSH 9.x لمقاومة هجمات "احصد الآن، فك التشفير لاحقاً".

تقوية SSH اليوم تعني ثلاث طبقات متكاملة: (1) منع وصول كلمة المرور تماماً، (2) ربط المصادقة بجهاز مادي أو شهادة قصيرة العمر، (3) تقييد الخوارزميات المسموحة وتحديد من له الحق بالاتصال أصلاً.

ما هي أفضل خوارزمية مفاتيح SSH في 2026؟

في 2026 الإجابة المختصرة هي Ed25519 للاستخدام العام وed25519-sk عندما تتوفر مفاتيح FIDO2. خوارزمية Ed25519 تعتمد على منحنى Curve25519 وتقدّم مستوى أمان مكافئ لـ RSA-3072 لكن بطول مفتاح 256 بت فقط، مع توقيع أسرع، ومقاومة معروفة لهجمات القنوات الجانبية. أمّا RSA فلا يزال مقبولاً عند طول 4096 بت ولكنه أبطأ ويُنتج مفاتيح أكبر بكثير. ECDSA على منحنى P-256 وP-384 يعمل، لكنه يعتمد على جودة مولّد الأرقام العشوائية، مما جعل بعض مؤسسات الأمان تتحفظ عليه.

الخصائص	Ed25519	RSA-4096	ECDSA P-256	ed25519-sk (FIDO2)
قوة الأمان (تقديرية)	~128 بت	~140 بت	~128 بت	~128 بت + جهاز مادي
طول المفتاح العام	قصير جداً (68 حرفاً)	طويل جداً	متوسط	قصير
سرعة التوقيع	سريع جداً	بطيء نسبياً	سريع	سريع
الحماية من سرقة الملف	تعتمد على ProtectSystem	تعتمد على ProtectSystem	تعتمد على ProtectSystem	المفتاح في جهاز مادي
دعم OpenSSH	6.5+ (شامل)	كافة الإصدارات	5.7+	8.2+
التوصية في 2026	افتراضي للأفراد	توافقية فقط	تجنّبها عند الإمكان	الأمثل للمسؤولين

لاحظ أنّ DSA حُذف نهائياً من OpenSSH 9.8 (يوليو 2024)، ولن تستطيع توليده أو استخدامه في أي توزيعة لينكس حديثة. كذلك مفاتيح ssh-rsa مع SHA-1 معطّلة افتراضياً.

إنشاء واستخدام مفاتيح Ed25519 خطوة بخطوة

توليد زوج مفاتيح Ed25519 جديد لا يحتاج سوى أمر واحد. استبدل [email protected] بهوية تعريفية تساعدك على تمييز المفتاح في authorized_keys لاحقاً.

# توليد زوج مفاتيح Ed25519 مع تشديد عدد دورات KDF
ssh-keygen -t ed25519 -a 100 -C "ops@linuxsecureops 2026-06" -f ~/.ssh/id_ed25519

# عرض البصمة بصيغة SHA256
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# نسخ المفتاح العام إلى الخادم
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

الخيار -a 100 يرفع عدد دورات اشتقاق المفتاح من passphrase إلى 100، مما يجعل هجمات القوة الغاشمة ضد ملف المفتاح الخاص أبطأ بحوالي 50 ضعفاً مقارنة بالقيمة الافتراضية. بعد توليد المفتاح، حدّد صلاحيات صارمة على المجلد:

# صلاحيات صحيحة لمجلد ‎.ssh والمفاتيح
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys 2>/dev/null || true

# (اختياري) تخزين المفتاح في ssh-agent للجلسة الحالية فقط
eval "$(ssh-agent -s)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519  # على macOS
ssh-add ~/.ssh/id_ed25519                         # على لينكس

كيف أستخدم مفاتيح FIDO2 الأجهزة مع SSH؟

مفاتيح الأجهزة من نوع FIDO2/U2F (مثل YubiKey 5، SoloKey 2، Nitrokey 3) تتيح توقيع SSH بحيث يكون "النصف السري" من المفتاح مخزّناً داخل الجهاز ولا يغادره أبداً. عندما تحاول الاتصال، تُجبَر على لمس الجهاز للتأكيد، مما يقضي على هجمات السرقة عن بُعد حتى لو اخترق المهاجم محطّتك. OpenSSH يدعم نوعين: ecdsa-sk و ed25519-sk، ونوصي بالثاني.

صراحة، أوّل مرة استخدمت فيها YubiKey مع SSH ظننت أنّ الإعداد سيكون معقّداً. خمس دقائق فقط ومفتاحي كان جاهزاً، والآن لا أتخيّل العودة لمفاتيح ملف على القرص.

# توليد مفتاح ed25519-sk مرتبط بجهاز FIDO2
ssh-keygen -t ed25519-sk -O resident -O verify-required \
  -C "yubikey-laptop 2026-06" -f ~/.ssh/id_ed25519_sk

# الخيار -O resident: تخزين المفتاح داخل الجهاز ليُستعاد لاحقاً
# الخيار -O verify-required: يطلب PIN مع كل عملية توقيع

إذا انتقلت إلى محطة جديدة، تستطيع استرجاع المفاتيح المخزّنة في الجهاز بأمر ssh-keygen -K. هذا يجعل مفتاح YubiKey واحد يعمل عبر عدة أجهزة دون نسخ الملفات.

# استعادة المفاتيح المقيمة من جهاز FIDO2 إلى مجلد جديد
cd ~/.ssh && ssh-keygen -K

# نسخ المفتاح العام إلى الخادم (تماماً كما هو الحال مع المفاتيح العادية)
ssh-copy-id -i ~/.ssh/id_ed25519_sk_rk.pub [email protected]

يجب التأكد أنّ إصدار OpenSSH على الخادم يبلغ 8.2 أو أحدث لدعم *-sk. كل التوزيعات المدعومة حالياً (Ubuntu 22.04+, Debian 12+, RHEL 9+) تستوفي ذلك. لمزيد من التفاصيل الرسمية حول دعم FIDO2 راجع ملاحظات إصدار OpenSSH 8.2.

شهادات SSH عبر CA: البديل الأنيق لـ authorized_keys

إدارة authorized_keys على عشرات الخوادم تصبح كابوساً مع نمو الفريق. الحل الذي تتبنّاه شركات مثل Facebook وUber هو شهادات SSH الموقّعة بمفتاح CA داخلي. الخادم يثق بالـ CA مرة واحدة، وأي شهادة موقّعة منه (تحتوي اسم المستخدم وقائمة الخوادم المسموحة ومدة صلاحية قصيرة) تُقبَل تلقائياً دون نسخ مفاتيح.

# 1) إنشاء مفتاح CA (نوصي بتشفير قوي وحماية بـ HSM في الإنتاج)
ssh-keygen -t ed25519 -a 200 -f /etc/ssh/ca/host_ca -C "linuxsecureops-host-ca"
ssh-keygen -t ed25519 -a 200 -f /etc/ssh/ca/user_ca -C "linuxsecureops-user-ca"

# 2) على كل خادم: نشر المفتاح العام للـ CA وثقته
echo "@cert-authority *.example.com $(cat /etc/ssh/ca/host_ca.pub)" \
  | sudo tee -a /etc/ssh/ssh_known_hosts

# 3) في sshd_config أخبر الخادم بقبول الشهادات الموقّعة من user_ca
echo "TrustedUserCAKeys /etc/ssh/ca/user_ca.pub" | sudo tee -a /etc/ssh/sshd_config.d/50-ca.conf
sudo systemctl reload ssh

# 4) إصدار شهادة لمستخدم تنتهي بعد 8 ساعات فقط
ssh-keygen -s /etc/ssh/ca/user_ca \
  -I "ops-jane-2026-06" \
  -n jane,ops \
  -V +8h \
  -z 1001 \
  ~/.ssh/id_ed25519.pub

أي شهادة تنتهي تلقائياً بعد 8 ساعات تُلغي الحاجة لتدوير المفاتيح يدوياً عند مغادرة موظف. لتطبيق الإلغاء الفوري قبل انتهاء الصلاحية استخدم خيار RevokedKeys في sshd_config.

تكوين sshd_config الموصى به في 2026

ملف /etc/ssh/sshd_config الافتراضي يحتاج تعديلات عدة. التوصية أن تضع تخصيصاتك في ملف منفصل داخل /etc/ssh/sshd_config.d/ ليبقى الأصل قابلاً للتحديث. فيما يلي تكوين متوازن مستوحى من إرشادات Mozilla لـ OpenSSH ومعدّل لـ 2026.

# /etc/ssh/sshd_config.d/99-hardening.conf
Port 22
AddressFamily inet
Protocol 2

# المصادقة
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 30s

# تقييد المستخدمين والمجموعات
AllowGroups ssh-users

# الخوارزميات (متوافقة مع OpenSSH 9.x ومقاومة لما بعد الكم)
KexAlgorithms [email protected],curve25519-sha256,[email protected]
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# التسجيل
SyslogFacility AUTH
LogLevel VERBOSE

# منع التوجيه غير المرغوب
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitUserEnvironment no
PermitTunnel no

# الحفاظ على الاتصال
ClientAliveInterval 300
ClientAliveCountMax 2

بعد كل تعديل، تحقق من صحة التكوين قبل إعادة التحميل، فأي خطأ قد يقفل عليك الخادم:

# فحص بنية ملف التكوين
sudo sshd -t

# إعادة تحميل بدون قطع الجلسات الحالية
sudo systemctl reload ssh

# إبقاء جلسة احتياطية مفتوحة في طرفية أخرى قبل إعادة التحميل

إذا كنت تدير جدار حماية متقدماً، راجع دليلنا حول بناء جدار حماية حديث بـ nftables وضع قاعدة tcp dport 22 accept فقط للشبكات الموثوقة.

تعطيل كلمة المرور وتفعيل المصادقة الثنائية

الخطوة الأهم وأبسط الخطوات أثراً هي تعطيل PasswordAuthentication بعد التأكد أنّ مفتاحك يعمل. هذا وحده يحبط 99% من هجمات بوتنت Mirai وأخواتها التي تجوب الإنترنت بحثاً عن SSH مفتوح بكلمات مرور افتراضية. بعد التعطيل، أَضف طبقة مصادقة ثانية اختيارياً عبر TOTP أو شهادة CA.

لإضافة مصادقة TOTP (مثل Google Authenticator أو Aegis)، استخدم libpam-google-authenticator أو pam-u2f:

# تثبيت الحزمة على Debian/Ubuntu
sudo apt install libpam-google-authenticator

# على RHEL/AlmaLinux
sudo dnf install google-authenticator

# لكل مستخدم: توليد سر TOTP وحفظه في ~/.google_authenticator
google-authenticator -t -d -f -r 3 -R 30 -W

# تفعيل وحدة PAM في /etc/pam.d/sshd
echo "auth required pam_google_authenticator.so nullok" \
  | sudo tee -a /etc/pam.d/sshd

# في sshd_config: المصادقة بمفتاح ثم TOTP
sudo sed -i 's/^#*KbdInteractiveAuthentication.*/KbdInteractiveAuthentication yes/' /etc/ssh/sshd_config
echo "AuthenticationMethods publickey,keyboard-interactive" \
  | sudo tee /etc/ssh/sshd_config.d/60-mfa.conf
sudo systemctl reload ssh

الفاصلة في publickey,keyboard-interactive تعني كلاهما مطلوب وليس "أيٌّ منهما"، وهذا هو الفرق بين MFA حقيقي ومفتاح فقط.

التحقق من قوة التكوين بأداة ssh-audit

ssh-audit أداة مفتوحة المصدر مكتوبة بـ Python تتصل بمنفذ SSH وتُحلّل الخوارزميات والإصدار وتُصدر تقريراً مفصّلاً يصنّف كل عنصر إلى آمن أو ضعيف أو متقادم. منذ إصدار 3.3 الصادر أواخر 2025 أصبحت تتعرف على خوارزميات ما بعد الكم وتنبّه إذا كانت مفقودة.

# تثبيت سريع عبر pipx
pipx install ssh-audit

# فحص الخادم
ssh-audit server.example.com -p 22

# توليد سياسة من تكوينك الحالي والاحتفاظ بها
ssh-audit server.example.com -p 22 --make-policy=baseline.txt

# تطبيق السياسة لاحقاً للتأكد من عدم وجود انحراف
ssh-audit server.example.com -p 22 --policy=baseline.txt

الناتج يصنّف مفاتيح المضيف، الخوارزميات، الشيفرات، MACs، ويعطي درجة من A+ إلى F. هدفك أن تصل إلى A+ مع 0 تحذيرات. ادمج هذا الأمر في خط CI الخاص بك بعد أي تغيير في sshd_config لمنع أي تراجع غير مقصود في الأمان.

حماية SSH من هجمات القوة الغاشمة

حتى مع تعطيل كلمة المرور، يستهلك المهاجمون نطاقاً ترددياً وعرض حزمة، ويملؤون السجلات بمحاولات فاشلة. الحل المعتمد هو fail2ban الذي يقرأ /var/log/auth.log ويحجب عناوين IP المخالفة عبر nftables أو iptables. منذ إصدار 1.1 (2024) أصبح يدعم backend nftables أصلياً.

# تثبيت fail2ban
sudo apt install fail2ban  # Debian/Ubuntu
sudo dnf install fail2ban  # RHEL/AlmaLinux

# /etc/fail2ban/jail.local
sudo tee /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
banaction = nftables-multiport
bantime = 1h
findtime = 10m
maxretry = 4
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8

[sshd]
enabled = true
port    = ssh
backend = systemd
EOF

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

في 2026 يفضّل بعض المسؤولين استبدال fail2ban بـ CrowdSec الذي يشارك قوائم العناوين السيئة عبر شبكة موزعة. كلا الحلين صحيح، والأهم أن لا تترك المنفذ مكشوفاً للجمهور دون رصد. اقرأ في دليلنا حول تأمين لينكس بـ eBPF كيف يمكن إضافة رصد على مستوى النواة لمحاولات تسجيل دخول مشبوهة.

هل أحتاج إلى Port Knocking أو نقل المنفذ؟

نقل SSH من المنفذ 22 إلى منفذ غير قياسي (مثل 2222) يقلل الضجيج في السجلات لكنه ليس حماية حقيقية، لأنّ الماسحات تكتشفه خلال دقائق. Port knocking وsingle packet authorization (مثل fwknop) أكثر قوة لأنّ المنفذ يبقى مغلقاً تماماً حتى يصل تسلسل سري صحيح، وهو مفيد في بيئات ذات تهديد عالٍ لكنه يضيف تعقيداً تشغيلياً. التوصية: اعتمد على المفاتيح + جدار حماية + fail2ban أولاً، ولا تنقل المنفذ إلا إذا كنت تواجه ضغطاً غير معقول من السجلات.

قائمة فحص نهائية لتقوية SSH

قبل اعتبار خادمك مؤمّناً، تأكد من تحقيق كل بند:

تعطيل دخول root المباشر (PermitRootLogin no).
تعطيل كلمة المرور تماماً (PasswordAuthentication no).
الاعتماد على Ed25519 أو ed25519-sk فقط، وإزالة المفاتيح القديمة من authorized_keys.
تكوين AllowGroups أو AllowUsers لمنع المستخدمين غير المصرّح لهم من المحاولة أصلاً.
تقييد KexAlgorithms, Ciphers, MACs وفق التوصيات أعلاه.
تشغيل ssh-audit والوصول إلى تصنيف A+.
تفعيل fail2ban أو CrowdSec مع backend nftables.
إعداد نظام تنبيه على محاولات تسجيل دخول ناجحة من عناوين IP جديدة.
توثيق إجراء طوارئ لاسترداد الوصول (وحدة تحكم خارج النطاق، KVM، أو cloud console).
اختبار النسخة الاحتياطية للمفاتيح في خزينة كلمات مرور أو HSM.

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

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

ما الفرق بين Ed25519 وRSA لمفاتيح SSH؟

Ed25519 يستخدم منحنى Curve25519 وينتج مفاتيح بطول 256 بت توفر أماناً يكافئ RSA-3072 لكن بسرعة توقيع أعلى بحوالي 10 أضعاف. RSA-4096 لا يزال آمناً لكنه أبطأ ويُنشئ مفاتيح أكبر بكثير. في 2026 يُوصى افتراضياً بـ Ed25519 ما لم تحتج توافقاً مع نظام قديم جداً.

كيف أعطّل المصادقة بكلمة المرور في SSH بأمان؟

أولاً تأكد أنّ مفتاحك العام موجود في ~/.ssh/authorized_keys ويعمل دون كلمة مرور، ثم احتفظ بجلسة SSH مفتوحة احتياطياً وعدّل PasswordAuthentication no في /etc/ssh/sshd_config.d/99-hardening.conf. اختبر التكوين بـ sudo sshd -t ثم نفّذ sudo systemctl reload ssh.

هل يحمي تغيير منفذ SSH من المنفذ 22 إلى منفذ آخر؟

التغيير يقلل ضجيج السجلات لكنه ليس حماية حقيقية لأن ماسحات المنافذ تكتشف الخدمة خلال دقائق. الأمان الحقيقي يأتي من تعطيل كلمة المرور، استخدام مفاتيح Ed25519 أو FIDO2، تقييد المستخدمين بـ AllowGroups، وتفعيل fail2ban.

هل مفاتيح FIDO2 (YubiKey) أفضل من المفاتيح العادية؟

نعم في معظم سيناريوهات المسؤولين والمطورين. مفاتيح ed25519-sk تحفظ النصف السري داخل الجهاز ولا تغادره، فحتى لو اخترقت محطّتك لا يمكن للمهاجم استخدام المفتاح دون لمس الجهاز فعلياً. العيب الوحيد هو ضرورة وجود الجهاز معك عند الاتصال.

كم مرة يجب تدوير مفاتيح SSH؟

للمفاتيح الشخصية: عند مغادرة موظف أو الشك في تسريب فقط. للوصول الآلي (CI/CD، نسخ احتياطي): كل 6-12 شهر. أفضل ممارسة هي استبدال authorized_keys تماماً بشهادات CA قصيرة العمر تنتهي تلقائياً، مما يلغي الحاجة للتدوير اليدوي.

ما هي خوارزميات SSH التي يجب إيقافها في 2026؟

أوقف نهائياً: ssh-dss (DSA)، ssh-rsa المرتبط بـ SHA-1، arcfour، 3des-cbc، diffie-hellman-group1-sha1، وأي *-cbc. اعتمد فقط على ed25519، rsa-sha2-512، chacha20-poly1305، aes256-gcm، و curve25519-sha256.