התקנת Fail2ban ב-Ubuntu 24.04: חסימת בוטים ב-SSH

מה Fail2ban עושה בפועל

Fail2ban הוא daemon שקורא קובצי לוג. הוא מנטר את הודעות האימות של SSH, ולאחר מספר ניסיונות כושלים מכתובת אחת בתוך חלון זמן קצר, הוא מריץ פקודת firewall שחוסמת את אותה כתובת לזמן מה. זהו כל הרעיון. מדובר בכ-30 שורות הגדרה בקובץ אחד, וב-Ubuntu 24.04 ההתקנה היא פקודת apt אחת שמשאירה אתכם מוגנים עוד לפני שערכתם דבר.

היו ברורים לגבי מהו הכלי ומה הוא לא. Fail2ban אינו מאמת אף אחד, אינו מצפין דבר, ואינו עוצר ניסיון התחברות נחוש בודד, אלא רק ניסיונות חוזרים מאותו מקור. זהו מסנן רעשים ומגביל קצב (rate limiter), לא מנעול. תפקידו הוא לגרום לסריקה הבלתי פוסקת של פורט 22 ברקע להפסיק לבזבז את ה-CPU, את רוחב הפס ואת שטח הלוגים שלכם, ולהאט כל תוקף שנאלץ להגיע מכתובת אחת בכל פעם.

מה Fail2ban אינו מחליף

Fail2ban הוא שכבת ההגנה השלישית, לא הראשונה. אם השרת שלכם עדיין מקבל סיסמאות עבור SSH, רשת בוטים (botnet) הפרוסה על פני אלפי כתובות יכולה להמשיך ולנחש, כיוון שכל כתובת נשארת מתחת לסף החסימה שלכם ולעולם לא מפעילה אותה. ההגנה האמיתית מפני מצב זה היא אימות מבוסס מפתחות בלבד (key-only authentication), שהופך ניחוש סיסמאות לבלתי אפשרי, ללא קשר למספר הניסיונות. Fail2ban, כשהוא מופעל מעל אימות מבוסס מפתחות, מבצע שתי פעולות מועילות: הוא מסנן את הרעש של ניסיונות ה-brute-force מתוך הלוגים שלכם, ומסלק סורקים בשלב מוקדם כדי שיפסיקו להפציץ את הפורט. התייחסו אליו כאל הגנה רב-שכבתית (defence in depth). הוא יושב מאחורי אימות מבוסס מפתחות ומאחורי firewall, לעולם לא לפניהם.

דרישות קדם, והמציאות ב-Ubuntu 24.04

אתם זקוקים ל-VPS המריץ Ubuntu 24.04 עם גישת root או sudo, וחיבור SSH פעיל, רצוי מבוסס אימות מפתחות. Fail2ban הוא שירות חסכוני: הוא צורך עשרות בודדות של מגה-בייטים של RAM, ואינו דורש כוונון של מגבלות.

כעת לחלק שרוב המדריכים הישנים טועים בו. במשך שנים ההמלצה הסטנדרטית הייתה "התקינו את Fail2ban, ואז הוסיפו את backend = systemd, כיוון ש-Ubuntu הפסיקה לכתוב ל-/var/log/auth.log." המלצה זו מתארת שינוי אמיתי; תמונות שרת וענן מודרניות מופצות ללא rsyslog, לכן SSH מתעד רק ל-systemd journal וקובץ הטקסט ההוא אינו קיים. עם זאת, ב-Ubuntu 24.04 חבילת Fail2ban כבר לוקחת זאת בחשבון. החבילה מתקינה את /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, שהוא ה-firewall ש-Ubuntu 24.04 משתמשת בו בפועל, במקום ה-iptables המיושן. ו-[sshd] enabled = true אומר שה-jail פעיל מהאתחול הראשון. השורה התחתונה: התקנה סטנדרטית של apt install fail2ban ב-Ubuntu 24.04 חוסמת התקפות brute-force על SSH מהרגע הראשון. רוב העבודה שלכם היא אימות פעולה זו, כוונון המדיניות, ווידוא שלא תנעלו את עצמכם מחוץ לשרת.

המלכודת הישנה של auth.log עדיין גורמת לבעיות בשלושה מצבים, וכדאי להכיר אותם: התקנתם את Fail2ban עם pip במקום apt, ולכן אין defaults-debian.conf; אתם נמצאים בתוך container ללא הרשאות שאין לו systemd journal לקריאה; או שעקבתם אחרי מדריך ישן והדבקתם את backend = auto לתוך ה-jail.local שלכם, ובכך דרסתם את ברירת המחדל התקינה. סעיף מצבי הכשל מראה בדיוק איך כל אחד מהם נראה.

