Fail2ban على Ubuntu 24.04: أوقف هجمات SSH

ما الذي يفعله Fail2ban فعلًا

Fail2ban برنامج خفي (daemon) يقرأ السجلّات. يراقب رسائل مصادقة SSH لديك، وبعد حفنة من المحاولات الفاشلة من عنوان واحد خلال نافذة زمنية قصيرة، ينفّذ أمرًا في جدار الحماية يحجب ذلك العنوان لفترة من الوقت. هذه هي الفكرة كلها. الأمر كله نحو ثلاثين سطرًا من الإعدادات في ملف واحد، وعلى Ubuntu 24.04 يتم التثبيت بأمر apt واحد يتركك محميًّا قبل أن تعدّل أي شيء.

كن واضحًا بشأن ما يفعله هذا البرنامج وما لا يفعله. لا يقوم Fail2ban بمصادقة أحد، ولا يشفّر شيئًا، ولا يوقف محاولة تسجيل دخول واحدة مصمِّمة على النجاح — بل يوقف فقط المحاولات المتكررة من المصدر نفسه. إنه مرشِّح ضجيج ومحدِّد لمعدل المحاولات، لا قفل. مهمته أن يجعل المسح المستمر للمنفذ 22 في الخلفية يكفّ عن إهدار الـ CPU وعرض النطاق ومساحة السجلّات لديك، وأن يبطئ أي مهاجم مضطر إلى المجيء من عنوان واحد في كل مرة.

ما الذي لا يغني عنه Fail2ban

Fail2ban هو الطبقة الثالثة، لا الأولى. إذا كان خادمك لا يزال يقبل كلمات مرور SSH، فإن شبكة أجهزة مخترقة (botnet) موزّعة على آلاف العناوين تستطيع مواصلة التخمين، لأن كل عنوان يبقى تحت عتبة الحظر لديك ولا يتجاوزها أبدًا. الدفاع الحقيقي ضد ذلك هو المصادقة بالمفاتيح فقط، التي تجعل تخمين كلمات المرور مستحيلًا مهما بلغ عدد المحاولات. أما Fail2ban فوق المصادقة بالمفاتيح فقط فيفعل شيئين مفيدين: يشذّب ضجيج القوة الغاشمة من سجلّاتك، ويطرد الماسحات مبكرًا فتكفّ عن قصف المنفذ. عامله على أنه دفاع في العمق. مكانه خلف المصادقة بالمفاتيح وخلف جدار الحماية، لا أمامهما أبدًا.

المتطلبات المسبقة، وواقع Ubuntu 24.04

تحتاج إلى خادم VPS يعمل بنظام Ubuntu 24.04 مع صلاحيات root أو sudo، وإلى SSH يعمل مسبقًا — ويُفضَّل أن يكون بالمصادقة بالمفاتيح. Fail2ban مقتصد: بضع عشرات من الميغابايتات من ذاكرة RAM، ولا حاجة إلى ضبط أي حدود.

والآن الجزء الذي تخطئ فيه كل الأدلة القديمة. لسنوات كانت النصيحة المعتادة: «ثبّت Fail2ban ثم أضف backend = systemd، لأن Ubuntu توقف عن كتابة /var/log/auth.log». هذه النصيحة تصف تغييرًا حقيقيًا — فصور الخوادم والسحابة الحديثة تأتي من دون rsyslog، ولذلك لا يكتب SSH سجلّاته إلا في سجلّ systemd المعروف باسم journal، وذلك الملف النصي لم يعد موجودًا — لكن حزمة Fail2ban على Ubuntu 24.04 تأخذ ذلك في الحسبان أصلًا. تضع الحزمة الملف /etc/fail2ban/jail.d/defaults-debian.conf، وهذا الملف، لا القيم الافتراضية الأصلية، هو ما يشغّله خادمك فعلًا:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

