Ein frisch bestellter VPS bei Hetzner oder Netcup ist nach der Erstinstallation oft offen: Root-Login per Passwort, alle Ports erreichbar, und Bots starten innerhalb von Minuten die ersten Anmeldeversuche. Diese Anleitung zum Absichern und Härten eines VPS baut mit drei Bordmitteln eine Grundabsicherung auf: UFW-Firewall, schlüsselbasiertes SSH ohne Passwort und Brute-Force-Schutz mit Fail2Ban. Dazu lernen Sie, wie Sie sich im Notfall über die Webkonsole wieder Zugang verschaffen.

Was bedeutet „VPS härten“ und warum ist das wichtig?

Härten (englisch Hardening) heißt, die Angriffsfläche zu verkleinern: nur benötigte Dienste und Ports nach außen öffnen, die Anmeldung kryptografisch absichern und automatisierte Angreifer ausbremsen.

Die drei Bausteine dieser Anleitung greifen ineinander:

UFW (Uncomplicated Firewall) ist ein einfaches Frontend für iptables/nftables und kontrolliert, welcher Verkehr den Server erreicht.
SSH-Schlüssel ersetzen das Passwort durch ein kryptografisches Schlüsselpaar; ein 256-Bit-Ed25519-Schlüssel lässt sich praktisch nicht erraten.
Fail2Ban liest Logdateien mit und sperrt IP-Adressen automatisch, die zu oft fehlerhaft versuchen, sich anzumelden.

Jeder Server mit öffentlicher IPv4-Adresse wird rund um die Uhr nach offenem SSH gescannt und mit Standard-Zugangsdaten angegriffen. Ohne Schutz fällt ein schwaches Passwort früher oder später.

Voraussetzungen

Ein laufender VPS mit einer aktuellen Linux-Distribution (Beispiele hier für Ubuntu 24.04 LTS bzw. Debian 12, übertragbar auf andere Versionen).
Root-Zugriff oder ein Benutzer mit sudo-Rechten.
Zugang zum Hetzner- bzw. Netcup-Kundenpanel inklusive Web-/VNC-Konsole (wichtig als Rettungsanker, falls Sie sich aussperren).
Ein lokaler Rechner mit SSH-Client (Linux/macOS-Terminal oder unter Windows die PowerShell mit OpenSSH).
Die öffentliche IP-Adresse Ihres VPS aus dem Hosting-Panel.
Hardware: Die Härtung braucht kaum Ressourcen; jeder VPS ab 1 vCPU und 1 GB RAM genügt, x86 oder ARM. Den Bedarf bestimmen die späteren Dienste.

Schritt 1: System aktualisieren und Nicht-Root-Benutzer anlegen

Melden Sie sich per SSH an und bringen Sie das System auf den neuesten Stand; veraltete Pakete sind eine häufige Schwachstelle.

Mit dem Server verbinden (IP aus dem Panel einsetzen):

ssh root@IHRE_SERVER_IP

Paketquellen aktualisieren und Upgrades einspielen:

apt update && apt upgrade -y

Einen normalen Arbeitsbenutzer mit sudo-Rechten anlegen (ersetzen Sie marcel durch Ihren Namen):

adduser marcel
usermod -aG sudo marcel

Der eigene Benutzer ist nötig, weil Sie den direkten Root-Login gleich deaktivieren. Testen Sie in einem zweiten Terminal, dass er sich anmelden und sudo nutzen kann, bevor Sie weitermachen.

Verifizieren: id marcel listet die Gruppe sudo, und nach der Anmeldung als marcel gibt sudo whoami den Wert root aus. apt list --upgradable zeigt keine ausstehenden Pakete mehr.

Schritt 2: SSH-Schlüssel erstellen und auf den Server übertragen

Das Schlüsselpaar erzeugen Sie auf Ihrem lokalen Rechner; der private Schlüssel verlässt ihn nie.

Schlüsselpaar generieren

Lokal ein modernes Ed25519-Schlüsselpaar erzeugen:

ssh-keygen -t ed25519 -C "vps-hetzner"

Vergeben Sie eine starke Passphrase; sie schützt den privaten Schlüssel auch bei kompromittiertem Rechner.

