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 von Ubuntu 24.04

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

Nun zu dem Punkt, den ältere Anleitungen häufig falsch darstellen. Jahrelang lautete die Standardempfehlung: „Installieren Sie Fail2ban und fügen Sie anschließend backend = systemd hinzu, weil Ubuntu /var/log/auth.log nicht mehr schreibt.“ Diese Empfehlung gilt nur für bestimmte Images. Ein unverändertes Ubuntu-24.04-Server- oder Cloud-Image installiert weiterhin rsyslog. Dessen Standardregeln schreiben auth,authpriv.* nach /var/log/auth.log. Daher landen SSH-Fehler auf den meisten VPS sowohl in dieser Datei als auch im systemd-Journal. Minimale Images (das minimale Ubuntu-24.04-Cloud-Image wird ohne rsyslog ausgeliefert) und die meisten Container protokollieren SSH dagegen nur im Journal. Dort fehlt die Textdatei tatsächlich. In beiden Fällen berücksichtigt das Fail2ban-Paket Ubuntu 24.04 bereits. Das Paket legt /etc/fail2ban/jail.d/defaults-debian.conf an. Diese Datei, nicht die Upstream-Standards, wird auf Ihrem Server tatsächlich verwendet:

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

[sshd]
enabled = true

Lesen Sie die Datei sorgfältig. Damit sind zwei Fragen geklärt, bevor Sie Änderungen vornehmen. backend = systemd bedeutet, dass der SSH-Jail das Journal liest. Es spielt daher keine Rolle, ob Ihr Image auth.log schreibt. banaction = nftables bedeutet, dass Sperren über nftables durchgesetzt werden. Das ist die Firewall, die Ubuntu 24.04 tatsächlich verwendet, und nicht das ältere iptables. [sshd] enabled = true bedeutet, dass der Jail bereits beim ersten Boot aktiviert ist. Das Ergebnis: Ein unverändertes apt install fail2ban sperrt unter Ubuntu 24.04 SSH-Brute-Force-Angriffe standardmäßig. Ihre Hauptaufgabe besteht darin, dies zu bestätigen, die Richtlinie anzupassen und sicherzustellen, dass Sie sich nicht selbst aussperren.

Die alte auth.log-Falle tritt weiterhin in drei Situationen auf. Sie sollten diese Fälle erkennen: Sie haben Fail2ban mit pip statt mit apt installiert, sodass defaults-debian.conf fehlt. Sie befinden sich in einem nicht privilegierten Container ohne systemd-Journal, das gelesen werden kann. Oder Sie sind einer alten Anleitung gefolgt und haben backend = auto in Ihre eigene jail.local kopiert. Dadurch wurde die funktionierende Standardeinstellung überschrieben. Der erste und der dritte Fall verhindern die SSH-Sperrung nur auf einem Image ohne rsyslog, beispielsweise auf einem minimalen Image. Wenn rsyslog ausgeführt wird, findet das dateibasierte Backend /var/log/auth.log und funktioniert. Der Abschnitt zu den Fehlerursachen 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: Bearbeiten Sie jail.local, niemals jail.conf

