Ubuntu 24.04 वर Fail2ban कसे इन्स्टॉल करायचे

Fail2ban नेमके काय करते

Fail2ban हा एक log-reading daemon आहे. तो तुमचे SSH authentication messages पाहतो आणि एका ठराविक वेळेत एकाच address वरून काही वेळाने failures आढळल्यास, firewall command रन करतो ज्यामुळे तो address काही काळासाठी block होतो. हीच त्याची मुख्य संकल्पना आहे. एका file मध्ये सुमारे तीस lines ची config असते आणि Ubuntu 24.04 वर, काहीही edit करण्यापूर्वीच तुम्हाला सुरक्षित करण्यासाठी फक्त एक single apt command पुरेशी आहे.

ते काय आहे आणि काय नाही, हे स्पष्ट समजून घ्या. Fail2ban कोणालाही authenticate करत नाही, काहीही encrypt करत नाही आणि कोणताही एक determined login attempt थांबवू शकत नाही — ते फक्त एकाच source कडून वारंवार होणारे attempts थांबवते. हे एक noise filter आणि rate limiter आहे, lock नाही. port 22 वर होणारी सततची background scanning थांबवून तुमचा CPU, bandwidth आणि log space वाचवणे, आणि एका वेळी एकाच address वरून येणाऱ्या attacker चा वेग कमी करणे, हे त्याचे काम आहे.

Fail2ban कशाची जागा घेऊ शकत नाही

Fail2ban हा तिसरा स्तर (layer) आहे, पहिला नाही. जर तुमचा server अजूनही SSH passwords स्वीकारत असेल, तर हजारो addresses वर पसरलेले botnet सतत guesses करण्याचा प्रयत्न करू शकतात; कारण प्रत्येक address तुमच्या ban threshold च्या खाली राहते आणि तो threshold कधीही ओलांडत नाही. यावर खरा बचाव म्हणजे key-only authentication आहे, ज्यामुळे कोणीही कितीही attempts केले तरी password guessing अशक्य होते. key-only auth सोबत Fail2ban वापरण्याचे दोन फायदे आहेत: ते तुमच्या logs मधून brute-force noise काढून टाकते, आणि scanners ला लवकर बाहेर काढते जेणेकरून ते port वर हल्ला करणे थांबवतील. याला defence in depth म्हणून पहा. हे key authentication आणि firewall च्या मागे असते, त्यांच्या पुढे कधीही नसते.

Prerequisites, आणि Ubuntu 24.04 ची वास्तवता

तुम्हाला Ubuntu 24.04 चालवणाऱ्या VPS ची आवश्यकता आहे, ज्यामध्ये root किंवा sudo अधिकार आहेत आणि SSH कार्यरत आहे — शक्यतो key authentication सह. Fail2ban खूप कमी संसाधने वापरते: काही मेगाबाइट्स RAM लागते आणि कोणत्याही tuning ची गरज नसते.

आता एक महत्त्वाची गोष्ट, जी जुन्या मार्गदर्शिकांमध्ये चुकीची दिली जाते. अनेक वर्षे "Fail2ban इंस्टॉल करा, मग backend = systemd जोडा, कारण Ubuntu ने /var/log/auth.log लिहिणे बंद केले आहे" हा सल्ला standard होता. हा सल्ला एका खऱ्या बदलाचे वर्णन करतो — आधुनिक server आणि cloud images मध्ये rsyslog नसते, त्यामुळे SSH logs फक्त systemd journal मध्ये जातात आणि तो text file आता अस्तित्वात नाही — परंतु Ubuntu 24.04 वर Fail2ban package ने आधीच या बदलाचा विचार केला आहे. Package मध्ये /etc/fail2ban/jail.d/defaults-debian.conf समाविष्ट आहे, आणि upstream defaults ऐवजी तुमचा server प्रत्यक्षात हा file वापरतो:

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

[sshd]
enabled = true

