SSH absichern: Fail2Ban, Key-Only, Port ändern
Inhaltsverzeichnis:
Jeder öffentlich erreichbare Linux-Server ist permanenten Angriffen ausgesetzt. Besonders der SSH-Dienst steht im Fokus automatisierter Bots, die rund um die Uhr Passwörter durchprobieren. Brute-Force-Attacken treffen dabei nicht nur große Unternehmen. Auch kleine Projekte und private Server geraten ins Visier. Ein ungesicherter SSH-Zugang öffnet Angreifern Tür und Tor. Bereits wenige Minuten nach der Ersteinrichtung eines Servers tauchen erste Login-Versuche in den Logdateien auf.
Glücklicherweise lässt sich der SSH-Zugang mit wenigen Maßnahmen deutlich härten. Drei Methoden haben sich in der Praxis besonders bewährt: Fail2Ban als Intrusion-Prevention-System, die ausschließliche Authentifizierung per SSH-Schlüssel sowie das Verlegen des Standard-Ports. Jede dieser Maßnahmen allein erhöht die Sicherheit spürbar. In Kombination bilden sie jedoch ein robustes Schutzschild gegen die meisten Angriffsszenarien. Dieser Artikel erklärt alle drei Ansätze im Detail.
Fail2Ban: Funktionsweise und Installation
Fail2Ban ist ein in Python geschriebenes Sicherheitswerkzeug, das seit 2004 aktiv weiterentwickelt wird. Die Software überwacht Logdateien wie /var/log/auth.log auf fehlgeschlagene Anmeldeversuche. Erkennt Fail2Ban ein verdächtiges Muster, sperrt es die betreffende IP-Adresse automatisch für einen definierten Zeitraum. Diese temporäre Blockade erfolgt über Firewall-Regeln, etwa mittels nftables oder iptables. Der gesamte Vorgang läuft im Hintergrund als Daemon ab. Administratoren müssen nach der Einrichtung nicht manuell eingreifen.
Die Installation gelingt unter Debian, Ubuntu und den meisten anderen Distributionen mit einem einzigen Paketmanager-Befehl. Nach der Installation startet der Dienst automatisch und überwacht standardmäßig den SSH-Daemon. Wichtig ist allerdings der Umgang mit den Konfigurationsdateien. Die Datei jail.conf sollte niemals direkt bearbeitet werden, denn Paketupdates überschreiben sie regelmäßig. Stattdessen empfiehlt sich eine eigene jail.local, in der alle individuellen Einstellungen gespeichert werden. Diese Datei überlebt jedes Update und überschreibt die Standardwerte automatisch.
Fail2Ban richtig konfigurieren und abstimmen
Drei Parameter bestimmen das Verhalten von Fail2Ban maßgeblich. Der Wert maxretry legt fest, wie viele Fehlversuche toleriert werden. Mit findtime definiert der Administrator den Beobachtungszeitraum für diese Versuche. Die bantime bestimmt schließlich die Dauer der Sperre. Eine bewährte Konfiguration setzt maxretry auf 3, findtime auf 600 Sekunden und bantime auf mindestens 3600 Sekunden. Bei häufigen Angriffen empfiehlt sich sogar ein Wert von 86400 Sekunden – also ein ganzer Tag.
Neben den Grundeinstellungen verdient der Parameter ignoreip besondere Aufmerksamkeit. Hier trägt der Administrator die eigenen IP-Adressen ein, damit er sich nicht versehentlich selbst aussperrt. Der Status einzelner Jails lässt sich jederzeit per Kommandozeile abfragen. Fail2Ban zeigt dann die Anzahl gesperrter Adressen, fehlgeschlagener Versuche und überwachter Logdateien an. Trotz aller Stärken hat das Werkzeug eine Grenze: Gegen verteilte Angriffe aus Bot-Netzen mit tausenden wechselnden IPs stößt die einfache IP-Sperre an ihre Grenzen. Genau hier greifen ergänzende Maßnahmen.
SSH-Schlüssel statt Passwort: Public-Key-Authentifizierung einrichten
Die Authentifizierung per SSH-Schlüssel gilt als deutlich sicherer als ein klassisches Passwort. Das Verfahren basiert auf asymmetrischer Kryptografie mit einem Schlüsselpaar. Ein privater Schlüssel verbleibt geschützt auf dem eigenen Rechner. Der zugehörige öffentliche Schlüssel wird auf dem Server hinterlegt. Beim Verbindungsaufbau prüft der Server, ob der Client den passenden privaten Schlüssel besitzt. Ein Erraten oder Durchprobieren wie bei Passwörtern ist dadurch praktisch unmöglich.
Das Erstellen eines Schlüsselpaars erfolgt mit dem Befehl ssh-keygen. Empfehlenswert ist dabei ein RSA-Schlüssel mit 4096 Bit oder alternativ ein Ed25519-Schlüssel. Nach der Erzeugung überträgt der Befehl ssh-copy-id den öffentlichen Schlüssel bequem auf den Zielserver. Dort landet er in der Datei ~/.ssh/authorized_keys. Eine Passphrase für den privaten Schlüssel bietet eine weitere Schutzschicht. Selbst bei einem Diebstahl der Schlüsseldatei bleibt der Zugang ohne diese Passphrase gesperrt. Nach einem erfolgreichen Test der schlüsselbasierten Anmeldung folgt der nächste logische Schritt.
Passwort-Login deaktivieren und Key-Only erzwingen
/etc/ssh/sshd_config muss daher die Direktive PasswordAuthentication auf no gesetzt werden. Ebenso empfiehlt sich das Deaktivieren von ChallengeResponseAuthentication. Erst nach einem Neustart des SSH-Daemons greifen diese Änderungen.
Vor dem Deaktivieren der Passwort-Authentifizierung ist ein Test unbedingt notwendig. Am besten öffnet man eine zweite SSH-Sitzung, bevor die bestehende Verbindung geschlossen wird. Schlägt der Key-Login fehl, bleibt über die erste Sitzung noch Zugriff auf den Server erhalten. Seit Ubuntu 22.04 kann außerdem die Datei /etc/ssh/sshd_config.d/50-cloud-init.conf die eigenen Einstellungen überschreiben. Diese Datei sollte geprüft und gegebenenfalls angepasst werden. Mit deaktiviertem Passwort-Login verlieren sämtliche Wörterbuch-Attacken ihren Angriffspunkt.
SSH-Port ändern: Nutzen und Grenzen der Maßnahme
Das Verlegen des SSH-Dienstes auf einen anderen Port als den Standard-Port 22 gehört zu den meistdiskutierten Maßnahmen. Kritiker bezeichnen den Ansatz als reine „Security by Obscurity“ – also Sicherheit durch Verschleierung. Tatsächlich kann ein gezielter Portscan jeden beliebigen Port aufspüren. Dennoch zeigt die Praxis einen messbaren Effekt: Die Masse automatisierter Bots prüft ausschließlich Port 22. Nach einem Portwechsel sinken die Login-Versuche in den Logdateien oft von tausenden auf nahezu null pro Tag.
Beim Verlegen des Ports sollte ein Wert unter 1024 gewählt werden. Ports oberhalb dieser Grenze dürfen auch unprivilegierte Benutzer öffnen, was ein Sicherheitsrisiko darstellt. Die Anpassung erfolgt in der Datei sshd_config über die Direktive Port. Vor dem Entfernen des alten Ports muss die Firewall den neuen Port freigeben. Auch Fail2Ban benötigt eine Anpassung im Jail, damit es den geänderten Port überwacht. Das Ändern des Ports ersetzt keine echte Sicherheitsmaßnahme – es ergänzt sie lediglich. Ohne starke Schlüssel und ein aktives Fail2Ban bleibt ein Server verwundbar, egal auf welchem Port SSH lauscht.
Weitere Härtungsmaßnahmen für den SSH-Daemon
PermitRootLogin no unterbinden. Administratoren melden sich dann als unprivilegierter Benutzer an und wechseln erst danach per sudo auf Root-Rechte. Die Direktive AllowUsers oder AllowGroups beschränkt den Zugang auf bestimmte Konten. Mit MaxAuthTries begrenzt der Daemon die Anzahl erlaubter Anmeldeversuche pro Verbindung.
Auch die LoginGraceTime verdient Beachtung. Dieser Wert bestimmt, nach wie vielen Sekunden eine Verbindung ohne erfolgreichen Login getrennt wird. Ein Wert von 30 bis 60 Sekunden genügt in den meisten Fällen. Für maximale Sicherheit empfiehlt sich eine Kombination aller genannten Maßnahmen mit einem VPN-Zugang. Lösungen wie WireGuard oder IPsec verschlüsseln den gesamten Datenverkehr und verbergen den SSH-Dienst vollständig hinter einem Tunnel. Der SSH-Port muss dann nicht einmal öffentlich erreichbar sein. Jede zusätzliche Schicht erhöht den Aufwand für potenzielle Angreifer erheblich.
Fazit zum Absichern von SSH