اقرأ ذلك بتمعّن، لأنه يحسم سؤالين قبل أن تلمس أي شيء. backend = systemd يعني أن «السجن» (jail) الخاص بـ SSH يقرأ من الـ journal، فلا يهم غياب auth.log. وbanaction = nftables يعني أن الحظر يُنفَّذ عبر nftables، وهو جدار الحماية الذي يستخدمه Ubuntu 24.04 فعلًا، لا iptables القديم. و[sshd] enabled = true يعني أن السجن مفعّل منذ أول إقلاع. الخلاصة: تنفيذ apt install fail2ban كما هو على Ubuntu 24.04 يحظر هجمات القوة الغاشمة على SSH فور التثبيت. معظم عملك هو التأكد من ذلك، وضبط السياسة، والحرص على ألا تحبس نفسك خارج خادمك.

فخّ auth.log القديم ما زال يُطبِق على ضحاياه في ثلاث حالات، ومن المفيد التعرف عليها: أن تكون قد ثبّت Fail2ban بـ pip بدلًا من apt فلا يوجد لديك defaults-debian.conf؛ أو أن تكون داخل حاوية غير مميّزة الصلاحيات (unprivileged container) لا يوجد فيها journal لـ systemd يمكن قراءته؛ أو أن تكون قد اتبعت درسًا قديمًا ولصقت backend = auto في ملف jail.local الخاص بك فتجاوزت القيمة الافتراضية العاملة. يعرض قسم أنماط الفشل أدناه الشكل الدقيق لكل حالة منها.

الخطوة 1: ثبّت وتأكد من أنه يحظر بالفعل

sudo apt update
sudo apt install -y fail2ban

يأتي Ubuntu 24.04 بالإصدار Fail2ban 1.0.2، وتسحب الحزمة معها python3-systemd بوصفها اعتمادية إلزامية، وبذلك تملك واجهة journal الخلفية (backend) كل ما تحتاج إليه. تُفعَّل الخدمة وتبدأ من تلقاء نفسها:

sudo systemctl status fail2ban

ما تريد رؤيته هو active (running). ثم ألقِ نظرة على السجن الذي يؤدي عمله بالفعل:

sudo fail2ban-client status sshd

على خادم VPS عام ظل متاحًا ولو لدقائق معدودة، سترى غالبًا محاولات فاشلة مُحصاة في العدّاد وعناوين محظورة بالفعل — فالإنترنت يمسح المنفذ 22 بلا توقف. هذا هو الدليل على أن الإعدادات الأصلية تعمل. من هنا فصاعدًا أنت تصقلها، لا تبنيها من الصفر.

الخطوة 2: عدّل jail.local، ولا تلمس jail.conf أبدًا