Es entstehen zwei Dateien: ~/.ssh/id_ed25519 (privat, geheim halten) und ~/.ssh/id_ed25519.pub (öffentlich, darf auf den Server).

Public Key auf den Server kopieren

Unter Linux/macOS geht das am bequemsten mit ssh-copy-id:

ssh-copy-id marcel@IHRE_SERVER_IP

Unter Windows PowerShell gibt es ssh-copy-id nicht. Übertragen Sie den Public Key stattdessen so:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh marcel@IHRE_SERVER_IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Testen Sie den Schlüssel-Login. Abgefragt wird höchstens die Passphrase, nicht mehr das Server-Passwort:

ssh marcel@IHRE_SERVER_IP

Verifizieren: Die Anmeldung als marcel gelingt ohne Server-Passwort, und auf dem Server enthält cat ~/.ssh/authorized_keys eine Zeile, die mit ssh-ed25519 beginnt und mit Ihrem Kommentar vps-hetzner endet.

Erst wenn der Schlüssel-Login nachweislich klappt, schalten Sie die Passwort-Anmeldung ab. Andernfalls sperren Sie sich aus.

Öffnen Sie die SSH-Konfiguration auf dem Server:

sudo nano /etc/ssh/sshd_config

Setzen bzw. ändern Sie die folgenden Zeilen und entfernen Sie dabei eventuell vorhandene Rauten # am Zeilenanfang:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
UsePAM yes

Optional, aber empfehlenswert: Verschieben Sie SSH auf einen anderen Port (z. B. 2222), um das Grundrauschen automatisierter Scans zu reduzieren:

Port 2222

Speichern, schließen und den SSH-Dienst neu starten:

sudo systemctl restart ssh

Auf OpenSSH 9.x (Ubuntu 24.04, Debian 12) heißt die Option KbdInteractiveAuthentication no. Das in älteren Anleitungen genannte ChallengeResponseAuthentication no ist ein veralteter Alias, der weiter akzeptiert wird, aber ersetzt werden sollte.

Achtung bei Drop-in-Dateien: Ubuntu 24.04 und Debian 12 binden am Anfang der sshd_config alle Dateien aus /etc/ssh/sshd_config.d/ ein, und OpenSSH nutzt den zuerst gelesenen Wert. Steht dort etwa in einer Datei des Hoster-Images PasswordAuthentication yes, bleibt der Passwort-Login aktiv. Prüfen Sie mit grep -ri passwordauthentication /etc/ssh/sshd_config.d/ und passen Sie Treffer an.

Wichtig: Schließen Sie Ihre aktuelle SSH-Sitzung jetzt noch nicht. Öffnen Sie ein zweites Terminal und prüfen Sie, ob Sie sich neu verbinden können. Falls etwas schiefgeht, haben Sie noch die laufende Sitzung, um Fehler zu korrigieren.

Hinweis: Ubuntu 24.04 startet SSH per Socket-Aktivierung und liest den Port beim Laden der systemd-Konfiguration aus der sshd_config. Haben Sie den Port geändert, führen Sie dort zusätzlich sudo systemctl daemon-reload und sudo systemctl restart ssh.socket aus.

Verifizieren: sudo sshd -t gibt keine Fehlermeldung aus, und sudo sshd -T | grep -Ei '^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication) ' zeigt Ihren Port sowie permitrootlogin no, passwordauthentication no und kbdinteractiveauthentication no. Die Neuanmeldung im zweiten Terminal gelingt per Schlüssel.

Schritt 4: UFW-Firewall einrichten (Port 22 zuerst whitelisten!)

Häufigster Anfängerfehler bei der UFW Firewall: „alles blockieren“ und ufw enable, ohne vorher SSH freizugeben. Das sperrt Sie sofort aus. Halten Sie diese Reihenfolge strikt ein.

UFW installieren (auf vielen Distributionen bereits vorhanden):

sudo apt install ufw -y

Standardregeln setzen: eingehend alles verbieten, ausgehend alles erlauben:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Zuerst SSH freigeben - bei Standard-Port 22:

