Fail2ban auf Ubuntu 24.04 gegen SSH-Bots einrichten

Was Fail2ban tatsächlich tut

Fail2ban ist ein Daemon, der Logs auswertet. Er überwacht Ihre SSH-Authentifizierungsnachrichten. Nach mehreren Fehlversuchen von einer Adresse innerhalb eines kurzen Zeitfensters führt er einen Firewall-Befehl aus, der diese Adresse vorübergehend sperrt. Das ist das gesamte Prinzip. Die Konfiguration umfasst in einer Datei etwa 30 Zeilen. Unter Ubuntu 24.04 erfolgt die Installation mit einem einzigen apt-Befehl. Danach sind Sie geschützt, ohne zuvor etwas bearbeiten zu müssen.

Machen Sie sich klar, was Fail2ban ist und was es nicht ist. Fail2ban authentifiziert niemanden, verschlüsselt nichts und verhindert keinen einzelnen gezielten Anmeldeversuch. Es unterbindet nur wiederholte Versuche von derselben Quelle. Fail2ban ist ein Filter gegen Störungen und begrenzt die Rate, aber es ist keine Sperre. Seine Aufgabe besteht darin, das ständige Scannen von Port 22 im Hintergrund zu unterbinden, damit es keine CPU-Zeit, Netzwerkbandbreite und Log-Speicher mehr verschwendet. Außerdem verlangsamt Fail2ban Angreifer, die jeweils von nur einer Adresse aus vorgehen können.

Was Fail2ban nicht ersetzt

Fail2ban ist die dritte Schutzschicht, nicht die erste. Wenn Ihr Server weiterhin SSH-Passwörter akzeptiert, kann ein Botnet mit Tausenden von Adressen das Raten fortsetzen, weil jede Adresse unter Ihrem Schwellenwert für Sperren bleibt und diesen nie überschreitet. Die eigentliche Abwehr dagegen ist die schlüsselbasierte Authentifizierung. Damit ist das Erraten von Passwörtern unabhängig von der Anzahl der Versuche unmöglich. Fail2ban bietet zusätzlich zur schlüsselbasierten Authentifizierung zwei wichtige Funktionen: Es reduziert das Brute-Force-Rauschen in Ihren Logs und entfernt Scanner frühzeitig, damit sie den Port nicht weiter mit Anfragen belasten. Betrachten Sie Fail2ban als mehrschichtige Abwehr. Es steht hinter der Schlüsselauthentifizierung und hinter einer Firewall, niemals davor.

Voraussetzungen und die Realität unter Ubuntu 24.04

Sie benötigen einen VPS mit Ubuntu 24.04, root- oder sudo-Zugriff sowie eine bereits funktionierende SSH-Verbindung, idealerweise mit Schlüsselauthentifizierung. Fail2ban ist genügsam: Es benötigt einige Dutzend Megabyte RAM. Eine Anpassung von Limits ist nicht erforderlich.

Hier liegt der Punkt, den ältere Anleitungen regelmäßig falsch darstellen. Jahrelang lautete die Standardempfehlung: „Installieren Sie Fail2ban und fügen Sie anschließend backend = systemd hinzu, weil Ubuntu nicht mehr in /var/log/auth.log schreibt.“ Diese Empfehlung beschreibt zwar eine tatsächliche Änderung: Moderne Server- und Cloud-Images werden ohne rsyslog ausgeliefert. SSH schreibt dann nur noch in das systemd-Journal, und die Textdatei fehlt. Unter Ubuntu 24.04 berücksichtigt das Fail2ban-Paket diesen Umstand jedoch bereits. Das Paket installiert /etc/fail2ban/jail.d/defaults-debian.conf. Diese Datei legt fest, was auf Ihrem Server tatsächlich ausgeführt wird, nicht die Voreinstellungen des Upstream-Projekts:

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

[sshd]
enabled = true

