Fail2ban unter Ubuntu 24.04 installieren

Was Fail2ban tatsächlich tut

Fail2ban ist ein Daemon zum Lesen von Logdateien. Er überwacht Ihre SSH-Authentifizierungsnachrichten. Wenn eine Adresse innerhalb eines kurzen Zeitfensters mehrere Fehlversuche meldet, führt er einen Firewall-Befehl aus, der diese Adresse vorübergehend sperrt. Das ist das grundlegende Prinzip. Die Konfiguration umfasst etwa dreißig Zeilen in einer Datei. Unter Ubuntu 24.04 erfolgt die Installation über einen einzelnen apt-Befehl, der den Schutz aktiviert, noch bevor Sie Änderungen vornehmen.

Unterscheiden Sie genau, was das Programm leistet und was nicht. Fail2ban authentifiziert keine Benutzer, verschlüsselt keine Daten und stoppt keinen einzelnen, gezielten Login-Versuch – sondern nur wiederholte Versuche von derselben Quelle. Es handelt sich um einen Rauschfilter und einen Rate-Limiter, nicht um ein Schloss. Die Aufgabe besteht darin, das kontinuierliche Scannen von Port 22 zu unterbinden, damit CPU-Leistung, Bandbreite und Speicherplatz für Logdateien nicht verschwendet werden. Zudem wird Angreifer, die nur eine Adresse gleichzeitig nutzen können, verlangsamt.

Was Fail2ban nicht ersetzt

Fail2ban ist die dritte Ebene, nicht die erste. Wenn Ihr Server weiterhin SSH-Passwörter akzeptiert, kann ein Botnet, das über Tausende von Adressen verteilt ist, weiterhin Passwörter erraten. Dies geschieht, weil jede einzelne Adresse unter Ihrem Ban-Schwellenwert bleibt und diesen nie auslöst. Die wirksame Verteidigung dagegen ist die reine Schlüssel-Authentifizierung (key-only authentication). Diese macht das Erraten von Passwörtern unmöglich, unabhängig von der Anzahl der Versuche. Fail2ban zusätzlich zur Schlüssel-Authentifizierung bietet zwei Vorteile: Es reduziert das Brute-Force-Rauschen in Ihren Logs und entfernt Scanner frühzeitig, damit diese den Port nicht weiter angreifen. Betrachten Sie es als Defense in Depth. Es arbeitet hinter der Schlüssel-Authentifizierung und hinter einer Firewall, niemals davor.

Voraussetzungen und die Realität unter Ubuntu 24.04

Sie benötigen einen VPS mit Ubuntu 24.04 und root- oder sudo-Rechten sowie einer funktionierenden SSH-Verbindung – idealerweise über eine Schlüsselauthentifizierung. Fail2ban ist ressourcensparend: Er benötigt nur wenige zehn Megabyte RAM und erfordert keine Anpassung der Limits.

Hier folgt der Teil, den jeder ältere Leitfaden falsch macht. Jahrelang lautte der Standardrat: „Installieren Sie Fail2ban und fügen Sie backend = systemd hinzu, da Ubuntu aufgehört hat, /var/log/auth.log zu schreiben.“ Dieser Rat beschreibt eine reale Änderung – moderne Server- und Cloud-Images werden ohne rsyslog ausgeliefert, sodass SSH-Logs nur noch in das systemd-Journal geschrieben werden und die Textdatei fehlt. Unter Ubuntu 24.04 berücksichtigt das Fail2ban-Paket dies jedoch bereits. Das Paket liefert /etc/fail2ban/jail.d/defaults-debian.conf mit, und diese Datei bestimmt, was Ihr Server tatsächlich ausführt, nicht die Standardeinstellungen des Upstreams:

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

[sshd]
enabled = true

Lesen Sie dies sorgfältig, da es zwei Fragen klärt, bevor Sie Änderungen vornehmen. backend = systemd bedeutet, dass der SSH-Jail das Journal ausliest, sodass die fehlende auth.log keine Rolle spielt. banaction = nftables bedeutet, dass Sperren über nftables erzwungen werden, was die Firewall ist, die Ubuntu 24.04 tatsächlich verwendet, anstatt des veralteten iptables. Und [sshd] enabled = true bedeutet, dass der Jail ab dem ersten Bootvorgang aktiv ist. Das Ergebnis: Ein Standard-apt install fail2ban auf Ubuntu 24.04 sperrt SSH-Brute-Force-Angriffe sofort. Die meiste Arbeit besteht darin, dies zu bestätigen, die Richtlinien anzupassen und sicherzustellen, dass Sie sich nicht selbst aussperren.