sudo ufw allow 22/tcp

Falls Sie in Schritt 3 auf Port 2222 gewechselt sind, stattdessen:

sudo ufw allow 2222/tcp

Bei Bedarf weitere Dienste öffnen, z. B. einen Webserver:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Erst jetzt die Firewall aktivieren:

sudo ufw enable

Status und Regeln kontrollieren:

sudo ufw status verbose

Die Ausgabe sollte Default: deny (incoming), allow (outgoing) zeigen und Ihren SSH-Port als ALLOW listen.

Verifizieren: sudo ufw status verbose meldet Status: active, die Standardregel deny (incoming) und Ihren SSH-Port mit ALLOW IN. Eine neue SSH-Verbindung aus einem zweiten Terminal gelingt weiterhin.

Schritt 5: Fail2Ban gegen SSH-Brute-Force installieren

Fail2Ban erkennt wiederholte Fehlanmeldungen und sperrt die IP automatisch für eine festgelegte Zeit. Das bremst Brute-Force-Versuche auch über erlaubte Verbindungen aus.

Fail2Ban installieren:

sudo apt install fail2ban -y

Legen Sie eine eigene Konfiguration jail.local an. Diese Datei überschreibt nie die mitgelieferte jail.conf und bleibt bei Updates erhalten:

sudo nano /etc/fail2ban/jail.local

Tragen Sie folgende Konfiguration ein (bei abweichendem SSH-Port den port anpassen):

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
backend = systemd

[sshd]
enabled = true
port = 22
maxretry = 3

Dienst aktivieren und starten:

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Damit wird eine IP nach maxretry = 3 Fehlversuchen innerhalb von findtime = 600 Sekunden für bantime = 3600 (eine Stunde) gesperrt. Für strengere Sperren erhöhen Sie bantime oder nutzen bantime.increment = true.

Verifizieren: systemctl is-active fail2ban antwortet mit active, und sudo fail2ban-client status listet unter Jail list den Eintrag sshd.

Schritt 6: Verifikation - der erste Sicherheitstest

Prüfen Sie abschließend, dass alle drei Schutzschichten greifen.

Firewall-Regeln kontrollieren:

sudo ufw status numbered

Fail2Ban-Status und aktive Sperren für den SSH-Filter anzeigen:

sudo fail2ban-client status sshd

Die Ausgabe listet Currently banned und Total banned. Hier tauchen mit der Zeit die geblockten Bot-IPs auf.
Testen Sie den Passwort-Login: Ein Verbindungsversuch, der Passwort statt Schlüssel erzwingt, muss scheitern:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no marcel@IHRE_SERVER_IP

Erwartetes Ergebnis: Permission denied (publickey). Genau so soll es sein.
Prüfen Sie, dass der Root-Login per SSH abgelehnt wird:

ssh root@IHRE_SERVER_IP

Wenn der Schlüssel-Login funktioniert, Passwort- und Root-Login scheitern und UFW nur Ihre erlaubten Ports zeigt, ist die Grundabsicherung erfolgreich.

Verifizieren: Der Passwort-Test endet mit Permission denied (publickey), der Root-Login ebenfalls mit Permission denied, und sudo ufw status numbered enthält nur die Ports, die Sie bewusst freigegeben haben.

Updates und Wartung

Sicherheit ist kein einmaliger Vorgang. Halten Sie den Server dauerhaft gepflegt:

Regelmäßig manuell aktualisieren mit sudo apt update && sudo apt upgrade -y.
Für automatische Sicherheitsupdates das Paket unattended-upgrades einrichten:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Nach jedem Distributions-Upgrade die SSH-, UFW- und Fail2Ban-Konfiguration erneut prüfen, da Update-Routinen Konfigurationsdateien ersetzen können.

Backup nicht vergessen

Härtung schützt nicht vor Datenverlust durch Fehlbedienung, defekte Datenträger oder Ransomware. Aktivieren Sie die Snapshots/Backups Ihres Hosters (Hetzner und Netcup bieten das im Kundenpanel) und sichern Sie wichtige Konfigurationen und Datenbanken zusätzlich extern, nach der 3-2-1-Regel (drei Kopien, zwei Medien, eine außer Haus).