Lesen Sie diese Konfiguration sorgfältig. Sie klärt zwei Fragen, bevor Sie Änderungen vornehmen. backend = systemd bedeutet, dass das SSH-Jail das Journal liest. Das fehlende auth.log spielt daher keine Rolle. banaction = nftables bedeutet, dass Sperren über nftables umgesetzt werden. Das ist die Firewall, die Ubuntu 24.04 tatsächlich verwendet, und nicht das veraltete iptables. [sshd] enabled = true bedeutet außerdem, dass das Jail bereits beim ersten Systemstart aktiviert ist. Das Ergebnis: Ein unverändertes apt install fail2ban sperrt unter Ubuntu 24.04 SSH-Brute-Force-Angriffe standardmäßig. Ihre wichtigste Aufgabe besteht darin, dies zu überprüfen, die Richtlinie anzupassen und sicherzustellen, dass Sie sich nicht selbst aussperren.

Die alte auth.log-Falle tritt weiterhin in drei Situationen auf. Es lohnt sich, diese zu kennen: Sie haben Fail2ban mit pip statt mit apt installiert, sodass defaults-debian.conf nicht vorhanden ist; Sie befinden sich in einem nicht privilegierten Container ohne auslesbares systemd-Journal; oder Sie haben eine alte Anleitung befolgt und backend = auto in Ihre eigene jail.local kopiert, wodurch die funktionierende Standardeinstellung überschrieben wurde. Der Abschnitt zu den Fehlerbildern zeigt genau, wie die einzelnen Fälle aussehen.

Schritt 1: Installieren und bestätigen, dass bereits Sperren erfolgen

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 enthält Fail2ban 1.0.2. Das Paket zieht python3-systemd als feste Abhängigkeit nach. Das Journal-Backend verfügt damit über alle erforderlichen Komponenten. Der Dienst wird automatisch aktiviert und gestartet:

sudo systemctl status fail2ban

Erwartet wird active (running). Prüfen Sie anschließend das Jail, das bereits seine Aufgabe erfüllt:

sudo fail2ban-client status sshd

Auf einem öffentlichen VPS sehen Sie oft schon nach wenigen Minuten, dass Fehlversuche gezählt und Adressen gesperrt wurden. Das Internet scannt Port 22 kontinuierlich. Das belegt, dass die Standardkonfiguration funktioniert. Von hier aus verfeinern Sie sie, statt sie von Grund auf neu aufzubauen.

Schritt 2: jail.local bearbeiten, niemals jail.conf