Fail2ban speichert seine Standardeinstellungen aus dem Upstream in /etc/fail2ban/jail.conf. Bearbeiten Sie diese Datei nicht. Ein Paket-Upgrade kann sie ersetzen, wie der eigene Kopfbereich warnt, und Ihre Änderungen können verloren gehen. Fail2ban liest Dateien in einer festen Reihenfolge: zuerst jail.conf, anschließend jail.d/*.conf in alphabetischer Reihenfolge, dann jail.local und danach jail.d/*.local in alphabetischer Reihenfolge. Der zuletzt gelesene Wert gilt. Daher überschreibt jail.local die mit dem Paket gelieferte Datei defaults-debian.conf. Jede *.local-Datei, die Sie in jail.d/ ablegen, wird danach gelesen und überschreibt den Wert wiederum. Halten Sie Ihre Überschreibungen an einer Stelle, damit Sie wissen, welcher Wert aktiv ist. Die Datei .local gehört Ihnen. Paket-Upgrades ändern sie nie. Dasselbe gilt für Filter: Eine *.local-Datei überschreibt die mitgelieferte Datei filter.d/*.conf.

Sie erstellen daher eine kleine jail.local-Datei, die nur die wenigen Einstellungen überschreibt, die Sie benötigen. jail.conf und die mit dem Paket gelieferte Datei jail.d/defaults-debian.conf lassen Sie als Referenz unverändert.

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 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. Dadurch schlägt ein Tippfehler in jail.local hier direkt fehl, statt den Dienst funktionslos zu hinterlassen. Ein fehlerfreier 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:   203.0.113.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 von einem anderen Computer absichtlich eine Anmeldung fehlschlagen lassen, wird das Journal gelesen und Sie sind fertig. Bleibt sie unabhängig von der Anzahl Ihrer Fehlversuche bei 0, und sind Sie sicher, 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 erkennt jedoch auch _COMM=sshd, und OpenSSH protokolliert seine Fehlversuche unter 24.04 von 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 echte Sperre beobachten oder testweise erzwingen

Echte Sperren werden auf jedem öffentlichen VPS innerhalb weniger Minuten automatisch ausgelöst. 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 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

Um den Ablauf ohne Wartezeit vollständig zu testen, sperren Sie manuell eine Dokumentationsadresse, niemals Ihre eigene. 203.0.113.66 liegt in TEST-NET-3, einem für Dokumentation reservierten Adressbereich. Daher kann es sich weder um einen echten Host noch um eine private Adresse im Netzwerk Ihres Providers handeln:

sudo fail2ban-client set sshd banip 203.0.113.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 wird dafür nftables verwendet, nicht iptables:

sudo nft list table inet f2b-table

Sie sehen ein Set namens addr-set-sshd, das 203.0.113.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 unter nft list nichts erscheint, stimmen Ihre Sperraktion und Ihre Firewall nicht überein. Lesen Sie dazu den Hinweis zu nftables/iptables im Abschnitt zu den 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, entfernen Sie die Sperre. Das gilt auch für Ihre eigene Adresse:

sudo fail2ban-client set sshd unbanip 203.0.113.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 verwirft jedes Paket der gesperrten Adresse an Port 22, 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 wieder her, beispielsweise über VNC oder eine serielle Konsole. Diese Verbindung verwendet nicht 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.

Fehlermodi und die exakten Meldungen, die Sie sehen werden

"Have not found any log file for sshd jail", und Fail2ban startet nicht. Dies ist das alte auth.log-Problem. Unter Ubuntu 24.04 tritt es nur auf, wenn /var/log/auth.log nicht existiert (ein Image ohne rsyslog, wie ein Minimal-Image oder ein Container) und das Journal nicht gelesen wird: eine pip-Installation ohne defaults-debian.conf, ein Container ohne Journal oder ein versehentliches backend = auto, das Sie in jail.local eingefügt haben. Auf einem Datei-Backend ohne /var/log/auth.log kann das sshd-Jail sein Log nicht finden 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, startet der Dienst nicht und fail2ban-client status meldet daraufhin das nachgelagerte Symptom:

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 es nie gestartet wurde, weil ein Jail sein Log nicht finden konnte. Das Setzen von backend = systemd in [DEFAULT], was das Ubuntu-Paket bereits für Sie erledigt, behebt beide Meldungen gleichzeitig.

Jail ist aktiv, aber Total failed ändert sich nicht. Der Daemon läuft und das Journal wird gelesen, dennoch häufen sich echte Fehlversuche in journalctl -u ssh, während der Zähler auf 0 stehen bleibt. Schließen Sie zuerst das Offensichtliche aus: Sie testen von einer Adresse aus, die in ignoreip aufgeführt ist, daher sind Ihre eigenen Fehlversuche systembedingt ausgenommen. Wenn dies nicht die Ursache ist, verwenden Sie eine OpenSSH-Version, in der der Worker pro Verbindung sshd-session ist (9.8 oder höher), deren Journal-_COMM sshd-session und nicht sshd lautet, weshalb der mitgelieferte Abgleich fehlschlägt. Erweitern Sie den Abgleich im [sshd]-Block:

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

Starten Sie neu, provozieren Sie einen fehlgeschlagenen Login von einer Adresse, die nicht in ignoreip steht, und bestätigen Sie, dass Total failed endlich ansteigt.

Sie haben sich selbst gesperrt: Connection refused. Sie haben Ihre eigene Adresse nicht in ignoreip aufgenommen, einige fehlerhafte Logins getestet und nun:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Die Verweigerung, anstatt eines stillen Timeouts, ist das standardmäßige reject-Urteil der nftables-Aktion, das seine Arbeit an Ihnen verrichtet. Beheben Sie dies wie in Schritt 6: Heben Sie die Sperre von einer Sitzung über eine andere, nicht gesperrte Adresse auf oder über die Konsole des Anbieters; eine bereits geöffnete Sitzung von der gesperrten Adresse friert ebenfalls ein. Fügen Sie dann Ihre Adresse zu ignoreip hinzu, damit dies nicht erneut passiert.

Fail2ban meldet eine gesperrte Adresse, aber diese kann weiterhin eine Verbindung herstellen. Der Zähler in status sshd steigt, doch die Adresse erreicht weiterhin Port 22. Dies ist ein Konflikt zwischen der Sperraktion und der Firewall. Unter Ubuntu 24.04 bedeutet dies fast immer, dass Sie die funktionierende banaction = nftables-Einstellung mit banaction = iptables-multiport überschrieben haben, das aus einer älteren Anleitung kopiert wurde, auf einem System ohne iptables-Schicht. 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 mitgelieferte nftables-Aktion. Wenn Sie die Firewall vollständig über ufw verwalten und möchten, dass Sperren dort erscheinen, setzen Sie banaction = ufw in [DEFAULT]. Starten Sie neu und bestätigen Sie mit sudo nft list ruleset | grep f2b, dass die Regel erscheint.

Fail2ban startet nach dem Bearbeiten von jail.local nicht. Ein Tippfehler, eine überflüssige Überschrift oder ein ungültiger Zeitwert führen dazu, dass der Dienst nicht startet. Lassen Sie Fail2ban die Konfiguration vor dem Ausführen prüfen:

sudo fail2ban-client -t

Es benennt die Datei und das Jail mit dem Problem, zum Beispiel Errors in jail 'sshd'. Skipping..., sodass Sie die Ursache beheben können, anstatt zu raten.

FAQ

Sperrt die Standardinstallation von Fail2ban unter Ubuntu 24.04 tatsächlich SSH-Angriffe?

Ja. Das Paket enthält /etc/fail2ban/jail.d/defaults-debian.conf. Dadurch wird der Jail sshd aktiviert. Außerdem wird backend = systemd gesetzt, sodass das systemd-Journal gelesen wird, unabhängig davon, ob Ihr Image /var/log/auth.log schreibt. Mit banaction = nftables werden Sperren über die tatsächliche Firewall von Ubuntu durchgesetzt. Ein einfaches apt install fail2ban schützt SSH ab dem ersten Bootvorgang. 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 die funktionierende Standardeinstellung überschrieben, indem Sie aus einer älteren Anleitung backend = auto in jail.local eingefügt haben. Dadurch funktioniert die SSH-Sperre auf einem Image ohne rsyslog und damit auch ohne auth.log nicht. Oder Sie befinden sich in einem Container, in dem überhaupt kein systemd-Journal zum Lesen vorhanden ist. Prüfen Sie Total failed in fail2ban-client status sshd. Wenn der Wert nicht ansteigt, während journalctl -u ssh echte Fehler anzeigt, liest der Jail an der falschen Stelle.

Wie hebe ich die Sperre meiner eigenen IP-Adresse auf?

Führen Sie sudo fail2ban-client set sshd unbanip YOUR.IP.HERE aus. Bei Erfolg wird 1 zurückgegeben. Mit sudo fail2ban-client unban --all heben Sie alle Sperren auf. 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 dies nicht erneut geschieht.

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

jail.conf enthält die Upstream-Standardeinstellungen von Fail2ban und kann durch ein Paketupgrade ersetzt werden. Jede Änderung an dieser Datei ist daher gefährdet. Das Debian/Ubuntu-Paket ergänzt seine eigenen Einstellungen über jail.d/defaults-debian.conf. Ihre Änderungen gehören in jail.local. Diese Datei wird nach den beiden anderen Dateien gelesen und hat Vorrang. Bei Upgrades bleibt sie unverändert. Nur eine *.local-Datei innerhalb von jail.d/ wird noch später gelesen. Lassen Sie dort daher keine zusätzlichen Dateien liegen. Verwenden Sie jail.conf nur als Referenz und ändern Sie sie nicht.

Ersetzt Fail2ban die SSH-Authentifizierung per Schlüssel?

Nein. Fail2ban begrenzt die Rate wiederholter Fehler von einer Adresse. Gegen langsame, verteilte Rateversuche, bei denen jede Adresse unter dem Schwellenwert bleibt, wirkt es nicht. Eine Authentifizierung ausschließlich per Schlüssel (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.