Die alte auth.log-Falle tritt in drei Situationen auf, die es zu kennen gilt: Sie haben Fail2ban mit pip anstatt mit apt installiert, weshalb defaults-debian.conf fehlt; Sie befinden sich in einem unprivilegierten Container ohne systemd-Journal zum Auslesen; oder Sie haben einem alten Tutorial gefolgt und backend = auto in Ihre eigene jail.local kopiert, wodurch die funktionierende Standardeinstellung überschrieben wurde. Der Abschnitt zu den Fehlerursachen zeigt genau, wie diese aussehen.

Schritt 1: Installation und Überprüfung der aktiven Sperrfunktion

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 enthält Fail2ban 1.0.2. Das Paket installiert python3-systemd als Hard-Dependency, sodass das Journal-Backend alle erforderlichen Komponenten besitzt. Der Dienst aktiviert und startet sich selbst:

sudo systemctl status fail2ban

Sie benötigen active (running). Überprüfen Sie anschließend die Jail, die bereits aktiv ist:

sudo fail2ban-client status sshd

Auf einem öffentlichen VPS, der nur wenige Minuten erreichbar ist, werden oft bereits Fehlversuche gezählt und IP-Adressen gesperrt – das Internet scannt Port 22 kontinuierlich. Dies ist der Beweis, dass die Standardkonfiguration funktioniert. Sie passen die Konfiguration ab diesem Punkt an, anstatt sie neu zu erstellen.

Schritt 2: Editieren Sie jail.local, niemals jail.conf

