SSH-Härtung für Heimserver – von schlüsselbasierter Authentifizierung bis fail2ban

Vor einiger Zeit öffnete ich untätig das SSH-Protokoll auf meinem Heimserver – einem gebrauchten Laptop, den ich als Server in der Ecke meines Zimmers benutzte. Was ich fand, war ziemlich augenöffnend: Hunderte von Anmeldeversuchen von ausländischen IPs jeden Tag. Jeder hat klassische Benutzernamenkombinationen wie root, admin, ubuntu ausprobiert und dann blind das Passwort erraten. Mein Server verwendet nicht einmal den Standard-Port 22, aber Bots im Internet finden ihn trotzdem.

Hier wurde es mir klar: Die Installation von SSH auf einem Server ist wie die Installation einer Tür an einem Haus. Eine Tür allein reicht nicht aus – Sie brauchen ein gutes Schloss und bei Bedarf auch eine Überwachungskamera. Dieser Artikel fasst die Schritte zur SSH-Härtung zusammen, die ich selbst implementiert habe: schlüsselbasierte Authentifizierung, fail2ban und einige kleine Konfigurationen, die eine große Wirkung hatten.

Warum reicht ein Passwort allein nicht aus?

Ein Passwort ist wie ein Schloss mit Zahlenschloss. Solange das Schloss komplex genug ist, ist es theoretisch sicher. Das Problem ist, dass es im Internet Tausende von Bots gibt, deren Aufgabe nur eine ist: ständig, unermüdlich und ohne Bezahlung alle Kombinationen auszuprobieren. Dies wird als Brute-Force-Angriff bezeichnet.

Stellen Sie sich einen Fremden vor, der vor Ihrem Zaun steht und einen nach dem anderen an einem riesigen Schlüsselbund mit Millionen von Schlüsseln probiert. Vielleicht schafft er es heute nicht. Aber wenn er ein Jahr dort bleibt, steigen seine Chancen stetig. Vor allem, wenn Sie ein „ziemlich häufiges“ Passwort verwenden – Geburtsdatum, Name der Freundin oder P@ssw0rd123.

Die eleganteste Lösung: Ersetzen Sie Zahlenschlösser durch Schlösser, die nur mit einem einzigen physischen Schlüssel geöffnet werden können – und dieser Schlüssel kann nicht erraten, nicht fotografiert werden, nicht anhand der Form des Schlosses erraten werden. Das ist schlüsselbasierte Authentifizierung.

Schritt 1: Schlüsselbasierte Authentifizierung

SSH-Schlüssel bestehen aus einem Dateipaar: privater Schlüssel (der Schlüssel, den Sie sicher auf Ihrem Computer speichern) und öffentlicher Schlüssel (das Schloss, das Sie auf dem Server installieren). Der Server öffnet die Tür nur denjenigen, die über einen passenden privaten Schlüssel verfügen – und es ist praktisch unmöglich, den privaten Schlüssel mit roher Gewalt zu erraten, da der Raum der Möglichkeiten astronomisch ist.

Generieren Sie auf dem Client-Computer (Laptop/PC, den Sie normalerweise für SSH verwenden) das Schlüsselpaar:

ssh-keygen -t ed25519 -C "adam@laptop-utama"

Ich empfehle ed25519 gegenüber RSA – kürzer, schneller und moderner. Wenn Sie nach einer Passphrase gefragt werden, geben Sie diese ein. Diese Passphrase stellt eine zusätzliche Sicherheitsebene dar: Wenn Ihr privater Schlüssel gestohlen wird, benötigt der Dieb immer noch die Passphrase, um ihn verwenden zu können.

Senden Sie dann den öffentlichen Schlüssel an den Server:

ssh-copy-id -p 6393 [email protected]

Oder wenn ssh-copy-id nicht verfügbar ist, machen Sie es manuell:

cat ~/.ssh/id_ed25519.pub | ssh -p 6393 [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Testen Sie zunächst die Anmeldung mit dem Schlüssel im neuen Terminal. Schließen Sie keine aktive SSH-Sitzung – das ist die goldene Regel beim Öffnen von SSH. Wenn die Konfiguration falsch ist, bleibt Ihnen immer noch die Möglichkeit, das Problem zu beheben.

Schritt 2: Anmeldekennwort deaktivieren

Sobald die schlüsselbasierte Authentifizierung reibungslos funktioniert, ist es an der Zeit, das alte Zahlenschloss zu entfernen. Bearbeiten Sie die SSH-Serverkonfiguration in /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PermitRootLogin no
MaxAuthTries 3

Kurze Erklärung:

• PasswordAuthentication no – Brute-Force-Passwort wird sofort irrelevant. Bots können Millionen von Kombinationen ausprobieren, der Server wird nie danach fragen.
• PermitRootLogin no – Erlauben Sie niemals die direkte Anmeldung als Root. Melden Sie sich als normaler Benutzer an, dann sudo. Wenn es jemandem gelingt, einzutreten, wird er zumindest nicht sofort König.
• MaxAuthTries 3 – Versuche pro Verbindung begrenzen. Verlangsamt Angreifer und sorgt für sauberere Protokolle.

SSH-Dienst neu laden:

sudo systemctl reload ssh

Noch einmal: Testen Sie die Anmeldung am neuen Terminal, bevor Sie die alte Sitzung schließen.

Schritt 3: fail2ban – Automatisierter Sicherheitswächter

Die schlüsselbasierte Authentifizierung macht es Brute-Force-Angriffen unmöglich, erfolgreich zu sein, aber die Bots füllen trotzdem Protokolle und verschwenden Ressourcen. Hier kommt fail2ban ins Spiel – so wie ein Wachmann das Gesicht der Person bemerkt, die dreimal den falschen Schlüssel ausprobiert hat, und ihm dann eine Stunde lang den Zutritt verbietet.

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Bearbeiten Sie die Abschnitte /etc/fail2ban/jail.local und [sshd]:

[sshd]
enabled = true
port = 6393
maxretry = 3
findtime = 600
bantime = 3600

Das bedeutet: Wenn sich eine IP innerhalb von 10 Minuten dreimal nicht anmelden kann (findtime), blockieren Sie diese IP für 1 Stunde (bantime). Vergessen Sie nicht, port anzupassen, wenn Sie einen benutzerdefinierten Port wie meinen verwenden.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Der letzte Befehl zeigt Gefängnisstatistiken an: wie viele IPs derzeit blockiert sind, wie viele insgesamt blockiert wurden. Es ist sehr befriedigend, diese Liste zu sehen.

Schritt 4: Benutzerdefinierter Port – Sicherheit durch Unsichtbarkeit

Das Verschieben von SSH von Port 22 auf einen anderen Port (ich verwende 6393) wird oft diskutiert. Kritiker sagen, es gehe um „Sicherheit durch Unklarheit“ – und sie haben Recht, es ist nicht der ultimative Sicherheitsmechanismus. Aber um das Ganze abzurunden, war der Effekt real: Mein Protokoll, das zuvor Hunderte von Anmeldeversuchen pro Tag enthielt, sank drastisch.

Die Analogie ist, als würde man die Tür eines Hauses von der Seite der Hauptstraße in eine kleine Gasse verlegen. Die Zäune und Vorhängeschlösser schützen immer noch – aber zumindest versucht nicht jeder, der vorbeikommt, die Türklinke zu betätigen.

# di /etc/ssh/sshd_config
Port 6393

Vergessen Sie nicht, einen neuen Port in der Firewall zu öffnen, bevor Port 22 schließt, und stellen Sie sicher, dass Ihr neuer Port nicht mit anderen Diensten in Konflikt gerät.

Schritt 5: Begrenzen Sie, wer teilnehmen darf

Zwei zusätzliche Sicherheitsmaßnahmen, die eine Überlegung wert sind:

Benutzer einschränken – Erlauben Sie nur bestimmten Benutzern SSH:

# di /etc/ssh/sshd_config
AllowUsers adam

IP-Einschränkung – wenn Sie nur von einem bestimmten Netzwerk aus zugreifen (zum Beispiel nur von Ihrem Heim-LAN oder über VPN wie WireGuard/Tailscale), beschränken Sie es auf Firewall-Ebene mit nftables:

sudo nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 6393 accept
sudo nft add rule inet filter input tcp dport 6393 drop

Damit ist der SSH-Port nicht einmal von außerhalb des Netzwerks sichtbar. Aber Vorsicht: Wenn Sie nicht zu Hause sind und Ihr VPN Probleme hat, kann es sein, dass Sie von Ihrem eigenen Server ausgeschlossen werden. Haben Sie immer einen Backup-Plan – ich selbst verlasse mich auf Cloudflare-Tunnel als alternative Route.

Abschließende Checkliste

• Schlüsselbasierte Authentifizierung ist aktiv, Passwortanmeldung ist deaktiviert
• PermitRootLogin no
• fail2ban läuft und jail sshd aktiv
• Benutzerdefinierter Port (optional, löscht aber Protokolle)
• AllowUsers und/oder IP-Einschränkungen in der Firewall
• Die alte SSH-Sitzung bleibt geöffnet, bis alle Konfigurationen nachweislich funktionieren

Schließung

SSH-Härtung ist keine einmalige Aufgabe. Es ist eher so, als würde man sich um den Hauszaun kümmern: Überprüfen Sie gelegentlich die Protokolle (journalctl -u ssh), sehen Sie, wer fail2ban blockiert hat, und stellen Sie sicher, dass sich die Konfiguration nach einem Systemupdate nicht geändert hat. Die oben genannten fünf Schritte reichen aus, um Ihren kleinen Server zu einem unattraktiven Ziel zu machen – Bots werden aufgeben und zu einem anderen Opfer übergehen, dessen Tür noch über ein Zahlenschloss verfügt.

Wenn Sie weitere Härtungstipps haben, die sich auf Ihrem Heimserver als wirksam erwiesen haben, teilen Sie diese bitte in der Kommentarspalte mit. Praxiserfahrung ist immer wertvoller als Theorie.