हे काळजीपूर्वक वाचा, कारण काहीही करण्यापूर्वी हे दोन प्रश्नांची उत्तरे देते. backend = systemd मुळे SSH jail journal वाचते, त्यामुळे auth.log नसला तरी चालते. banaction = nftables मुळे bans nftables द्वारे लागू केले जातात, जे Ubuntu 24.04 मध्ये वापरले जाणारे firewall आहे, legacy iptables नाही. आणि [sshd] enabled = true मुळे first boot पासूनच jail सुरू असते. निष्कर्ष: Ubuntu 24.04 वरील stock apt install fail2ban मध्ये SSH brute-force साठी out of the box बंदी (bans) असते. तुमचे बहुतेक काम फक्त हे सुनिश्चित करणे, policy tune करणे आणि स्वतःला lock out करण्यापासून वाचवणे हे असेल.

जुना auth.log trap अजूनही तीन परिस्थितीत लागू होतो, ते ओळखणे आवश्यक आहे: तुम्ही Fail2ban apt ऐवजी pip ने इंस्टॉल केले आहे, ज्यामुळे defaults-debian.conf नाही; तुम्ही अशा unprivileged container मध्ये आहात जिथे systemd journal उपलब्ध नाही; किंवा तुम्ही जुन्या tutorial चे अनुसरण करून तुमच्या स्वतःच्या jail.local मध्ये backend = auto पेस्ट केले आहे, ज्यामुळे कार्यरत default बदलले गेले आहे. failure-modes विभाग प्रत्येक परिस्थितीचे तपशील सांगतो.

Step 1: Install and confirm it is already banning

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 मध्ये Fail2ban 1.0.2 येते. यामध्ये python3-systemd ही hard dependency म्हणून येते, त्यामुळे journal backend कडे सर्व आवश्यक गोष्टी उपलब्ध असतात. ही service आपोआप enable आणि start होते:

sudo systemctl status fail2ban

तुम्हाला active (running) हवे आहे. त्यानंतर, सध्या कार्यरत असलेली jail तपासा:

sudo fail2ban-client status sshd

जर public VPS काही मिनिटांपासून online असेल, तर तुम्हाला failures आणि banned addresses आधीच दिसू शकतात — कारण internet सतत port 22 scan करत असते. यामुळे stock config व्यवस्थित काम करत असल्याचे सिद्ध होते. आता तुम्हाला फक्त त्यात सुधारणा करायची आहे, ती शून्यापासून तयार करायची नाही.

Step 2: jail.local संपादित करा, jail.conf नाही