שלב 1: התקנה ואימות פעולת החסימה

sudo apt update
sudo apt install -y fail2ban

הפצה של Ubuntu 24.04 כוללת את Fail2ban בגרסה 1.0.2, והחבילה מושכת את python3-systemd כתלות הכרחית, כך שלמנגנון ה-journal יש את כל הדרוש לו. השירות מופעל ומתחיל לעבוד באופן אוטומטי:

sudo systemctl status fail2ban

יש להריץ את active (running). לאחר מכן, בדקו את ה-jail שכבר מבצע את עבודתו:

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 שייך לכם, ושדרוגי חבילות לעולם לא נוגעים בו. אותו כלל חל על מסננים (filters), שבהם קובץ *.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. כתובות שממשיכות לנסות להתחבר נחסמות לזמן הולך וגדל.

מצאו את הכתובת להחרגה (whitelist) מהמחשב שממנו אתם מבצעים את ה-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 תגרום לכשל גלוי כבר בשלב זה, במקום להשאיר את השירות מושבת. סטטוס תקין של jail נראה כך:

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, אך ה-filter שמגיע עם התוכנה תואם גם ל-_COMM=sshd, ו-OpenSSH בגרסה 24.04 מתעד את הכשלים שלו מתהליך בשם sshd, לכן ההתאמה עובדת. פרט זה רלוונטי רק אם אתם משתמשים בגרסת OpenSSH חדשה יותר (9.8 ומעלה, שבה תהליך ה-worker לכל חיבור הוא 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. כעת אשרו שהחסימה אכן קיימת ב-firewall. ב-Ubuntu 24.04 המערכת היא nftables, ולא iptables:

sudo nft list table inet f2b-table

אתם תראו קבוצה (set) בשם addr-set-sshd המכילה את 10.0.0.66, ושרשרת (chain) בשם f2b-chain הדוחה כל מקור שנמצא בקבוצה זו. אם fail2ban-client מדווח שכתובת חסומה אך היא אינה מופיעה ב-nft list, פעולת החסימה שלכם אינה תואמת ל-firewall המוגדר; עיינו בהערת ה-nftables/iptables תחת סעיף כשלי המערכת.

שלב 6: ביטול חסימה עצמית ושחזור גישה במקרה של נעילה

אם חסמת כתובת שלא היית אמור לחסום, כולל הכתובת שלך, הסר אותה:

sudo fail2ban-client set sshd unbanip 10.0.0.66

הפקודה מחזירה 1 עם הצלחה. כדי לנקות את כל החסימות מכל ה-jails:

sudo fail2ban-client unban --all

אל תסתמך על סשן SSH פתוח שיציל אותך: חסימת ה-nftables דוחה כל חבילה מהכתובת החסומה לפורט 22, כולל חיבורים קיימים, לכן סשן פעיל יקפא ברגע שהחסימה תיכנס לתוקף. אם חסמת את עצמך ואין לך רשומת ignoreip, תינעל מחוץ לשרת עד לפקיעת החסימה. שחזר גישה דרך מסוף הניהול של ספק הענן (VNC או serial), שאינו עובר דרך SSH, והמתן עד לסיום ה-bantime או הרץ שם את פקודת ביטול החסימה.

שלב 7: הפיכת חסימות לקבועות והסלמתן

Fail2ban שומר חסימות פעילות בבסיס נתונים קטן מסוג SQLite בנתיב /var/lib/fail2ban/fail2ban.sqlite3, כך שהן שורדות הפעלה מחדש של השירות או אתחול של השרת; החסימות אינן הולכות לאיבוד. השורות bantime.increment שהוספת כבר הופכות כל עבריין סדרתי לבעיה מחמירה עבור עצמו, כאשר זמן החסימה מוכפל בערך משעה אחת ועד לשבוע.

עבור מדיניות "שלוש פסילות" מערכתית בנוסף לכך, Fail2ban מספק jail בשם recidive שעוקב אחר ה-/var/log/fail2ban.log שלו ומטיל חסימות ארוכות על כל כתובת שנחסמה שוב ושוב בכל ה-jails. מכיוון שה-[DEFAULT] שלך משתמש כעת ב-backend של systemd, עליך להפנות את ה-jail הזה בחזרה לקובץ הלוג שהוא נועד לקרוא:

[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. כאשר סיסמאות מנוטרלות, התקפות brute force לא יכולות להצליח כלל; Fail2ban משמש במקרה זה להפחתת רעש בלוגים ולחסימה מוקדמת של סורקים. פתרון חזק עוד יותר הוא להרחיק את SSH לחלוטין מהאינטרנט הציבורי: הציבו את SSH מאחורי שרת WireGuard VPN עצמאי וחסמו את פורט 22 ב-firewall כך שיגיב רק דרך ה-tunnel. איש אינו יכול לבצע brute force לפורט שאינו נגיש עבורו, ו-Fail2ban הופך לקו הגנה אחורי במקום לקו חזית.

Fail2ban אינו מיועד רק ל-SSH. כל שירות שמתעד כניסות כושלות יכול לקבל jail, בין אם מדובר בשרת דואר, אתר Nginx, או מנהל סיסמאות Vaultwarden עצמאי שאינכם מעוניינים להשאיר את ממשק הכניסה שלו חשוף ל-credential stuffing. ברגע שיישום אינטרנט נמצא מאחורי אתר Nginx עם תעודת Let's Encrypt, כוונו מסנן (filter) של Fail2ban אל ה-access log שלו, באותו אופן שבו ה-jail של SSH מופנה אל ה-journal.

מצבי כשל והודעות השגיאה המדויקות

"Have not found any log file for sshd jail", ו־Fail2ban מסרב לעלות. זוהי בעיית auth.log ישנה. בגרסת Ubuntu 24.04 תיתקלו בה רק אם משהו דרס את הגדרות ברירת המחדל של החבילה, אם מדובר בהתקנת pip ללא defaults-debian.conf, במכולה (container) ללא journal, או ב־backend = auto מיותר שהודבק לתוך jail.local. בשימוש ב-backend של קבצים ללא /var/log/auth.log, ה-jail של sshd לא מוצא את קובץ הלוג וה-daemon כולו קורס. הפקודה 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, אלא על כך שהוא לא עלה כי אחד ה-jails לא מצא את הלוג שלו. הגדרת backend = systemd בתוך [DEFAULT], מה שחבילת ה-Ubuntu כבר עושה עבורכם, פותרת את שתי ההודעות בו-זמנית.

ה-jail פעיל אך Total failed לא משתנה. ה-daemon רץ וה-journal נקרא, אך כשלים אמיתיים מצטברים ב-journalctl -u ssh בעוד המונה נשאר על 0. ראשית, שללו את המובן מאליו: אתם בודקים מכתובת שמופיעה ב-ignoreip, ולכן הכשלים שלכם מוחרגים כחלק מהתכנון. אם לא זו הבעיה, אתם משתמשים בגרסת OpenSSH שבה ה-worker של כל חיבור הוא sshd-session (גרסה 9.8 ומעלה), שבה ה-journal _COMM הוא sshd-session ולא sshd, ולכן תבנית ההתאמה המובנית מפספסת אותו. הרחיבו את ההתאמה בבלוק ה-[sshd]:

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

בצעו restart, נסו להיכשל בכניסה בכוונה מכתובת שאינה ב-ignoreip, וודאו ש-Total failed אכן עולה.

חסמתם את עצמכם: Connection refused. השארתם את הכתובת שלכם מחוץ ל-ignoreip, בדקתם כמה כניסות שגויות, ועכשיו:

ssh: connect to host 10.0.0.10 port 22: Connection refused

הסירוב, במקום timeout שקט, הוא תוצאה של ה-verdict המוגדר כ-reject ב-nftables שעושה את עבודתו עליכם. תקנו זאת כפי שמתואר בשלב 6: בטלו את החסימה (unban) מסשן בכתובת אחרת שלא נחסמה, או דרך ה-console של ספק השרתים; סשן שכבר פתוח מהכתובת החסומה יקפא גם הוא. לאחר מכן הוסיפו את הכתובת שלכם ל-ignoreip כדי שזה לא יקרה שוב.

Fail2ban מדווח שכתובת חסומה, אך היא עדיין מצליחה להתחבר. המונה ב-status sshd עולה, אך הכתובת עדיין מגיעה לפורט 22. מדובר בחוסר התאמה בין ה-ban-action לבין ה-firewall. ב-Ubuntu 24.04 זה כמעט תמיד אומר שדרסתם את ה-banaction = nftables התקין עם banaction = iptables-multiport שהועתק ממדריך ישן, על שרת ללא שכבת iptables. הפקודה fail2ban.log תציג:

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

מחקו את הדריסה הזו ואפשרו ל-action המובנה nftables לעבוד, או, אם אתם מנהלים את ה-firewall במלואו דרך ufw ורוצים שהחסימות יופיעו שם, הגדירו banaction = ufw ב-[DEFAULT]. בצעו restart וודאו שהחוק מופיע בעזרת sudo nft list ruleset | grep f2b.

Fail2ban לא עולה לאחר עריכת jail.local. שגיאת הקלדה, כותרת מיותרת או ערך זמן שגוי גורמים לשירות לסרב לעלות. בקשו מ-Fail2ban לבדוק את התצורה לפני ההרצה:

sudo fail2ban-client -t

הוא יציין את הקובץ ואת ה-jail הבעייתי, למשל Errors in jail 'sshd'. Skipping..., כך שתוכלו לתקן את המקור במקום לנחש.

FAQ

האם התקנת ברירת המחדל של Fail2ban ב-Ubuntu 24.04 אכן חוסמת התקפות SSH?

כן. החבילה כוללת את /etc/fail2ban/jail.d/defaults-debian.conf, המפעיל את ה-jail מסוג sshd, מגדיר את backend = systemd כך שיקרא את ה-systemd journal במקום את /var/log/auth.log החסר, ומגדיר את banaction = nftables כך שהחסימות ייאכפו דרך ה-firewall המובנה של Ubuntu. התקנה נקייה של apt install fail2ban מגנה על SSH כבר מה-boot הראשון. ניתן לאמת זאת באמצעות sudo fail2ban-client status sshd ולחפש ערך שאינו אפס ב-Total failed.

מדוע Fail2ban לא חוסם שום דבר בשרת שלי?

יש לשלול את שלוש הסיבות הנפוצות לפי הסדר. ייתכן שאתם בודקים מכתובת הנמצאת ב-ignoreip, הפטורה מחסימה כברירת מחדל. ייתכן שדרסתם את הגדרות ברירת המחדל התקינות על ידי העתקת backend = auto לתוך jail.local ממדריך ישן, מה שמשבש את קריאת ה-journal במערכת שבה אין auth.log. לחלופין, ייתכן שאתם נמצאים בתוך container שאין בו כלל systemd journal לקריאה. בדקו את Total failed בתוך fail2ban-client status sshd: אם הערך לא עולה בזמן ש-journalctl -u ssh מציג כשלים אמיתיים, ה-jail קורא מהמקום הלא נכון.

איך אוכל לבטל חסימה של כתובת ה-IP שלי?

הריצו את sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, שיחזיר 1 במקרה של הצלחה, או את sudo fail2ban-client unban --all כדי לנקות את כל החסימות. אם ננעלתם מחוץ ל-SSH, השתמשו ב-console של ספק השרת או ב-VNC כדי להריץ את אותה פקודה; החסימה דוחה כל חבילת מידע מהכתובת שלכם לפורט 22, כך שגם session שהיה פתוח יפסיק לעבוד. לאחר מכן, הוסיפו את הכתובת שלכם ל-ignoreip כדי למנוע הישנות של המקרה.

מה ההבדל בין jail.conf לבין jail.local?

jail.conf מכיל את הגדרות ברירת המחדל של Fail2ban ונדרס בכל עדכון חבילה, לכן כל עריכה בו תלך לאיבוד בסופו של דבר. חבילות Debian/Ubuntu מוסיפות את ההגדרות שלהן מעל באמצעות jail.d/defaults-debian.conf. השינויים שלכם צריכים להתבצע ב-jail.local, שנקרא אחרון וגובר על שניהם, ושאותו עדכונים לעולם לא משנים. השאירו את jail.conf כקובץ לעיון בלבד.

האם Fail2ban מחליף אימות SSH מבוסס מפתחות?

לא. Fail2ban מבצע הגבלת קצב (rate-limit) לניסיונות כושלים חוזרים מאותה כתובת; הוא אינו מגן מפני ניחוש איטי ומבוזר שבו כל כתובת נשארת מתחת לסף החסימה. אימות מבוסס מפתחות בלבד (PasswordAuthentication no) הופך ניחוש סיסמאות לבלתי אפשרי מיסודו, ו-Fail2ban משמש במקרה זה לצמצום רעש בלוגים והרחקת סורקים בשלב מוקדם. מומלץ להשתמש בשניהם, ובאופן אידיאלי, להשאיר את ה-SSH מחוץ לאינטרנט הציבורי לחלוטין.