Troubleshooting

Komplett ausgesperrt? Die Web-/VNC-Konsole im Hetzner- bzw. Netcup-Panel verbindet Sie unabhängig von SSH und UFW. Melden Sie sich mit dem Passwort Ihres sudo-Benutzers (oder eines gesetzten Root-Passworts) an und lösen Sie die Sperre mit sudo ufw allow 22/tcp bzw. sudo ufw disable.
Eigene IP versehentlich gebannt? Heben Sie die Sperre auf mit sudo fail2ban-client set sshd unbanip IHRE_IP. Tragen Sie Ihre feste Heim-IP optional in jail.local unter ignoreip = 127.0.0.1/8 ::1 IHRE_IP ein.
SSH-Verbindung abgelehnt nach Portwechsel? Verbinden Sie sich explizit mit dem neuen Port: ssh -p 2222 marcel@IHRE_SERVER_IP und stellen Sie sicher, dass UFW genau diesen Port erlaubt.
„Permission denied (publickey)“ trotz Schlüssel? Prüfen Sie die Rechte: ~/.ssh muss 700, ~/.ssh/authorized_keys muss 600 und dem Benutzer gehören.
Fail2Ban startet nicht? Auf Systemd-Distributionen ist backend = systemd nötig. Logs ansehen mit sudo journalctl -u fail2ban -e.

Häufige Fragen

Brauche ich Fail2Ban überhaupt, wenn ich SSH-Keys nutze?

Ohne Passwort-Login ist Brute-Force gegen SSH praktisch chancenlos. Fail2Ban reduziert trotzdem das Log-Rauschen, blockt aufdringliche Scanner und schützt mit eigenen Jails auch Webserver, Mailserver oder Webanwendungen.

Warum Ed25519 statt RSA für den SSH-Schlüssel?

Ed25519 bietet bei kurzer Schlüssellänge sehr hohe Sicherheit, ist schnell und wird von allen aktuellen OpenSSH-Versionen unterstützt; für neue Setups die empfohlene Wahl. RSA sollte mindestens 4096 Bit haben (ssh-keygen -t rsa -b 4096).

Sollte ich den SSH-Port wirklich ändern?

Ein anderer Port ist Verschleierung (Security through Obscurity) und ersetzt keine Härtung, senkt aber spürbar die automatisierten Anmeldeversuche in den Logs. Ein nützlicher Zusatz, kein Muss.

Was passiert, wenn ich mich komplett aussperre?

Dafür gibt es die Web- bzw. VNC-Konsole im Kundenpanel (siehe Troubleshooting). Testen Sie den Konsolen-Zugang einmal, bevor Sie mit der Härtung beginnen.

Ist diese Absicherung für einen Produktivserver ausreichend?

Sie ist eine Grundabsicherung gegen die häufigsten automatisierten Angriffe. Für produktive Systeme kommen je nach Anwendung Backups, Monitoring, Reverse-Proxy mit TLS, Intrusion Detection, regelmäßige Audits und ein Rechtekonzept hinzu.

Fazit

Merksatz: erst den SSH-Port freigeben, dann UFW aktivieren, und den Passwort-Login erst abschalten, wenn der Schlüssel-Login nachweislich funktioniert. Die Webkonsole des Hosters ist Ihr Sicherheitsnetz. Auf dieser Basis geben Sie weitere Dienste gezielt frei.

Weiterführende Anleitungen und Quellen

Wer auf dem so abgesicherten Server Dienste betreiben will, findet im s-edv-Bestand passende Anleitungen: vom Einrichten von Docker über das Selbsthosten von Bitwarden/Vaultwarden mit Nginx Proxy Manager bis zum Monitoring mit Uptime Kuma. Wer SSH noch weiter absichern will, findet Match-Blöcke und die Prüfung mit ssh-audit im SSH-Hardening Deep-Dive. Mehr Tutorials finden Sie in unserer Kategorie Cloud.

Quellen: Ubuntu Community Help - UFW, Fail2Ban auf GitHub und die offizielle OpenSSH sshd_config-Dokumentation.