Ein frisch bestellter VPS bei Hetzner oder Netcup ist nach der Erstinstallation oft erschreckend offen: Root-Login per Passwort, alle Ports erreichbar und automatisierte Bots, die innerhalb von Minuten die ersten Anmeldeversuche starten. Diese VPS absichern und härten Anleitung zeigt dir als Einsteiger Schritt für Schritt, wie du mit drei bewährten Bordmitteln eine solide Grundabsicherung aufbaust: der UFW-Firewall, schlüsselbasiertem SSH ohne Passwort und dem Brute-Force-Schutz Fail2Ban. Am Ende ist dein Server gegen die häufigsten automatisierten Angriffe gehärtet - und du weißt, wie du dich im Notfall über die Webkonsole nicht selbst aussperrst.

Kurzfassung: SSH-Schlüssel mit ssh-keygen -t ed25519 erstellen, Public Key auf den Server kopieren, dann PasswordAuthentication no und PermitRootLogin no setzen. UFW mit default deny incoming konfigurieren, aber unbedingt vorher Port 22 (oder deinen SSH-Port) freigeben. Zum Schluss Fail2Ban mit maxretry=3 und bantime=3600 aktivieren.

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

Unter Härten (englisch Hardening) versteht man, die Angriffsfläche eines Systems systematisch zu verkleinern. Bei einem Linux-VPS heißt das konkret: nur die Dienste und Ports nach außen öffnen, die du wirklich brauchst, die Anmeldung am Server kryptografisch absichern und automatisierte Angreifer ausbremsen.

Die drei Bausteine dieser Anleitung greifen ineinander:

UFW (Uncomplicated Firewall) ist ein einfaches Frontend für iptables/nftables. Es kontrolliert, welcher Netzwerkverkehr deinen Server überhaupt erreichen darf.
SSH-Schlüssel ersetzen das Passwort durch ein kryptografisches Schlüsselpaar. Ein 256-Bit-Ed25519-Schlüssel lässt sich praktisch nicht erraten - im Gegensatz zu einem Passwort.
Fail2Ban liest Logdateien mit und sperrt IP-Adressen automatisch, die zu oft fehlerhaft versuchen, sich anzumelden.

Warum das Ganze? Sobald ein Server eine öffentliche IPv4-Adresse hat, scannen ihn Bots rund um die Uhr nach offenem SSH und probieren Standard-Zugangsdaten durch. Ohne Schutz ist das nur eine Frage der Zeit, bis ein schwaches Passwort fällt.

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 du dich aussperrst).
Ein lokaler Rechner mit SSH-Client (Linux/macOS-Terminal oder unter Windows die PowerShell mit OpenSSH).
Die öffentliche IP-Adresse deines VPS aus dem Hosting-Panel.

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

Melde dich zunächst per SSH am Server an und bring das System auf den neuesten Stand. Veraltete Pakete sind eine der häufigsten Schwachstellen.

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

ssh root@DEINE_SERVER_IP

Paketquellen aktualisieren und Upgrades einspielen:

apt update && apt upgrade -y

Einen normalen Arbeitsbenutzer mit sudo-Rechten anlegen (ersetze marcel durch deinen Namen):

adduser marcel
usermod -aG sudo marcel

Der eigene Benutzer ist wichtig, weil wir gleich den direkten Root-Login per SSH deaktivieren. Teste in einem zweiten Terminal, dass der neue Benutzer sich anmelden und sudo nutzen kann, bevor du weitermachst.

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

Das Schlüsselpaar erzeugst du immer auf deinem lokalen Rechner, nicht auf dem Server. Der private Schlüssel verlässt deinen Rechner nie.

Schlüsselpaar generieren

Lokal ein modernes Ed25519-Schlüsselpaar erzeugen:

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

Wenn du gefragt wirst, vergib eine starke Passphrase für den privaten Schlüssel - so ist er auch dann geschützt, wenn jemand deinen Rechner kompromittiert.

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@DEINE_SERVER_IP

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

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

Teste anschließend, dass der Login per Schlüssel funktioniert - du solltest jetzt höchstens nach der Passphrase, aber nicht mehr nach dem Server-Passwort gefragt werden:

ssh marcel@DEINE_SERVER_IP

Erst wenn der Schlüssel-Login nachweislich klappt, schaltest du die Passwort-Anmeldung ab. Andernfalls sperrst du dich aus.

Öffne die SSH-Konfiguration auf dem Server:

sudo nano /etc/ssh/sshd_config

Setze (bzw. ändere) die folgenden Zeilen - entferne dabei eventuell vorhandene Rauten # am Zeilenanfang:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
UsePAM yes

Optional, aber empfehlenswert: Verschiebe 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

Hinweis zum Keyword: Auf aktuellen Systemen mit OpenSSH 9.x (Ubuntu 24.04, Debian 12) heißt die Option KbdInteractiveAuthentication no. Ältere Anleitungen nennen stattdessen ChallengeResponseAuthentication no - das ist nur noch ein veralteter Alias, der bei neuen Versionen weiterhin akzeptiert wird, aber durch das obige Keyword ersetzt werden sollte.

Wichtig: Schließe deine aktuelle SSH-Sitzung jetzt noch nicht. Öffne ein zweites Terminal und prüfe, ob du dich neu verbinden kannst. Falls etwas schiefgeht, hast du noch die laufende Sitzung, um Fehler zu korrigieren.

Hinweis: Auf neueren Systemen mit Socket-Aktivierung (Ubuntu 24.04) kann zusätzlich sudo systemctl restart ssh.socket nötig sein, wenn du den Port geändert hast.

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