Fail2ban speichert die Standardwerte in /etc/fail2ban/jail.conf. Editieren Sie diese Datei nicht. Jedes apt upgrade des Pakets kann diese Datei ersetzen, wodurch Ihre Änderungen ohne Warnung verloren gehen. Fail2ban liest Dateien in einer festen Reihenfolge — zuerst jail.conf, dann alles in jail.d/, dann jail.local — wobei der letzte Wert entscheidend ist. Die .local Datei gehört Ihnen; Paket-Upgrades ändern diese Datei niemals. Dieselbe Regel gilt für Filter, wobei eine *.local Datei die mitgelieferte filter.d/*.conf Datei überschreibt.

Schreiben Sie daher eine kleine jail.local, die nur die wenigen relevanten Einstellungen überschreibt. Lassen Sie sowohl jail.conf als auch die mitgelieferte jail.d/defaults-debian.conf als Referenz unverändert.

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

sudo nano /etc/fail2ban/jail.local

Fügen Sie diesen Inhalt ein und ersetzen Sie die Adresse in der Zeile ignoreip durch Ihre eigene öffentliche 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

Jede Zeile hat eine spezifische Funktion:

• bantime, findtime, maxretry definieren die Richtlinie. Der standardmäßig gelieferte Wert bantime beträgt nur zehn Minuten; eine Stunde ist ein vernünftigerer Mindestwert. Fünf Fehlversuche von einer Adresse innerhalb von zehn Minuten führen zur Sperre. Echte Benutzer vertippen sich ein- oder zweimal; fünf Fehlversuche in zehn Minuten deuten auf ein Skript hin.
• ignoreip dient als Sicherheitsmechanismus. Tragen Sie hier die öffentliche Adresse ein, von der aus Sie sich verbinden, damit Fail2ban Sie niemals von Ihrem eigenen Server aussperrt. Eine Heimverbindung mit wechselnder IP ist ein Grund, am Ende den VPN-Ansatz zu bevorzugen, aber kein Grund, diese Zeile wegzulassen.
• bantime.increment = true bewirkt, dass jede wiederholte Sperre länger dauert als die vorherige — eine Stunde, dann zwei, dann vier — bis zu bantime.maxtime. Adressen, die wiederholt versuchen zuzugreifen, werden progressiv ausgesperrt.

Ermitteln Sie die Adresse, die auf die Whitelist gesetzt werden soll, von der Maschine aus, von der Sie per SSH zugreifen, nicht vom Server:

curl -s ifconfig.me

Sie können hier eine auf Ihre Ports und Richtlinien optimierte jail.local generieren und diese anschließend in die Datei einfügen:

Schritt 4: Neustart und Überprüfung des Journal-Zugriffs

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

Der -t führt zuerst einen Konfigurationstest aus. Ein Tippfehler in jail.local führt hier zu einer Fehlermeldung, anstatt den Dienst stillschweigend abstürzen zu lassen. Ein korrekter 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 beweist, dass Fail2ban die Logins tatsächlich ausliest, ist Total failed. Wenn dieser Wert über Null liegt oder ansteigt, wenn Sie absichtlich einen Login von einem anderen Gerät aus fehlschlagen lassen, wird das Journal korrekt gelesen und der Vorgang ist abgeschlossen. Wenn der Wert bei 0 bleibt, egal wie oft Sie den Login fehlschlagen lassen — und Sie sicher sind, dass Sie nicht von der Adresse in ignoreip aus testen — folgen Sie den Fehlerbehebungen unten.

Beachten Sie, dass die Journal matches-Zeile weiterhin sshd.service nennt. Unter Ubuntu lautet die SSH-Unit eigentlich ssh.service, aber der mitgelieferte Filter gleicht auch mit _COMM=sshd ab. OpenSSH protokolliert Fehlversuche unter 24.04 über einen Prozess namens sshd, weshalb der Abgleich funktioniert. Dieses Detail ist nur relevant, wenn Sie eine neuere OpenSSH-Version (9.8 oder neuer, bei der der Per-Connection-Worker sshd-session ist) verwenden; die Fehlerbehebungen decken diesen Fall ab.

Schritt 5: Einen echten Ban beobachten oder einen Test-Ban erzwingen

Auf einem öffentlichen VPS treten echte Bans innerhalb weniger Minuten automatisch auf. Um einen Ban zu beobachten, nutzen Sie den tail-Befehl für das Log:

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

Ein Ban 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 Funktionsweise ohne Wartezeit zu testen, sperren Sie manuell eine Dokumentations-Adresse – nutzen Sie niemals Ihre eigene:

sudo fail2ban-client set sshd banip 10.0.0.66

Es wird 1 ausgegeben und die Adresse erscheint unter Banned IP list in fail2ban-client status sshd. Bestätigen Sie nun, dass die Sperre tatsächlich in der Firewall existiert. Unter Ubuntu 24.04 wird nftables statt iptables verwendet:

sudo nft list table inet f2b-table

Sie sehen ein Set namens addr-set-sshd, das 10.0.0.66 enthält, sowie eine Chain f2b-chain, die alle Quellen in diesem Set ablehnt. Wenn fail2ban-client anzeigt, dass eine Adresse gesperrt ist, aber nichts in nft list erscheint, stimmt die Ban-Aktion nicht mit Ihrer Firewall überein – siehe den Hinweis zu nftables/iptables unter den Fehlerursachen.

Schritt 6: Entsperren Sie sich selbst und stellen Sie den Zugriff wieder her, falls Sie ausgesperrt wurden

Falls Sie eine Adresse gesperrt haben, die nicht gesperrt werden sollte – zum Beispiel Ihre eigene – entfernen Sie diese:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Bei Erfolg wird 1 zurückgegeben. Um alle Sperren in allen Jails zu löschen:

sudo fail2ban-client unban --all

Verlassen Sie sich nicht auf eine bereits offene SSH-Session: nftables lehnt jedes Paket von der gesperrten Adresse an Port 22 ab – auch bestehende Verbindungen. Eine aktive Session friert sofort nach der Sperrung ein. Wenn Sie sich selbst sperren und keinen ignoreip-Eintrag haben, bleiben Sie ausgesperrt, bis die Sperre abläuft. Stellen Sie den Zugriff über die Web-Konsole Ihres Providers wieder her (VNC oder Serial), da diese nicht über SSH läuft. Warten Sie entweder, bis bantime abgelaufen ist, oder führen Sie dort den Befehl zum Entsperren aus.

Schritt 7: Sperren dauerhaft machen und eskalieren

Fail2ban speichert aktive Sperren in einer kleinen SQLite-Datenbank unter /var/lib/fail2ban/fail2ban.sqlite3. Dadurch bleiben die Sperren nach einem Neustart des Dienstes oder des Systems erhalten. Die bereits hinzugefügten bantime.increment-Zeilen führen dazu, dass sich die Sperrdauer bei wiederholten Verstößen erhöht – sie verdoppelt sich etwa von einer Stunde auf eine Woche.

Für eine systemweite „Three-Strikes“-Policy bietet Fail2ban ein recidive-Jail an. Dieses überwacht das eigene /var/log/fail2ban.log und sperrt Adressen, die in allen Jails wiederholt gesperrt wurden, für lange Zeiträume. Da Ihr [DEFAULT] nun das systemd-Backend nutzt, müssen Sie dieses Jail wieder auf die Logdatei festlegen, die es auslesen soll:

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

Die Verwendung von backend = auto mit dem expliziten logpath bewirkt, dass recidive weiterhin die einfache fail2ban.log liest. Dort erscheinen die Ban-Zeilen, die gezählt werden. Die global gesetzte systemd-Standardeinstellung würde auf das Journal verweisen, wo diese Zeilen nicht vorhanden sind.

Schritt 8: Kombination mit Key-only SSH oder idealerweise einem VPN

Fail2ban ist nur in Kombination mit einer Schlüssel-Authentifizierung (Key Authentication) effektiv. Erstellen Sie eine Konfigurationsdatei unter /etc/ssh/sshd_config.d/ — zum Beispiel /etc/ssh/sshd_config.d/00-hardening.conf — mit folgendem Inhalt:

PasswordAuthentication no
KbdInteractiveAuthentication no

Führen Sie anschließend sudo systemctl restart ssh aus. Wenn die Passwort-Authentifizierung deaktiviert ist, können Brute-Force-Angriffe nicht mehr erfolgreich sein. Fail2ban dient dann dazu, das Log-Rauschen zu reduzieren und Scanner frühzeitig zu blockieren. Noch sicherer ist es, SSH vollständig vom öffentlichen Internet zu trennen: stellen Sie SSH hinter ein selbst gehostetes WireGuard VPN und sperren Sie Port 22 in der Firewall, sodass er nur innerhalb des Tunnels antwortet. Ein Port, der nicht erreichbar ist, kann nicht per Brute-Force angegriffen werden; Fail2ban fungiert dann als zusätzliche Absicherung statt als primäre Verteidigungslinie.

Fail2ban ist nicht nur für SSH gedacht. Jeder Dienst, der fehlgeschlagene Logins protokolliert, kann eine Jail erhalten — etwa ein Mail-Server, eine nginx-Instanz oder ein selbst gehosteter Vaultwarden Passwort-Manager, dessen Web-Login nicht offen für Credential-Stuffing-Angriffe stehen sollte. Sobald eine Web-App hinter einer nginx-Instanz mit einem Let's Encrypt Zertifikat läuft, weisen Sie einen Fail2ban-Filter auf die Access-Log-Datei hin, genau wie die SSH-Jail auf das Journal verweist.

Fehlerzustände und die exakten Fehlermeldungen

"Have not found any log file for sshd jail", und Fail2ban startet nicht. Dies ist das bekannte auth.log-Problem. Auf Ubuntu 24.04 tritt dies nur auf, wenn Standardeinstellungen überschrieben wurden — etwa eine pip-Installation ohne defaults-debian.conf, ein Container ohne journal oder ein fehlerhafter backend = auto-Eintrag in jail.local. Bei einem File-Backend ohne /var/log/auth.log findet die sshd-Jail ihre Logdatei 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, startet der Dienst nicht und fail2ban-client status meldet das folgende Folgeproblem:

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

Die Zeile "socket path" bedeutet nicht, dass Fail2ban defekt ist — sie bedeutet, dass der Dienst nicht gestartet wurde, weil eine Jail ihre Logdatei 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 bewegt sich nicht. Der Daemon läuft und das journal wird gelesen, aber es häufen sich Fehlversuche in journalctl -u ssh, während der Zähler bei 0 verharrt. Prüfen Sie zuerst die offensichtlichen Ursachen: Sie testen von einer Adresse, die in ignoreip gelistet ist; diese Ausnahmen sind systembedingt. Falls dies nicht die Ursache ist, nutzen Sie eine OpenSSH-Version, bei der der Worker pro Verbindung sshd-session (9.8 und neuer) ist. Dessen journal _COMM ist sshd-session und nicht sshd, weshalb der Standard-Match fehlschlägt. Erweitern Sie den Match im [sshd]-Block:

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

Starten Sie neu, provozieren Sie einen Login-Fehler von einer Adresse, die nicht in ignoreip steht, und prüfen Sie, ob Total failed schließlich ansteigt.

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

ssh: connect to host 10.0.0.10 port 22: Connection refused

Die Ablehnung ist kein Timeout, sondern das Standard-Urteil reject der nftables-Action. Beheben Sie dies wie in Schritt 6: Entsperren Sie sich über eine Sitzung von einer anderen, nicht gesperrten Adresse oder über die Konsole des Providers — eine bereits offene Sitzung von der gesperrten Adresse wird ebenfalls einfrieren. Fügen Sie Ihre Adresse anschließend zu ignoreip hinzu, um dies zu verhindern.

Fail2ban meldet, dass eine Adresse gesperrt ist, aber die Verbindung ist weiterhin möglich. Der Zähler in status sshd steigt, aber die Adresse erreicht weiterhin Port 22. Dies ist ein Konflikt zwischen der Ban-Action und der Firewall. Auf Ubuntu 24.04 bedeutet dies fast immer, dass Sie die funktionierende banaction = nftables durch eine banaction = iptables-multiport ersetzt haben, die aus einem älteren Guide stammt und auf einem System ohne iptables-Layer konfiguriert wurde. fail2ban.log zeigt:

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

Löschen Sie diese Überschreibung und nutzen Sie die mitgelieferte nftables-Action. Falls Sie die Firewall vollständig über ufw verwalten und die Sperren dort sehen möchten, setzen Sie banaction = ufw in [DEFAULT]. Starten Sie neu und prüfen Sie mit sudo nft list ruleset | grep f2b, ob die Regel erscheint.

Fail2ban startet nach Bearbeitung von jail.local nicht. Ein Tippfehler — eine falsche Überschrift oder ein ungültiger Zeitwert — verhindert den Dienststart. Lassen Sie Fail2ban die Konfiguration vor dem Start prüfen:

sudo fail2ban-client -t

Das Tool nennt die Datei und die Jail, die das Problem verursacht (z. B. Errors in jail 'sshd'. Skipping...), sodass Sie die Ursache direkt beheben können.

FAQ

Sperrt die Standard-Fail2ban-Installation auf Ubuntu 24.04 SSH-Angriffe tatsächlich?

Ja. Das Paket enthält /etc/fail2ban/jail.d/defaults-debian.conf. Dies aktiviert die sshd jail, setzt backend = systemd, damit das systemd journal statt des fehlenden /var/log/auth.log gelesen wird, und setzt banaction = nftables, damit die Sperren über die Ubuntu-Firewall durchgesetzt werden. Eine einfache apt install fail2ban schützt SSH ab dem ersten Bootvorgang. Bestätigen 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?

Prüfen Sie die drei häufigsten Ursachen nacheinander. Sie testen möglicherweise von einer Adresse aus ignoreip, die systembedingt ausgenommen ist. Sie haben möglicherweise die funktionierende Standardkonfiguration überschrieben, indem Sie backend = auto aus einem alten Leitfaden in jail.local eingefügt haben. Dies verhindert das Lesen des Journals auf einem Image ohne auth.log. Oder Sie befinden sich in einem Container, der kein systemd journal zum Lesen besitzt. Prüfen Sie Total failed in fail2ban-client status sshd: Wenn dieser Wert nicht steigt, während journalctl -u ssh echte Fehlversuche anzeigt, liest die jail den falschen Ort aus.

Wie entsperre ich meine eigene IP-Adresse?

Führen Sie sudo fail2ban-client set sshd unbanip YOUR.IP.HERE aus, was bei Erfolg 1 zurückgibt, oder sudo fail2ban-client unban --all, um alle Sperren zu löschen. Wenn Sie durch SSH ausgesperrt sind, nutzen Sie die Web- oder VNC-Konsole Ihres Providers, um denselben Befehl auszuführen. Die Sperre lehnt jedes Paket von Ihrer Adresse an Port 22 ab; daher funktioniert selbst eine bereits offene Sitzung nicht mehr. Fügen Sie Ihre Adresse anschließend zu ignoreip hinzu, damit dies nicht erneut auftritt.

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

jail.conf enthält die Standardwerte von Fail2ban und wird bei jedem Paket-Upgrade überschrieben. Änderungen dort gehen 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 und hat Vorrang vor beiden anderen Dateien. Updates berühren diese Datei nie. Nutzen Sie jail.conf nur als schreibgeschützte Referenz.

Ersetzt Fail2ban die SSH-Authentifizierung per Key?

Nein. Fail2ban begrenzt die Rate wiederholter Fehlversuche von einer Adresse; es schützt nicht gegen langsame, verteilte Angriffe, bei denen jede Adresse unter dem Schwellenwert bleibt. Eine reine Key-Authentifizierung (PasswordAuthentication no) macht das Raten von Passwörtern unmöglich. Fail2ban reduziert dann das Log-Rauschen und entfernt Scanner frühzeitig. Nutzen Sie beide Methoden und lassen Sie SSH idealerweise komplett vom öffentlichen Internet aus entfernt.