يحتفظ Fail2ban بقيمه الافتراضية الأصلية في /etc/fail2ban/jail.conf. لا تعدّل هذا الملف. فكل apt upgrade للحزمة قد يستبدله، فتختفي تعديلاتك بلا أي تحذير. يقرأ Fail2ban الملفات بترتيب ثابت — jail.conf أولًا، ثم كل ما في jail.d/، ثم jail.local — والقيمة الأخيرة هي التي تفوز. ملف .local ملكك، وترقيات الحزمة لا تمسّه أبدًا. القاعدة نفسها تنطبق على المرشِّحات، حيث يطغى ملف *.local على ملف filter.d/*.conf المرفق مع الحزمة.

لذلك تكتب ملف jail.local صغيرًا لا يغيّر إلا حفنة الإعدادات التي تهمّك، وتترك كلًّا من jail.conf وملف الحزمة jail.d/defaults-debian.conf كما هما مرجعين.

الخطوة 3: اكتب /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

ضع فيه ما يلي، مع تغيير العنوان في سطر ignoreip إلى عنوان IP العام الخاص بك:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

كل سطر يستحق مكانه:

• bantime وfindtime وmaxretry هي السياسة. قيمة bantime الافتراضية المرفقة عشر دقائق فقط؛ والساعة الواحدة حد أدنى أعقل. خمس محاولات فاشلة من عنوان واحد خلال عشر دقائق تستوجب الحظر. البشر يخطئون في كتابة كلمة المرور مرة أو مرتين؛ أما خمسة إخفاقات في عشر دقائق فهي سكربت.
• ignoreip هو حزام أمانك. ضع فيه العنوان العام الذي تتصل منه حتى لا يستطيع Fail2ban أبدًا حبسك خارج خادمك. اتصال منزلي بعنوان IP متغيّر سببٌ لتفضيل نهج VPN المذكور في النهاية، لا سببٌ لتخطي هذا السطر.
• bantime.increment = true يجعل كل حظر متكرر أطول من سابقه — ساعة، ثم ساعتان، ثم أربع — وصولًا إلى bantime.maxtime. فالعناوين التي تواصل العودة تجد نفسها محظورة مددًا أطول فأطول.

اعثر على العنوان الذي ستضعه في القائمة البيضاء من الجهاز الذي تتصل عبر SSH منه، لا من الخادم:

curl -s ifconfig.me

يمكنك هنا توليد ملف jail.local مضبوط على منافذك وسياسة الحظر لديك، ثم لصقه في الملف:

الخطوة 4: أعد التشغيل وتحقق أنه يقرأ من الـ journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

الخيار -t يجري اختبارًا للإعدادات أولًا، فينكشف أي خطأ كتابي في jail.local هنا على الفور بدلًا من أن يترك الخدمة معطّلة. حالة السجن السليمة تبدو هكذا:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

الرقم الذي يثبت أن Fail2ban يقرأ تسجيلات دخولك فعلًا هو Total failed. إن كان فوق الصفر، أو ارتفع حين تتعمّد إفشال تسجيل دخول من جهاز آخر، فالـ journal يُقرأ وقد انتهيت. أما إن بقي عند 0 مهما أفشلت من محاولات — وكنت متأكدًا أنك لا تختبر من العنوان المدرج في ignoreip — فانتقل إلى أنماط الفشل أدناه.

لاحظ أن سطر Journal matches ما زال يذكر sshd.service. على Ubuntu وحدة SSH هي في الحقيقة ssh.service، لكن المرشِّح المرفق يطابق أيضًا القيمة _COMM=sshd، وOpenSSH على 24.04 يسجّل إخفاقاته من عملية اسمها sshd، لذا تنجح المطابقة. هذا التفصيل لا يهم إلا إذا كنت على إصدار أحدث من OpenSSH (الإصدار 9.8 وما بعده، حيث العملية العاملة لكل اتصال اسمها sshd-session)؛ ويغطي قسم أنماط الفشل تلك الحالة.

الخطوة 5: راقب حظرًا حقيقيًا وهو يقع، أو افرض واحدًا للاختبار

الحظر الحقيقي يصل من تلقاء نفسه خلال دقائق على أي خادم VPS عام. لمراقبته تابع السجل مباشرة:

sudo tail -f /var/log/fail2ban.log

يبدو الحظر هكذا:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

ولإثبات عمل الآلية من طرفها إلى طرفها دون انتظار، احظر يدويًا عنوانًا مخصصًا للتوثيق — لا عنوانك أنت أبدًا:

sudo fail2ban-client set sshd banip 10.0.0.66

يطبع الأمر 1، ويظهر العنوان تحت Banned IP list في fail2ban-client status sshd. تأكد الآن من أن الحجب موجود فعلًا في جدار الحماية. على Ubuntu 24.04 هذا يعني nftables لا iptables:

sudo nft list table inet f2b-table

سترى مجموعة اسمها addr-set-sshd تحوي 10.0.0.66، وسلسلة f2b-chain ترفض أي مصدر موجود في تلك المجموعة. إذا قال fail2ban-client إن عنوانًا محظور لكن لا شيء يظهر في nft list، فإجراء الحظر لديك لا يطابق جدار حمايتك — راجع ملاحظة nftables/iptables في قسم أنماط الفشل.

الخطوة 6: ارفع الحظر عن نفسك، واستعد الوصول إذا حُبست في الخارج

إذا حظرت عنوانًا لم يكن ينبغي حظره — عنوانك أنت — فأزله:

sudo fail2ban-client set sshd unbanip 10.0.0.66

يعيد الأمر 1 عند النجاح. ولمسح كل حظر في كل السجون:

sudo fail2ban-client unban --all

لا تعوّل على جلسة SSH مفتوحة مسبقًا لإنقاذك: حظر nftables يرفض كل حزمة قادمة من العنوان المحظور إلى المنفذ 22 — بما في ذلك الاتصالات القائمة — فتتجمد الجلسة الموجودة لحظة وقوع الحظر. إذا حظرت نفسك ولم يكن لديك إدخال في ignoreip، فأنت محبوس في الخارج حتى تنقضي مدة الحظر — استعد الوصول عبر وحدة التحكم عبر الويب لدى مزوّد الخدمة (VNC أو الطرفية التسلسلية)، فهي لا تمر عبر SSH، ثم إما أن تنتظر انقضاء bantime أو تنفّذ أمر رفع الحظر من هناك.

الخطوة 7: اجعل الحظر يدوم ويتصاعد

يحتفظ Fail2ban بالحظر النشط في قاعدة بيانات SQLite صغيرة في /var/lib/fail2ban/fail2ban.sqlite3، فيبقى بعد إعادة تشغيل الخدمة أو إعادة إقلاع الجهاز؛ فأنت لا تفقده. أما أسطر bantime.increment التي أضفتها بالفعل فتجعل كل عنوان يعاود الهجوم يجلب على نفسه حظرًا يتضاعف تقريبًا في كل مرة، من ساعة واحدة وصولًا إلى أسبوع كامل.

ولإضافة سياسة «الضربات الثلاث» على مستوى النظام فوق ذلك، يأتي Fail2ban بسجن اسمه recidive يراقب ملفه الخاص /var/log/fail2ban.log ويوقع حظرًا طويلًا على أي عنوان حُظر مرارًا عبر جميع السجون. ولأن قسم [DEFAULT] لديك يستخدم الآن واجهة systemd الخلفية، أعد ربط هذا السجن صراحةً بملف السجل الذي صُمم لقراءته:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto مع logpath الصريح يبقي recidive على قراءة ملف fail2ban.log العادي، وهو المكان الذي تظهر فيه فعلًا أسطر Ban التي يعدّها — بينما قيمة systemd الافتراضية التي ضبطتها على المستوى العام كانت ستوجهه إلى الـ journal، حيث لا تظهر تلك الأسطر.

الخطوة 8: اقرنه بمصادقة SSH بالمفاتيح فقط، والأفضل أن تضيف VPN

لا يستحق Fail2ban مكانه إلا إلى جانب المصادقة بالمفاتيح. في ملف drop-in تحت /etc/ssh/sshd_config.d/ — وليكن /etc/ssh/sshd_config.d/00-hardening.conf — اضبط:

PasswordAuthentication no
KbdInteractiveAuthentication no

ثم sudo systemctl restart ssh. مع تعطيل كلمات المرور لا يمكن للقوة الغاشمة أن تنجح إطلاقًا؛ ويبقى دور Fail2ban عندها قطع ضجيج السجلّات وطرد الماسحات مبكرًا. والأقوى من ذلك أن تُبقي SSH خارج الإنترنت العام كليًا: ضع SSH خلف شبكة WireGuard VPN مستضافة ذاتيًا واحجب المنفذ 22 بجدار الحماية بحيث لا يجيب إلا عبر النفق. لا أحد يستطيع شن هجوم قوة غاشمة على منفذ لا يمكنه الوصول إليه، ويتحول Fail2ban إلى خط إسناد خلفي بدلًا من خط المواجهة الأمامي.

Fail2ban ليس لـ SSH وحده. أي خدمة تسجّل محاولات دخول فاشلة يمكن أن تحصل على سجن — خادم بريد، أو موقع nginx، أو مدير كلمات مرور Vaultwarden مستضاف ذاتيًا لا تريد ترك واجهة دخوله على الويب مفتوحة أمام هجمات حشو بيانات الاعتماد (credential stuffing). وحين يستقر تطبيق ويب خلف موقع nginx بشهادة Let's Encrypt، وجّه مرشِّح Fail2ban إلى سجل الوصول الخاص به بالطريقة نفسها التي يتوجه بها سجن SSH إلى الـ journal.

أنماط الفشل، مع النصوص التي ستراها حرفيًا

«Have not found any log file for sshd jail»، وFail2ban يرفض البدء. هذه هي مشكلة auth.log القديمة، وعلى Ubuntu 24.04 لا تصادفها إلا إذا تجاوز شيء ما الإعداد الافتراضي للحزمة — تثبيت عبر pip بلا defaults-debian.conf، أو حاوية بلا journal، أو backend = auto شارد لصقته في jail.local. مع واجهة خلفية ملفّية بلا /var/log/auth.log، لا يجد سجن sshd سجلّه فينهار البرنامج الخفي كله. يعرض fail2ban.log:

ERROR   Failed during configuration: Have not found any log file for sshd jail

ولأن هذا الخطأ قاتل، لا تبدأ الخدمة أبدًا، فيبلّغ fail2ban-client status عندها عن العَرَض التالي في السلسلة:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

سطر «socket path» هذا لا يعني أن Fail2ban معطوب — بل يعني أنه لم يبدأ أصلًا لأن أحد السجون لم يجد سجلّه. ضبط backend = systemd في [DEFAULT]، وهو ما تفعله حزمة Ubuntu عنك مسبقًا، يصلح الرسالتين معًا دفعة واحدة.

السجن نشط لكن Total failed لا يتحرك أبدًا. البرنامج الخفي يعمل والـ journal يُقرأ، ومع ذلك تتراكم الإخفاقات الحقيقية في journalctl -u ssh بينما يظل العداد عند 0. استبعد الواضح أولًا: أنت تختبر من عنوان مدرج في ignoreip، فإخفاقاتك أنت معفاة بحكم التصميم. إن لم يكن الأمر كذلك، فأنت على نسخة من OpenSSH تكون فيها العملية العاملة لكل اتصال هي sshd-session (الإصدار 9.8 وما بعده)، وقيمتها _COMM في الـ journal هي sshd-session لا sshd، فتفوتها المطابقة المرفقة. وسّع المطابقة في قسم [sshd]:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

أعد التشغيل، وأفشل تسجيل دخول عمدًا من عنوان غير موجود في ignoreip، وتأكد من أن Total failed بدأ أخيرًا في الارتفاع.

حظرت نفسك: Connection refused. تركت عنوانك خارج ignoreip، وجرّبت بضع محاولات دخول خاطئة، والآن:

ssh: connect to host 10.0.0.10 port 22: Connection refused

الرفض، بدلًا من انقضاء المهلة في صمت، هو قرار reject الافتراضي لإجراء nftables يؤدي عمله — عليك أنت. أصلح الأمر كما في الخطوة 6: ارفع الحظر من جلسة على عنوان آخر غير محظور، أو من وحدة تحكم المزوّد — فالجلسة المفتوحة مسبقًا من العنوان المحظور تتجمد هي أيضًا. ثم أضف عنوانك إلى ignoreip حتى لا يتكرر ذلك.

Fail2ban يقول إن عنوانًا محظور، لكنه ما زال قادرًا على الاتصال. العداد في status sshd يرتفع، ومع ذلك ما زال العنوان يصل إلى المنفذ 22. هذا عدم تطابق بين إجراء الحظر وجدار الحماية، وعلى Ubuntu 24.04 يعني في الغالب الأعم أنك تجاوزت banaction = nftables العامل بقيمة banaction = iptables-multiport منقولة من دليل قديم، على جهاز لا توجد فيه طبقة iptables. يعرض fail2ban.log:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

احذف ذلك التجاوز ودع إجراء nftables الخاص بالحزمة قائمًا، أو — إن كنت تدير جدار الحماية كليًا عبر ufw وتريد أن يظهر الحظر هناك — فاضبط banaction = ufw في [DEFAULT]. أعد التشغيل وتأكد من ظهور القاعدة بالأمر sudo nft list ruleset | grep f2b.

Fail2ban يرفض البدء بعد تعديل jail.local. خطأ كتابي — ترويسة قسم شاردة أو قيمة زمنية خاطئة — يجعل الخدمة ترفض البدء. اطلب من Fail2ban فحص الإعدادات قبل تشغيله:

sudo fail2ban-client -t

يسمّي لك الملف والسجن موضع المشكلة، مثل Errors in jail 'sshd'. Skipping...، فتصلح المصدر بدلًا من التخمين.

FAQ

هل يحظر تثبيت Fail2ban الافتراضي على Ubuntu 24.04 هجمات SSH فعلًا؟

نعم. تأتي الحزمة بالملف /etc/fail2ban/jail.d/defaults-debian.conf الذي يفعّل سجن sshd، ويضبط backend = systemd ليقرأ من journal الخاص بـ systemd بدلًا من /var/log/auth.log الغائب، ويضبط banaction = nftables ليُنفَّذ الحظر عبر جدار الحماية الفعلي في Ubuntu. تنفيذ apt install fail2ban عادي يحمي SSH منذ أول إقلاع. تأكد من ذلك بالأمر sudo fail2ban-client status sshd وابحث عن قيمة Total failed غير صفرية.

لماذا لا يحظر Fail2ban أي شيء على جهازي؟

استبعد الأسباب الشائعة الثلاثة بالترتيب. فقد تكون تختبر من عنوان موجود في ignoreip، وهو معفى بحكم التصميم. وقد تكون تجاوزت الإعداد الافتراضي العامل بلصق backend = auto في jail.local من دليل قديم، وهو ما يعطّل قراءة الـ journal على صورة نظام بلا auth.log. أو قد تكون داخل حاوية لا يوجد فيها journal لـ systemd يُقرأ أصلًا. افحص Total failed في fail2ban-client status sshd: إن لم يرتفع أبدًا بينما يعرض journalctl -u ssh إخفاقات حقيقية، فالسجن يقرأ من المكان الخطأ.

كيف أرفع الحظر عن عنوان IP الخاص بي؟

نفّذ sudo fail2ban-client set sshd unbanip YOUR.IP.HERE، ويعيد 1 عند النجاح، أو sudo fail2ban-client unban --all لمسح كل الحظر. إن كنت محبوسًا خارج SSH، فاستخدم وحدة تحكم مزوّد الخدمة عبر الويب أو VNC لتنفيذ الأمر نفسه — فالحظر يرفض كل حزمة من عنوانك إلى المنفذ 22، حتى إن الجلسة التي كانت مفتوحة أصلًا تتوقف عن العمل. ثم أضف عنوانك إلى ignoreip حتى لا يتكرر الأمر.

ما الفرق بين jail.conf وjail.local؟

jail.conf يحمل القيم الافتراضية الأصلية لـ Fail2ban ويُستبدل مع كل ترقية للحزمة، فأي تعديل فيه ضائع في النهاية. حزمة Debian/Ubuntu تضيف إعداداتها فوقه عبر jail.d/defaults-debian.conf. أما تغييراتك فمكانها jail.local، الذي يُقرأ أخيرًا ويفوز على الاثنين، ولا تمسه الترقيات أبدًا. اترك jail.conf مرجعًا للقراءة فقط.

هل يغني Fail2ban عن مصادقة SSH بالمفاتيح؟

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