Fail2ban कडील मूळ (upstream) defaults /etc/fail2ban/jail.conf मध्ये असतात. तो file संपादित करू नका. Package मधील प्रत्येक apt upgrade तो file बदलू शकतो आणि तुमचे बदल कोणत्याही पूर्वसूचनांशिवाय निघून जाऊ शकतात. Fail2ban ठराविक क्रमाने files वाचते — प्रथम jail.conf, त्यानंतर jail.d/ मधील सर्व, आणि नंतर jail.local — आणि शेवटचे value प्रभावी ठरते. .local हा तुमचा file आहे आणि package upgrades तो कधीही बदलत नाहीत. हीच नियमावली filters साठी देखील लागू आहे, जिथे *.local file मधील settings मूळ filter.d/*.conf पेक्षा वरचढ ठरतात.

त्यामुळे, तुम्हाला आवश्यक असलेल्या मोजक्या settings साठी एक लहान jail.local लिहा आणि संदर्भ (reference) म्हणून jail.conf आणि packaged jail.d/defaults-debian.conf दोन्ही न बदलता तसेच ठेवा.

Step 3: /etc/fail2ban/jail.local लिहा

sudo nano /etc/fail2ban/jail.local

खालील मजकूर वापरा आणि ignoreip ओळीवरील IP पत्ता तुमच्या स्वतःच्या public 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 हे धोरण (policy) ठरवतात. डिफॉल्ट bantime फक्त 10 मिनिटे आहे; 1 तास हा अधिक सुरक्षित पर्याय आहे. 10 मिनिटांत एकाच address वरून 5 वेळा चुकीचा प्रयत्न झाल्यास ban लागू होईल. सामान्य वापरकर्ते 1-2 वेळा पासवर्ड चुकवू शकतात; परंतु 10 मिनिटांत 5 वेळा प्रयत्न करणे म्हणजे script आहे.
• ignoreip हे तुमचे सुरक्षा कवच आहे. तुम्ही ज्या public address वरून कनेक्ट होता, तो येथे टाका जेणेकरून Fail2ban तुम्हाला तुमच्या स्वतःच्या server मधून lock out करू शकणार नाही. जर तुमचा IP सतत बदलत असेल, तर शेवटी दिलेला VPN पर्याय वापरणे अधिक चांगले, परंतु ही ओळ वगळू नका.
• bantime.increment = true मुळे प्रत्येक subsequent ban ची वेळ वाढते — 1 तास, मग 2 तास, मग 4 तास — bantime.maxtime पर्यंत. वारंवार परत येणाऱ्या addresses ला हळूहळू अधिक वेळेसाठी lock out केले जाते.

ज्या machine वरून तुम्ही SSH करता, तिथून whitelist करण्यासाठी आवश्यक असलेला पत्ता शोधा, server वरून नाही:

curl -s ifconfig.me

तुम्ही तुमच्या ports आणि ban policy नुसार tuned केलेली jail.local येथे तयार करू शकता आणि ती फाईलमध्ये paste करू शकता:

Step 4: Restart and verify it is reading the journal

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

-t प्रथम एक config test रन करते, त्यामुळे jail.local मध्ये चूक असल्यास service बंद राहण्याऐवजी येथे लगेच त्रुटी (error) दर्शवली जाते. यशस्वी jail status खालीलप्रमाणे दिसतो:

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 खरोखर तुमचे logins वाचत आहे हे सिद्ध करणारा आकडा Total failed आहे. जर हा आकडा शून्यपेक्षा जास्त असेल, किंवा दुसऱ्या मशीनवरून लॉगिन करण्याचा प्रयत्न मुद्दाम अयशस्वी केल्यावर वाढत असेल, तर journal वाचले जात आहे आणि तुमचे काम पूर्ण झाले आहे. जर तुम्ही कितीही वेळा लॉगिन अयशस्वी करूनही तो 0 वरच राहत असेल — आणि तुम्ही ignoreip मधील address वरून टेस्ट करत नाही आहात याची खात्री असेल — तर खालील failure modes पहा.

Journal matches ओळीत अजूनही sshd.service असे नाव दिसत आहे याची नोंद घ्या. Ubuntu वर SSH unit प्रत्यक्षात ssh.service असते, परंतु shipped filter _COMM=sshd वर देखील मॅच होते, आणि OpenSSH 24.04 मध्ये failures sshd नावाच्या process मधून log होतात, त्यामुळे मॅचिंग यशस्वी होते. ही माहिती फक्त तुम्ही नवीन OpenSSH (9.8 किंवा त्यापुढील, जिथे per-connection worker sshd-session आहे) वापरत असल्यास महत्त्वाची ठरते; failure modes मध्ये त्या परिस्थितीचा समावेश आहे.

Step 5: प्रत्यक्ष ban पाहण्यासाठी किंवा चाचणीसाठी force ban करा

कोणत्याही public VPS वर काही मिनिटांत प्रत्यक्ष bans येतात. ते पाहण्यासाठी, log tail करा:

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

Ban असा दिसतो:

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

प्रतीक्षा न करता संपूर्ण यंत्रणा तपासण्यासाठी, मॅन्युअली एखादा documentation address ban करा — स्वतःचा address कधीही वापरू नका:

sudo fail2ban-client set sshd banip 10.0.0.66

हे 1 प्रिंट करते, आणि तो address fail2ban-client status sshd मधील Banned IP list अंतर्गत दिसतो. आता firewall मध्ये block खरोखर अस्तित्वात आहे याची खात्री करा. Ubuntu 24.04 वर तो nftables आहे, iptables नाही:

sudo nft list table inet f2b-table

तुम्हाला 10.0.0.66 असलेला addr-set-sshd नावाचा set आणि f2b-chain ही chain दिसेल, जी त्या set मधील कोणत्याही source ला reject करते. जर fail2ban-client मध्ये एखादा address ban असल्याचे दिसत असेल पण nft list मध्ये काहीही दिसत नसेल, तर तुमची ban action तुमच्या firewall शी मॅच होत नाही — failure modes मधील nftables/iptables टीप पहा.

Step 6: Unban yourself, and recover if you are locked out

If you banned an address you should not have — your own — remove it:

sudo fail2ban-client set sshd unbanip 10.0.0.66

It returns 1 on success. To clear every ban across every jail:

sudo fail2ban-client unban --all

Do not count on an already-open SSH session to save you: the nftables ban rejects every packet from the banned address to port 22 — established connections included — so an existing session freezes the moment the ban lands. If you ban yourself and have no ignoreip entry, you are locked out until the ban expires — recover through your provider's web console (VNC or serial), which does not go through SSH, and either wait out bantime or run the unban command there.

Step 7: Make bans persist and escalate

Fail2ban सक्रिय bans /var/lib/fail2ban/fail2ban.sqlite3 मधील एका लहान SQLite database मध्ये साठवते; यामुळे service restart किंवा reboot नंतरही bans कायम राहतात; ते नष्ट होत नाहीत. तुम्ही आधी जोडलेल्या bantime.increment ओळींमुळे वारंवार गुन्हा करणाऱ्यांसाठी समस्या वाढत जाते — बंदीचा कालावधी साधारणपणे एक तासापासून एक आठवड्यापर्यंत दुप्पट होत जातो.

याव्यतिरिक्त, संपूर्ण सिस्टमसाठी "three strikes" पॉलिसी लागू करण्यासाठी, Fail2ban मध्ये एक recidive jail असते. हे jail स्वतःच्या /var/log/fail2ban.log वर लक्ष ठेवते आणि सर्व jails मध्ये वारंवार प्रतिबंधित झालेल्या कोणत्याही address ला दीर्घकालीन बंदी घालते. तुमच्या [DEFAULT] मध्ये आता systemd backend वापरले जात असल्याने, या jail ला मूळ log file कडे निर्देशित करा:

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

logpath सह backend = auto वापरल्यामुळे recidive हे plain fail2ban.log वाचत राहते, जिथे Ban ओळी प्रत्यक्षात आढळतात — तुम्ही जागतिक स्तरावर (globally) सेट केलेले systemd default त्याला journal कडे निर्देशित करेल, जिथे या ओळी उपलब्ध नसतात.

Step 8: Key-only SSH आणि VPN चा वापर करा

Fail2ban चा पूर्ण फायदा घेण्यासाठी SSH मध्ये key authentication वापरणे आवश्यक आहे. /etc/ssh/sshd_config.d/ अंतर्गत, उदाहरणार्थ /etc/ssh/sshd_config.d/00-hardening.conf मध्ये, खालीलप्रमाणे सेट करा:

PasswordAuthentication no
KbdInteractiveAuthentication no

त्यानंतर sudo systemctl restart ssh करा. Password authentication बंद केल्यामुळे brute force हल्ले पूर्णपणे अयशस्वी ठरतात; अशा वेळी Fail2ban फक्त log noise कमी करण्यासाठी आणि scanners ला लवकर रोखण्यासाठी वापरता येते. अधिक सुरक्षिततेसाठी SSH ला सार्वजनिक इंटरनेटपासून पूर्णपणे वेगळे ठेवा: SSH ला self-hosted WireGuard VPN च्या मागे ठेवा आणि firewall port 22 बंद करा, जेणेकरून तो फक्त tunnel वरून प्रतिसाद देईल. ज्या port ला कोणीही पोहोचू शकत नाही, त्यावर brute-force हल्ला करणे अशक्य आहे; अशा वेळी Fail2ban ही पहिली सुरक्षा यंत्रणा न राहता एक अतिरिक्त सुरक्षा (backstop) म्हणून काम करते.

Fail2ban फक्त SSH साठी नाही. ज्या कोणत्याही service मध्ये failed logins चे logs असतात, तिथे तुम्ही jail वापरू शकता — जसे की mail server, nginx site, किंवा self-hosted Vaultwarden password manager ज्याचा web login तुम्हाला credential stuffing हल्ल्यांपासून सुरक्षित ठेवायचा आहे. एकदा का एखादे web app Let's Encrypt certificate असलेल्या nginx site च्या मागे आले की, SSH jail प्रमाणेच Fail2ban filter त्याच्या access log कडे निर्देशित करा.

Failure modes, with the exact strings you will see

"Have not found any log file for sshd jail", आणि Fail2ban सुरू होत नाही. ही जुनी auth.log समस्या आहे. Ubuntu 24.04 वर, जर तुम्ही पॅकेजमधील default settings बदलली असतील, तरच ही समस्या येते — जसे की defaults-debian.conf शिवाय pip install करणे, journal शिवाय container वापरणे, किंवा jail.local मध्ये चुकीचा backend = auto पेस्ट करणे. जर file backend मध्ये /var/log/auth.log नसेल, तर sshd jail ला त्याचा log सापडत नाही आणि संपूर्ण daemon बंद पडते. fail2ban.log मध्ये असे दिसते:

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

ही error fatal असल्यामुळे service सुरू होत नाही, आणि त्यानंतर fail2ban-client status खालीलप्रमाणे symptom दाखवते:

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

"socket path" ही ओळ Fail2ban खराब झाल्याचे दर्शवत नाही — याचा अर्थ असा आहे की एखादे jail त्याचा log शोधू शकले नाही म्हणून ते सुरूच झाले नाही. [DEFAULT] मध्ये backend = systemd सेट केल्यास (जे Ubuntu package आधीच तुमच्यासाठी करते), दोन्ही messages सुटतात.

Jail active आहे पण Total failed वाढत नाही. Daemon सुरू आहे आणि journal वाचले जात आहे, तरीही journalctl -u ssh मध्ये failures जमा होत आहेत पण counter 0 वरच स्थिर आहे. प्रथम स्पष्ट गोष्टी तपासा: तुम्ही ignoreip मध्ये नमूद केलेल्या address वरून test करत आहात, त्यामुळे तुमचे स्वतःचे failures मुद्दाम वगळले जातात. जर तसे नसेल, तर तुम्ही OpenSSH च्या अशा build वर आहात जिथे per-connection worker sshd-session (9.8 आणि नंतरचे) आहे, ज्याचा journal _COMM हा sshd-session आहे, sshd नाही, त्यामुळे shipped match ते शोधू शकत नाही. [sshd] block मध्ये match विस्तारून पहा:

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

Restart करा, ignoreip मध्ये नसलेल्या address वरून मुद्दाम login fail करण्याचा प्रयत्न करा, आणि Total failed वाढल्याची खात्री करा.

तुम्ही स्वतःलाच ban केले आहे: Connection refused. तुम्ही तुमचे स्वतःचे address ignoreip मधून वगळले, काही चुकीचे logins test केले आणि आता:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Timeout मिळण्याऐवजी refusal मिळणे, हे nftables action चा default reject verdict आहे जे तुमच्यावर लागू झाले आहे. Step 6 प्रमाणे ते fix करा: दुसऱ्या, unbanned address वरून किंवा provider console मधून session सुरू करून unban करा — banned address वरून आधीच सुरू असलेले session freeze होते. त्यानंतर तुमचे address ignoreip मध्ये जोडा जेणेकरून हे पुन्हा घडणार नाही.

Fail2ban सांगते की address banned आहे, पण तरीही कनेक्शन होते. status sshd मधील counter वाढत आहे, तरीही address अजूनही port 22 ला पोहोचू शकते. ही ban-action-versus-firewall mismatch ची समस्या आहे. Ubuntu 24.04 वर, याचा अर्थ असा आहे की तुम्ही iptables layer नसलेल्या system वर जुन्या guide मधून घेतलेले banaction = iptables-multiport वापरून कार्यरत banaction = nftables बदलले आहे. fail2ban.log मध्ये असे दिसते:

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

ते override काढून टाका आणि packaged nftables action वापरू द्या, किंवा जर तुम्ही firewall पूर्णपणे ufw द्वारे मॅनेज करत असाल आणि bans तिथे दाखवू इच्छित असाल, तर [DEFAULT] मध्ये banaction = ufw सेट करा. Restart करा आणि sudo nft list ruleset | grep f2b वापरून rule आल्याची खात्री करा.

jail.local edit केल्यानंतर Fail2ban सुरू होत नाही. एखादी typo — चुकीचे heading किंवा चुकीचे time value — service सुरू होण्यापासून रोखते. Fail2ban सुरू होण्यापूर्वी config तपासायला सांगा:

sudo fail2ban-client -t

हे समस्याग्रस्त file आणि jail चे नाव सांगते, उदाहरणार्थ Errors in jail 'sshd'. Skipping..., ज्यामुळे तुम्हाला अंदाज लावण्याऐवजी थेट मूळ चूक दुरुस्त करता येते.

FAQ

Ubuntu 24.04 वरील stock Fail2ban install SSH attacks वर खरोखर ban करते का?

हो. या package मध्ये /etc/fail2ban/jail.d/defaults-debian.conf असते, जे sshd jail सक्षम करते, backend = systemd सेट करते जेणेकरून ते /var/log/auth.log ऐवजी systemd journal वाचू शकेल, आणि banaction = nftables सेट करते जेणेकरून bans Ubuntu च्या real firewall द्वारे लागू होतील. पहिल्या boot पासून SSH सुरक्षित ठेवण्यासाठी साधी apt install fail2ban वापरली जाते. sudo fail2ban-client status sshd द्वारे याची खात्री करा आणि Total failed ची किंमत zero पेक्षा जास्त आहे का ते तपासा.

माझ्या system वर Fail2ban काहीही ban का करत नाहीये?

खालील तीन सामान्य कारणांची क्रमाने तपासणी करा. तुम्ही ignoreip मधील address मधून test करत असाल, जे design नुसार exempt आहे. तुम्ही जुन्या guide मधून jail.local मध्ये backend = auto paste केल्यामुळे default settings बदलली असावीत, ज्यामुळे ज्या image मध्ये auth.log नाही तिथे journal reading fail होते. किंवा तुम्ही अशा container मध्ये असाल जिथे वाचण्यासाठी systemd journal उपलब्ध नाही. fail2ban-client status sshd मध्ये Total failed तपासा: जर journalctl -u ssh मध्ये real failures दिसत असतानाही त्याची किंमत वाढत नसेल, तर jail चुकीची जागा वाचत आहे.

मी माझा स्वतःचा IP address कसा unban करू शकतो?

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE चालवा, जे यशस्वी झाल्यास 1 देते, किंवा सर्व bans clear करण्यासाठी sudo fail2ban-client unban --all वापरा. जर तुम्ही SSH मधून lock-out झाला असाल, तर तुमच्या provider च्या web किंवा VNC console चा वापर करून तीच command चालवा — ban मुळे तुमच्या address कडून port 22 वर येणारे सर्व packets reject होतात, त्यामुळे आधीच open असलेले session देखील काम करणे थांबवते. त्यानंतर, पुन्हा असे होऊ नये म्हणून तुमचा address ignoreip मध्ये जोडा.

jail.conf आणि jail.local मधील फरक काय आहे?

jail.conf मध्ये Fail2ban चे upstream defaults असतात आणि प्रत्येक package upgrade मध्ये ते overwrite केले जातात, त्यामुळे तिथे केलेले कोणतेही edit नंतर निघून जाते. Debian/Ubuntu package jail.d/defaults-debian.conf द्वारे स्वतःची settings layer करते. तुमचे बदल jail.local मध्ये असावेत, जे सर्वात शेवटी वाचले जाते आणि दोन्ही settings वर प्रभावी ठरते, तसेच upgrade मध्ये त्यात बदल होत नाहीत. jail.conf ला फक्त reference म्हणून read-only ठेवा.

Fail2ban, key-based SSH authentication ची जागा घेते का?

नाही. Fail2ban एका address कडून होणारे वारंवारचे failures rate-limit करते; परंतु जर प्रत्येक address threshold च्या खाली असेल, तर ते distributed guessing च्या विरोधात काहीही करू शकत नाही. Key-only authentication (PasswordAuthentication no) मुळे password guessing पूर्णपणे अशक्य होते, आणि Fail2ban log noise कमी करते आणि scanners ला लवकर बाहेर काढते. दोन्ही वापरा आणि शक्य असल्यास SSH पूर्णपणे public internet वरून बंद ठेवा.