Jetzt konfigurierst du die UFW Firewall. Der mit Abstand häufigste Anfängerfehler ist, die Firewall auf "alles blockieren" zu stellen und dann ufw enable auszuführen, ohne vorher SSH freigegeben zu haben - das Ergebnis ist eine sofortige Aussperrung. Halte deshalb 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 du in Schritt 3 auf Port 2222 gewechselt bist, 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 deinen SSH-Port als ALLOW listen.

Schritt 5: Fail2Ban gegen SSH-Brute-Force installieren

Fail2Ban ergänzt die Firewall um eine dynamische Komponente: Es erkennt wiederholte Fehlanmeldungen und sperrt die betreffende IP automatisch für eine festgelegte Zeit. So bremst du auch verteilte Brute-Force-Versuche aus, die einzelne erlaubte Verbindungen ausnutzen.

Fail2Ban installieren:

sudo apt install fail2ban -y

Lege 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

Trage 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

Mit bantime = 3600 wird eine IP nach maxretry = 3 Fehlversuchen innerhalb von findtime = 600 Sekunden für eine Stunde gesperrt. Wer das aggressiver mag, erhöht bantime oder nutzt bantime.increment = true für progressiv längere Sperren.

Schritt 6: Verifikation - der erste Sicherheitstest

Prüfe 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.
Teste den Passwort-Login: Ein Verbindungsversuch, der Passwort statt Schlüssel erzwingt, muss scheitern:

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

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

ssh root@DEINE_SERVER_IP

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

Updates und Wartung

Sicherheit ist kein einmaliger Vorgang. Halte 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. Aktiviere die Snapshots/Backups deines Hosters (Hetzner und Netcup bieten kostenpflichtige automatische Backups) und sichere zusätzlich wichtige Konfigurationen und Datenbanken regelmäßig extern. Eine 3-2-1-Strategie - drei Kopien, zwei Medien, eine außer Haus - ist auch für einen kleinen VPS sinnvoll.

Troubleshooting

Komplett ausgesperrt? Nutze die Web-/VNC-Konsole im Hetzner- bzw. Netcup-Panel. Diese verbindet dich unabhängig von SSH und UFW direkt mit dem Server. Dort kannst du dich mit Passwort am Root-Konto anmelden und mit sudo ufw allow 22/tcp bzw. sudo ufw disable die Sperre lösen.
Eigene IP versehentlich gebannt? Hebe die Sperre auf mit sudo fail2ban-client set sshd unbanip DEINE_IP. Trage deine feste Heim-IP optional in jail.local unter ignoreip = 127.0.0.1/8 ::1 DEINE_IP ein.
SSH-Verbindung abgelehnt nach Portwechsel? Verbinde dich explizit mit dem neuen Port: ssh -p 2222 marcel@DEINE_SERVER_IP und stelle sicher, dass UFW genau diesen Port erlaubt.
"Permission denied (publickey)" trotz Schlüssel? Prüfe 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?

Mit deaktiviertem Passwort-Login ist Brute-Force gegen SSH praktisch chancenlos. Fail2Ban bleibt trotzdem sinnvoll: Es reduziert das Log-Rauschen, blockt aufdringliche Scanner und schützt zusätzlich andere Dienste wie Webserver, Mailserver oder Webanwendungen, sobald du dafür eigene Jails einrichtest.

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. RSA funktioniert weiterhin, sollte dann aber mindestens 4096 Bit haben (ssh-keygen -t rsa -b 4096). Für neue Setups ist Ed25519 die empfohlene Wahl.

Sollte ich den SSH-Port wirklich ändern?

Ein anderer Port ist reine Verschleierung (Security through Obscurity) und ersetzt keine echte Härtung. Er senkt aber spürbar die Menge automatisierter Anmeldeversuche in den Logs. Als Ergänzung zu Keys, UFW und Fail2Ban ist es ein nützlicher, harmloser Zusatz - aber kein Muss.

Was passiert, wenn ich mich komplett aussperre?

Genau dafür gibt es die Web- bzw. VNC-Konsole im Kundenpanel von Hetzner und Netcup. Sie funktioniert unabhängig von SSH und Firewall, sodass du dich immer als Root am System anmelden und Fehlkonfigurationen rückgängig machen kannst. Teste den Konsolen-Zugang am besten einmal, bevor du die Härtung startest.

Ist diese Absicherung für einen Produktivserver ausreichend?

Sie ist eine solide Grundabsicherung und deckt die häufigsten automatisierten Angriffe ab. Für produktive Systeme kommen je nach Anwendung weitere Maßnahmen hinzu: separate Backups, Monitoring, Reverse-Proxy mit TLS, Intrusion Detection, regelmäßige Audits und ein durchdachtes Rechtekonzept.

Fazit

Mit UFW, schlüsselbasiertem SSH und Fail2Ban hast du deinen VPS bei Hetzner oder Netcup in wenigen Schritten gegen die mit Abstand häufigsten Angriffe gehärtet. Der wichtigste Merksatz dieser VPS absichern und härten Anleitung: immer erst Port 22 freigeben, bevor du UFW aktivierst, und den Passwort-Login erst abschalten, wenn der Schlüssel-Login nachweislich funktioniert. Die Webkonsole deines Hosters ist dein Sicherheitsnetz, falls doch einmal etwas schiefgeht. Auf dieser Basis kannst du anschließend gezielt weitere Dienste freigeben und absichern.

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 über die Infrastruktur-Strategie nachdenkt, sollte auch unseren Beitrag zur AWS European Sovereign Cloud mit SAP und EC2 G6 lesen. Mehr Tutorials findest du in unserer Kategorie Cloud.

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