Fail2ban speichert die Upstream-Standardwerte in /etc/fail2ban/jail.conf. Bearbeiten Sie diese Datei nicht. Jede apt upgrade des Pakets kann sie ersetzen, und Ihre Änderungen gehen ohne Warnung verloren. Fail2ban liest die Dateien in einer festen Reihenfolge: zuerst jail.conf, dann alle Dateien in jail.d/, anschließend jail.local. Der letzte Wert hat Vorrang. Die Datei .local gehört Ihnen, und Paketaktualisierungen ändern sie nie. Die gleiche Regel gilt für Filter: Eine Datei *.local überschreibt die mitgelieferte Datei filter.d/*.conf.

Legen Sie daher eine kleine jail.local an, die nur die wenigen benötigten Einstellungen überschreibt. Lassen Sie sowohl jail.conf als auch die mitgelieferte jail.d/defaults-debian.conf unverändert und verwenden Sie sie als Referenz.

Schritt 3: /etc/fail2ban/jail.local schreiben

sudo nano /etc/fail2ban/jail.local

Fügen Sie dies ein. Ersetzen Sie dabei die Adresse in der Zeile ignoreip durch Ihre eigene öffentliche IP-Adresse:

[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

Jede Zeile hat einen Zweck:

• bantime, findtime und maxretry legen die Richtlinie fest. Der mitgelieferte Standardwert bantime beträgt nur zehn Minuten. Eine Stunde ist als Mindestwert sinnvoller. Fünf Fehlversuche von einer Adresse innerhalb von zehn Minuten führen zur Sperre. Menschen geben ein Passwort ein- oder zweimal falsch ein. Fünf Fehlversuche in zehn Minuten sind ein Skript.
• ignoreip ist Ihre Sicherheitsvorkehrung. Tragen Sie hier die öffentliche Adresse ein, von der aus Sie eine Verbindung herstellen, damit Fail2ban Sie niemals von Ihrem eigenen Server aussperren kann. Eine Heimverbindung mit wechselnder IP-Adresse ist ein Grund, den VPN-Ansatz am Ende zu bevorzugen, nicht diese Zeile zu überspringen.
• bantime.increment = true verlängert jede erneute Sperre gegenüber der vorherigen: zunächst eine Stunde, dann zwei, dann vier, bis zu bantime.maxtime. Adressen, die wiederholt zurückkehren, werden schrittweise länger gesperrt.

Ermitteln Sie die freizugebende Adresse auf dem Rechner, von dem aus Sie eine SSH-Verbindung herstellen, nicht auf dem Server:

curl -s ifconfig.me

Hier können Sie einen jail.local erstellen, der auf Ihre Ports und Sperrrichtlinie abgestimmt ist. Fügen Sie ihn anschließend in die Datei ein:

Schritt 4: Neustart durchführen und prüfen, ob das Journal gelesen wird

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

-t führt zuerst einen Konfigurationstest durch. Ein Tippfehler in jail.local führt hier daher sofort zu einem Fehler, anstatt den Dienst nicht gestartet zu lassen. Ein korrekt arbeitender Jail-Status sieht so aus:

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

Die Zahl, die belegt, dass Fail2ban Ihre Anmeldeversuche tatsächlich auswertet, ist Total failed. Wenn sie größer als null ist oder steigt, sobald Sie eine Anmeldung absichtlich von einem anderen Rechner aus fehlschlagen lassen, wird das Journal gelesen und Sie sind fertig. Bleibt sie unabhängig von der Anzahl der Fehlversuche bei 0, und Sie sicher sind, dass Sie nicht von der Adresse in ignoreip testen, fahren Sie mit den folgenden Fehlerursachen fort.

Beachten Sie, dass die Zeile Journal matches weiterhin sshd.service nennt. Unter Ubuntu heißt die SSH-Unit tatsächlich ssh.service. Der mitgelieferte Filter sucht jedoch auch nach _COMM=sshd, und OpenSSH protokolliert seine Fehlversuche unter 24.04 mit einem Prozess namens sshd. Daher funktioniert die Übereinstimmung. Dieses Detail ist nur relevant, wenn Sie eine neuere OpenSSH-Version verwenden (9.8 oder höher, bei der der Worker pro Verbindung sshd-session heißt). Die folgenden Fehlerursachen behandeln diesen Fall.

Schritt 5: Eine tatsächliche Sperre beobachten oder zum Testen erzwingen

Auf jedem öffentlich erreichbaren VPS treten tatsächliche Sperren innerhalb weniger Minuten automatisch auf. Um eine Sperre zu beobachten, verfolgen Sie das Log:

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

Eine Sperre sieht so aus:

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

Um die gesamte Verarbeitungskette ohne Wartezeit zu prüfen, sperren Sie manuell eine Dokumentationsadresse, niemals Ihre eigene:

sudo fail2ban-client set sshd banip 10.0.0.66

Der Befehl gibt 1 aus. Die Adresse erscheint unter Banned IP list in fail2ban-client status sshd. Prüfen Sie nun, ob die Sperre tatsächlich in der Firewall vorhanden ist. Unter Ubuntu 24.04 ist dies nftables und nicht iptables:

sudo nft list table inet f2b-table

Sie sehen ein Set mit dem Namen addr-set-sshd, das 10.0.0.66 enthält, sowie eine Chain f2b-chain, die jede Quelle in diesem Set zurückweist. Wenn fail2ban-client meldet, dass eine Adresse gesperrt ist, aber in nft list nichts erscheint, passt Ihre Sperraktion nicht zu Ihrer Firewall. Lesen Sie dazu den Hinweis zu nftables/iptables im Abschnitt zu Fehlerursachen.

Schritt 6: Heben Sie Ihre eigene Sperre auf und stellen Sie den Zugriff wieder her

Wenn Sie eine Adresse gesperrt haben, die nicht gesperrt werden sollte, beispielsweise Ihre eigene, entfernen Sie die Sperre:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Bei Erfolg wird 1 ausgegeben. Um alle Sperren in allen Jails zu entfernen:

sudo fail2ban-client unban --all

Verlassen Sie sich nicht auf eine bereits geöffnete SSH-Sitzung: Die nftables-Sperre weist jedes Paket der gesperrten Adresse an Port 22 zurück, einschließlich Paketen bestehender Verbindungen. Eine vorhandene Sitzung friert daher ein, sobald die Sperre aktiv wird. Wenn Sie sich selbst sperren und keinen ignoreip-Eintrag haben, ist der Zugriff gesperrt, bis die Sperre abläuft. Stellen Sie die Verbindung über die Webkonsole Ihres Providers (VNC oder seriell) wieder her. Diese Verbindung läuft nicht über SSH. Warten Sie entweder, bis bantime abgelaufen ist, oder führen Sie dort den Befehl zum Aufheben der Sperre aus.

Schritt 7: Sperren dauerhaft speichern und eskalieren

Fail2ban speichert aktive Sperren in einer kleinen SQLite-Datenbank unter /var/lib/fail2ban/fail2ban.sqlite3. Dadurch bleiben sie nach einem Neustart des Dienstes oder einem Reboot erhalten. Sie gehen nicht verloren. Die bereits hinzugefügten Zeilen bantime.increment machen aus jedem wiederholten Angreifer ein zunehmend größeres Problem für den Angreifer selbst. Die Sperrdauer verdoppelt sich dabei ungefähr von einer Stunde bis zu einer Woche.

Für eine systemweite Richtlinie nach dem Muster „drei Verstöße“ stellt Fail2ban ein recidive-Jail bereit. Es überwacht sein eigenes /var/log/fail2ban.log und verhängt lange Sperren gegen jede Adresse, die in mehreren Jails wiederholt gesperrt wurde. Da [DEFAULT] jetzt das systemd-Backend verwendet, setzen Sie dieses Jail wieder auf die Logdatei zurück, die es lesen soll:

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

backend = auto mit dem expliziten logpath sorgt dafür, dass recidive weiterhin das normale fail2ban.log liest. Dort erscheinen die tatsächlich gezählten Ban-Zeilen. Der global gesetzte systemd-Standard würde stattdessen auf das Journal verweisen, in dem diese Zeilen nicht erscheinen.

Schritt 8: Mit SSH ausschließlich per Schlüssel kombinieren, noch besser mit einem VPN

Fail2ban ist nur in Kombination mit Schlüsselauthentifizierung sinnvoll. Legen Sie in einer Drop-in-Datei unter /etc/ssh/sshd_config.d/, beispielsweise /etc/ssh/sshd_config.d/00-hardening.conf, Folgendes fest:

PasswordAuthentication no
KbdInteractiveAuthentication no

Führen Sie anschließend sudo systemctl restart ssh aus. Wenn Passwörter deaktiviert sind, kann ein Brute-Force-Angriff überhaupt nicht erfolgreich sein. Fail2ban dient dann dazu, die Log-Meldungen zu reduzieren und Scanner frühzeitig auszusperren. Noch sicherer ist es, SSH vollständig aus dem öffentlichen Internet herauszuhalten: stellen Sie SSH hinter einem selbst gehosteten WireGuard-VPN bereit und konfigurieren Sie die Firewall für Port 22 so, dass er nur über den Tunnel erreichbar ist. Niemand kann einen Port per Brute-Force angreifen, den er nicht erreichen kann. Fail2ban dient dann als zusätzliche Absicherung und nicht als erste Schutzmaßnahme.

Fail2ban ist nicht nur für SSH geeignet. Jeder Dienst, der fehlgeschlagene Anmeldeversuche protokolliert, kann ein Jail erhalten. Dazu gehören ein Mailserver, eine nginx-Site oder ein selbst gehosteter Vaultwarden-Passwortmanager, dessen Webanmeldung Sie nicht für Credential-Stuffing offenlassen möchten. Sobald eine Webanwendung hinter einer nginx-Site mit einem Let's-Encrypt-Zertifikat läuft, verweisen Sie einen Fail2ban-Filter auf deren Access-Log. Gehen Sie dabei genauso vor wie beim SSH-Jail, das auf das Journal verweist.

Fehlerbilder mit den genau angezeigten Zeichenfolgen

„Have not found any log file for sshd jail“ und Fail2ban startet nicht. Das ist das alte auth.log-Problem. Unter Ubuntu 24.04 tritt es nur auf, wenn die vom Paket bereitgestellte Standardeinstellung überschrieben wurde, bei einer pip-Installation ohne defaults-debian.conf, in einem Container ohne Journal oder durch ein versehentlich in jail.local eingefügtes backend = auto. Bei einem dateibasierten Backend ohne /var/log/auth.log findet das sshd-Jail sein Log nicht, und der gesamte Daemon bricht ab. fail2ban.log zeigt:

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

Da dieser Fehler fatal ist, wird der Dienst nicht gestartet. fail2ban-client status meldet anschließend das Folgeproblem:

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

Die Zeile mit dem „socket path“ bedeutet nicht, dass Fail2ban defekt ist. Sie bedeutet, dass Fail2ban nicht gestartet wurde, weil ein Jail sein Log nicht finden konnte. Wenn Sie backend = systemd in [DEFAULT] setzen, was das Ubuntu-Paket bereits für Sie erledigt, verschwinden beide Meldungen.

Das Jail ist aktiv, aber Total failed ändert sich nicht. Der Daemon läuft, und das Journal wird gelesen. Trotzdem sammeln sich echte Fehlversuche in journalctl -u ssh, während der Zähler bei 0 bleibt. Schließen Sie zunächst die naheliegende Ursache aus: Sie testen von einer Adresse aus, die in ignoreip aufgeführt ist. Ihre eigenen Fehlversuche sind daher absichtlich ausgenommen. Falls das nicht die Ursache ist, verwenden Sie eine OpenSSH-Version, in der der Worker pro Verbindung sshd-session ist (9.8 und höher). Das entsprechende Journal-_COMM lautet sshd-session und nicht sshd. Daher greift das mitgelieferte Suchmuster nicht. Erweitern Sie das Suchmuster im Block [sshd]:

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

Starten Sie den Dienst neu. Führen Sie anschließend absichtlich einen fehlgeschlagenen Login von einer Adresse aus, die nicht in ignoreip aufgeführt ist. Prüfen Sie, ob Total failed nun ansteigt.

Sie haben sich selbst gesperrt: Connection refused. Sie haben Ihre eigene Adresse nicht in ignoreip eingetragen und mehrere fehlerhafte Logins getestet. Jetzt sehen Sie:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Die Ablehnung statt eines stillen Timeouts ist das standardmäßige reject-Urteil der nftables-Aktion. Es wird auch auf Ihre Verbindung angewendet. Beheben Sie das Problem wie in Schritt 6: Heben Sie die Sperre aus einer Sitzung von einer anderen, nicht gesperrten Adresse oder über die Provider-Konsole auf. Eine bereits von der gesperrten Adresse geöffnete Sitzung friert ebenfalls ein. Fügen Sie Ihre Adresse anschließend zu ignoreip hinzu, damit dies nicht erneut passiert.

Fail2ban meldet, dass eine Adresse gesperrt ist, die Adresse kann sich aber weiterhin verbinden. Der Zähler in status sshd steigt, die Adresse erreicht jedoch weiterhin Port 22. Das ist eine Diskrepanz zwischen der Sperraktion und der Firewall. Unter Ubuntu 24.04 bedeutet dies fast immer, dass Sie die funktionierende banaction = nftables durch eine aus einer älteren Anleitung kopierte banaction = iptables-multiport-Einstellung überschrieben haben, obwohl auf dem System keine iptables-Schicht vorhanden ist. fail2ban.log zeigt:

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

Löschen Sie diese Überschreibung, und verwenden Sie die vom Paket bereitgestellte nftables-Aktion. Wenn Sie die Firewall vollständig über ufw verwalten und gesperrte Adressen dort sichtbar sein sollen, setzen Sie banaction = ufw in [DEFAULT]. Starten Sie den Dienst neu. Prüfen Sie mit sudo nft list ruleset | grep f2b, ob die Regel angezeigt wird.

Fail2ban startet nach der Bearbeitung von jail.local nicht. Ein Tippfehler, eine versehentliche Überschrift oder ein ungültiger Zeitwert kann dazu führen, dass der Dienst den Start verweigert. Lassen Sie Fail2ban die Konfiguration vor dem Start prüfen:

sudo fail2ban-client -t

Der Befehl nennt die fehlerhafte Datei und das betroffene Jail, zum Beispiel Errors in jail 'sshd'. Skipping.... Dadurch korrigieren Sie die Ursache, statt die Einstellung erraten zu müssen.

FAQ

Bannt die standardmäßige Fail2ban-Installation unter Ubuntu 24.04 tatsächlich SSH-Angriffe?

Ja. Das Paket liefert /etc/fail2ban/jail.d/defaults-debian.conf mit. Dadurch wird das Jail sshd aktiviert, backend = systemd gesetzt, damit das Systemd-Journal statt des nicht vorhandenen /var/log/auth.log gelesen wird, und banaction = nftables gesetzt, damit Sperren über die tatsächlich verwendete Firewall von Ubuntu durchgesetzt werden. Ein unverändertes apt install fail2ban schützt SSH ab dem ersten Boot. Prüfen Sie dies mit sudo fail2ban-client status sshd und achten Sie auf einen Wert ungleich null bei Total failed.

Warum sperrt Fail2ban auf meinem System nichts?

Schließen Sie die drei häufigsten Ursachen der Reihe nach aus. Möglicherweise testen Sie von einer Adresse aus ignoreip, die absichtlich ausgenommen ist. Möglicherweise haben Sie den funktionierenden Standard überschrieben, indem Sie aus einer alten Anleitung backend = auto in jail.local eingefügt haben. Dadurch wird das Lesen des Journals auf einem Image ohne auth.log verhindert. Oder Sie befinden sich in einem Container, in dem überhaupt kein Systemd-Journal zum Lesen verfügbar ist. Prüfen Sie Total failed in fail2ban-client status sshd: Wenn der Wert nicht steigt, während journalctl -u ssh echte Fehlversuche anzeigt, liest das Jail an der falschen Stelle.

Wie hebe ich die Sperre für meine eigene IP-Adresse auf?

Führen Sie sudo fail2ban-client set sshd unbanip YOUR.IP.HERE aus. Bei Erfolg gibt der Befehl 1 zurück. Mit sudo fail2ban-client unban --all löschen Sie alle Sperren. Wenn Sie aus SSH ausgesperrt sind, verwenden Sie die Web- oder VNC-Konsole Ihres Providers, um denselben Befehl auszuführen. Die Sperre verwirft jedes Paket von Ihrer Adresse an Port 22. Daher funktioniert auch eine bereits geöffnete Sitzung nicht mehr. Fügen Sie Ihre Adresse anschließend zu ignoreip hinzu, damit die Sperre nicht erneut auftritt.

Was ist der Unterschied zwischen jail.conf und jail.local?

jail.conf enthält die Upstream-Standards von Fail2ban und wird bei jedem Paket-Upgrade überschrieben. Änderungen an dieser Datei gehen daher letztlich verloren. Das Debian/Ubuntu-Paket legt seine eigenen Einstellungen über jail.d/defaults-debian.conf darüber. Ihre Änderungen gehören in jail.local. Diese Datei wird zuletzt gelesen, setzt sich gegenüber beiden anderen Dateien durch und wird bei Upgrades nicht verändert. Lassen Sie jail.conf als schreibgeschützte Referenz unverändert.

Ersetzt Fail2ban die SSH-Authentifizierung per Schlüssel?

Nein. Fail2ban begrenzt die Rate wiederholter Fehlversuche von einer Adresse. Gegen langsame, verteilte Angriffe, bei denen jede Adresse unter dem Schwellenwert bleibt, bietet es keinen Schutz. Eine schlüsselbasierte Authentifizierung nur mit Schlüsseln (PasswordAuthentication no) macht das Erraten von Passwörtern grundsätzlich unmöglich. Fail2ban reduziert dann die Log-Meldungen und entfernt Scanner frühzeitig. Verwenden Sie beides. Idealerweise ist SSH überhaupt nicht aus dem öffentlichen Internet erreichbar.