Erster eigener Cloud-Server: VPS bei Hetzner oder Netcup aufsetzen und absichern

Wer zum ersten Mal einen eigenen virtuellen Server (VPS) in Betrieb nimmt, steht schnell vor einem Problem: Es gibt zahlreiche Anleitungen für Einzelschritte – SSH-Keys, Firewalls, fail2ban – aber kaum eine, die den vollständigen Weg in der richtigen Reihenfolge beschreibt. Genau das leistet diese Anleitung. Du wählst einen Provider (Hetzner Cloud oder Netcup), bestellst deinen ersten Server, loggst dich ein und absicherst ihn Schritt für Schritt so, dass er dauerhaft zuverlässig und sicher läuft – inklusive DACH-spezifischer Details, Kostenfallen und dem Defense-in-Depth-Prinzip.

Voraussetzungen

1. Hetzner Cloud Konto (cloud.hetzner.com) oder Netcup Kundenkonto (netcup.de) mit Zahlungsmethode (Kreditkarte oder SEPA-Lastschrift)
2. Lokaler SSH-Client: unter Linux/macOS bereits vorhanden; unter Windows: Windows Terminal mit eingebautem OpenSSH oder PuTTY
3. Ed25519-SSH-Schlüsselpaar lokal generiert (Anleitung: SSH-Key-Authentifizierung einrichten)
4. Optional: eigener Domainname, dessen A-Record du auf die Server-IP setzen kannst (für rDNS/PTR)
5. E-Mail-Adresse für unattended-upgrades-Benachrichtigungen
6. Ca. 90 Minuten Zeit für das vollständige Setup

Schritt 1: Provider wählen – Hetzner Cloud oder Netcup?

Beide Provider betreiben ihre Rechenzentren in Deutschland und erfüllen die DSGVO-Anforderungen. Die Entscheidung hängt von deinem Anwendungsfall ab. Die folgende Tabelle zeigt die relevanten Unterschiede für Einsteiger:

Stand: 12.06.2026. Grundlage sind die offiziellen Tarifseiten von Hetzner Cloud und netcup. Die früher genannten Modelle CX22, CX32 und VPS 1000 G11 sind dort aktuell nicht mehr die sichtbare Referenz für Neukunden. Preise und Steuerdarstellung können je nach Standort, MwSt. und Aktionszeitraum abweichen.

Empfehlung für Einsteiger: Hetzner Cloud bietet die bessere Dokumentation, eine moderne REST-API mit dem hcloud-CLI-Tool und stundengenaue Abrechnung ohne Mindestlaufzeit – ideal für schnelles Ausprobieren und automatisierte Setups. Netcup punktet mit besserem RAM-pro-Euro-Verhältnis und unlimitiertem Traffic – gut für Dauerläufer-Server mit hohem Datenvolumen. Für deinen ersten VPS empfiehlt sich Hetzner Cloud wegen der reibungsloseren Onboarding-Erfahrung. Aktuelle Preise immer direkt beim Provider prüfen.

Verifizieren: Du hast ein aktives Konto beim gewählten Provider, eine Zahlungsmethode hinterlegt und kannst dich in der Cloud-Konsole (Hetzner) bzw. im SCP (Netcup) anmelden.

Schritt 2: Server bestellen und SSH-Key hinterlegen

Bevor du den Server bestellst, solltest du deinen SSH-Key bereits lokal generiert haben. Falls nicht, erstelle ihn jetzt auf deinem lokalen Rechner (nicht auf dem Server):

ssh-keygen -t ed25519 -a 64 -C "adminname@meinedomain.de"

Der öffentliche Schlüssel liegt danach unter ~/.ssh/id_ed25519.pub.

Bei Hetzner Cloud: Gehe zu „SSH Keys" im Panel und füge den Inhalt von id_ed25519.pub hinzu. Beim Erstellen des Servers wählst du unter „Authentication" diesen Key aus – Hetzner trägt ihn automatisch in /root/.ssh/authorized_keys ein. Als Image wählst du Ubuntu 24.04 LTS (Support bis April 2029). Für ein vollautomatisches Setup kannst du im Feld „User Data" ein cloud-init-YAML eintragen (max. 32 KiB), das beim ersten Start ausgeführt wird. Achtung: User-Data wird nur einmalig beim ersten Boot ausgeführt – Änderungen nach der Server-Erstellung haben keine Wirkung.

Bei Netcup: Das Root-Passwort kommt per E-Mail („Ihr vServer ist bereit gestellt"), die SCP-Zugangsdaten per separater Mail. Den SSH-Key kannst du im SCP unter „Option" speichern – er wird aber nur bei einer Neu-Installation via Image eingespielt. Wird der Key nach der Installation gespeichert, ist er auf dem laufenden Server nicht aktiv und muss manuell übertragen werden.

Verifizieren: Der Server erscheint im Panel als „Running" mit zugewiesener IPv4-Adresse. Bei Hetzner ist unter „SSH Keys" dein Public Key eingetragen.

Schritt 3: Erster Login und System aktualisieren

Logge dich als root ein und führe sofort ein vollständiges System-Update durch – bevor du irgendetwas anderes tust:

# Erster Login (Hetzner: per SSH-Key; Netcup: per Passwort aus der E-Mail)
ssh root@<SERVER-IP>

# System sofort aktualisieren
apt update && apt upgrade -y && apt autoremove -y

Falls apt upgrade meldet, dass ein Neustart erforderlich ist (z. B. nach einem Kernel-Update), führe ihn jetzt durch:

reboot

Nach dem Neustart erneut einloggen:

ssh root@<SERVER-IP>

Verifizieren: Das Update läuft ohne Fehler durch. Prüfe die installierte Ubuntu-Version:

lsb_release -a

Erwartete Ausgabe: Description: Ubuntu 24.04.x LTS

Schritt 4: Admin-User anlegen und SSH-Key übertragen

Arbeite niemals dauerhaft als root. Lege jetzt einen Admin-User mit sudo-Rechten an:

# Admin-User anlegen (ersetze "adminname" durch deinen gewünschten Benutzernamen)
adduser adminname
usermod -aG sudo adminname

Übertrage deinen SSH-Public-Key auf den neuen User. Der einfachste Weg von deinem lokalen Rechner aus:

# Auf deinem lokalen Rechner ausführen:
ssh-copy-id adminname@<SERVER-IP>

Alternativ manuell auf dem Server:

# Auf dem Server als root:
mkdir -p /home/adminname/.ssh
chmod 700 /home/adminname/.ssh
cat /root/.ssh/authorized_keys >> /home/adminname/.ssh/authorized_keys
chmod 600 /home/adminname/.ssh/authorized_keys
chown -R adminname:adminname /home/adminname/.ssh

Verifizieren: Öffne eine neue, zweite SSH-Session (die aktuelle Root-Session offen lassen!) und logge dich als adminname ein:

ssh adminname@<SERVER-IP>

Erwartetes Ergebnis: Login gelingt ohne Passwort-Eingabe. Teste auch sudo:

sudo whoami

Erwartete Ausgabe: root. Erst wenn dieser Test erfolgreich ist, weiter zu Schritt 5.

Schritt 5: SSH-Daemon absichern und Root-Login deaktivieren

Kritisch: Halte die Root-Session und die Admin-Session aus Schritt 4 beide geöffnet, solange du an der SSH-Konfiguration arbeitest. Erst nach erfolgreichem Test schließen.

Bearbeite die SSH-Konfiguration:

sudo nano /etc/ssh/sshd_config

Setze oder passe folgende Zeilen an:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers adminname
X11Forwarding no

Validiere die Konfiguration und lade den Dienst neu (auf Ubuntu 24.04 heißt der Dienst ssh, nicht sshd):

sudo sshd -t && sudo systemctl reload ssh

Verifizieren: Teste in deiner zweiten SSH-Session erneut den Login als adminname – er muss weiterhin funktionieren. Teste dann, dass root-Login gesperrt ist:

ssh root@<SERVER-IP>

Erwartetes Ergebnis: „Permission denied (publickey)". Notfallzugang bei Problemen: Hetzner-Console im Panel bzw. VNC im Netcup-SCP.

Schritt 6: Hetzner Cloud Firewall einrichten (Netzwerkebene)

Dieser Schritt gilt nur für Hetzner Cloud. Netcup-Nutzer können ihn überspringen und direkt mit ufw (Schritt 7) beginnen.

Die Hetzner Cloud Firewall sitzt vor deinem Server auf Netzwerkebene und blockt Traffic, bevor er den Server überhaupt erreicht. Sie ist kostenlos und unterstützt bis zu 500 Regeln. In der Hetzner Cloud Console: Firewalls → Create Firewall. Erstelle eine Firewall mit folgenden Inbound-Regeln:

Outbound: Standard „Allow All" beibehalten. Weise die Firewall dem Server zu – entweder direkt über das Panel oder per hcloud CLI:

hcloud firewall apply-to-resource <firewall-name> --type server --server <server-name>

Wichtig: Ohne Inbound-Regeln blockiert die Cloud-Firewall allen eingehenden Traffic. Stelle sicher, dass Port 22/tcp freigegeben ist, bevor du die Firewall zuweist.

Verifizieren: In der Hetzner Console erscheint dein Server in der Firewall-Übersicht als zugewiesenes Resource. Ein SSH-Login funktioniert weiterhin:

ssh adminname@<SERVER-IP>

Schritt 7: ufw auf dem Server einrichten (OS-Ebene)

ufw (Uncomplicated Firewall) läuft direkt auf dem Server und ergänzt die Cloud-Firewall nach dem Defense-in-Depth-Prinzip. Selbst wenn die Cloud-Firewall falsch konfiguriert wird, schützt ufw zusätzlich. Außerdem schützt ufw vor lokal geöffneten Ports, die die Cloud-Firewall nicht kennt.

Kritische Reihenfolge: Erst Regeln setzen, dann ufw enable – niemals umgekehrt!

sudo apt install -y ufw

# Standardregeln: alles eingehend sperren, alles ausgehend erlauben
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH freigeben (ZUERST, bevor enable!)
sudo ufw allow 22/tcp comment 'SSH'

# Optional: weitere Ports
# sudo ufw allow 80/tcp comment 'HTTP'
# sudo ufw allow 443/tcp comment 'HTTPS'

# Jetzt erst aktivieren
sudo ufw enable
sudo ufw status verbose

Einen detaillierten Leitfaden zu ufw und fail2ban liefert die Anleitung Linux-Server absichern mit ufw und fail2ban.

Verifizieren: Die Ausgabe von sudo ufw status verbose zeigt:

Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere

SSH-Login funktioniert weiterhin ohne Unterbrechung.

Schritt 8: fail2ban gegen Brute-Force installieren

fail2ban überwacht Log-Dateien und sperrt IP-Adressen automatisch via Firewall-Regeln nach wiederholten Fehlversuchen:

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

# Lokale SSH-Jail-Konfiguration anlegen:
sudo bash -c 'cat > /etc/fail2ban/jail.d/sshd.local << '"'"'EOF'"'"'
[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 5
bantime = 3600
findtime = 600
EOF'

sudo systemctl restart fail2ban

Hinweis für Ubuntu 24.04: Falls /var/log/auth.log nicht existiert und fail2ban nicht startet, setze backend = systemd in der Jail-Konfiguration oder installiere rsyslog nach.

Verifizieren: Prüfe den Status des SSH-Jails:

sudo fail2ban-client status sshd

Die Ausgabe enthält Status for the jail: sshd mit Currently failed und Total banned Zeilen. Dienst-Status:

sudo systemctl status fail2ban

Erwartete Ausgabe: active (running)

Schritt 9: Automatische Sicherheitsupdates aktivieren

unattended-upgrades ist auf Ubuntu 24.04 bereits vorinstalliert, muss aber korrekt konfiguriert sein:

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

Beantworte die Abfrage mit „Ja". Optional kannst du E-Mail-Benachrichtigungen und automatische Neustarts in /etc/apt/apt.conf.d/50unattended-upgrades konfigurieren:

Unattended-Upgrade::Mail "admin@meinedomain.de";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Eine vertiefte Anleitung zur Konfiguration liefert Unattended-Upgrades: automatische Sicherheitsupdates unter Debian/Ubuntu.

Verifizieren: Führe einen Trockenlauf durch:

sudo unattended-upgrade --dry-run --debug 2>&1 | head -40

Die Ausgabe läuft ohne Fehler durch und zeigt, welche Pakete aktualisiert würden.

Schritt 10: Kernel-Netzwerk-Härtung via sysctl

Einige Kernel-Parameter erhöhen die Netzwerk-Sicherheit und sollten persistent gesetzt werden:

sudo bash -c 'cat > /etc/sysctl.d/99-vps-hardening.conf << '"'"'EOF'"'"'
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
EOF'

sudo sysctl --system

Verifizieren:

sudo sysctl net.ipv4.tcp_syncookies

Erwartete Ausgabe: net.ipv4.tcp_syncookies = 1

Schritt 11: rDNS/PTR-Eintrag setzen

Der Reverse-DNS-Eintrag (PTR) ordnet deiner IP-Adresse einen Hostnamen zu. Das ist besonders wichtig, wenn du einen Mailserver betreiben möchtest – ohne korrekten PTR lehnen viele Mailprovider eingehende E-Mails ab oder markieren sie als Spam.

Voraussetzung (Forward-confirmed rDNS, FCrDNS): Der A-Record deiner Domain muss bereits auf die Server-IP zeigen, bevor du den PTR setzt. Das kann einige Minuten bis Stunden dauern (DNS-Propagation).

Bei Hetzner Cloud (nur via Console): Console → Server auswählen → „Networking" → IPv4-Adresse → Stift-Icon → Hostnamen eintragen (z. B. server1.meinedomain.de). Für IPv6 nur den Interface-Identifier (::1) eingeben, das Präfix ist bereits gespeichert. Bei Netcup: Im SCP unter dem Server-Eintrag gibt es ebenfalls ein Feld für den rDNS-Eintrag. Detaillierte Anleitungen zur rDNS-Konfiguration für Mailserver liefert Reverse-DNS/PTR für Mailserver einrichten.

Verifizieren: Nach dem Setzen und etwas Wartezeit prüfen:

host <SERVER-IP>

Erwartete Ausgabe: <SERVER-IP>.in-addr.arpa domain name pointer server1.meinedomain.de.

Gegenprobe FCrDNS:

host server1.meinedomain.de

Muss dieselbe IP zurückliefern.

Schritt 12: Snapshot- und Backup-Strategie festlegen

Bevor der Server produktiv genutzt wird, solltest du eine klare Backup-Strategie haben. Bei Hetzner Cloud gibt es zwei Mechanismen:

Kostenfalle Snapshots: Bei einem Server mit 60 GB belegtem Speicher kostet ein einzelner Snapshot 0,72 EUR/Monat. Wer fünf Snapshots vorhält, zahlt 3,60 EUR/Monat extra – das multipliziert sich bei mehreren Servern schnell.

Empfohlene Strategie für Einsteiger: Snapshot manuell vor jedem größeren Update erstellen, danach prüfen und ältere löschen. Per hcloud CLI:

hcloud server create-image --type snapshot --description "vor-update-$(date +%Y%m%d)" <server-name>

Für eine umfassende Backup-Strategie nach dem 3-2-1-Prinzip empfiehlt sich die Anleitung 3-2-1-Backup-Strategie praktisch umsetzen.

Verifizieren: Erstelle einen Test-Snapshot und prüfe, dass er in der Console unter „Snapshots" erscheint. Notiere dir die Größe und kalkuliere die monatlichen Kosten.

Troubleshooting / Typische Fehler

1. „Permission denied (publickey)" beim Admin-Login: Der Public Key wurde nicht korrekt übertragen. Als root prüfen: cat /home/adminname/.ssh/authorized_keys muss den Key enthalten. Berechtigungen prüfen: Verzeichnis 700, Datei 600, Eigentümer adminname. Dann sshd -t auf Konfigurationsfehler.
2. SSH-Verbindung nach ufw enable unterbrochen: ufw allow 22/tcp wurde vor ufw enable vergessen. Lösung: Über die Notfallkonsole (Hetzner Console oder Netcup VNC im SCP) einloggen und ufw allow 22/tcp && ufw reload ausführen.
3. fail2ban startet nicht (Unit failed): Auf Ubuntu 24.04 mit systemd-journald kann /var/log/auth.log fehlen. In /etc/fail2ban/jail.d/sshd.local die Zeile backend = systemd setzen und sudo systemctl restart fail2ban.
4. sshd -t meldet Syntaxfehler: Konfigurationsfehler in /etc/ssh/sshd_config. Die Fehlermeldung zeigt Zeile und Fehlertyp. Häufig: doppelt vorhandene Direktiven oder Tippfehler. Vor systemctl reload ssh immer sshd -t ausführen.
5. cloud-init User-Data wird nach Neustart nicht nochmals ausgeführt: Das ist erwartetes Verhalten – cloud-init führt User-Data nur beim allerersten Start aus. Für erneutes Ausführen muss der Server neu erstellt werden.
6. PTR/rDNS-Eintrag lässt sich nicht setzen (Hetzner): Der A-Record der Domain muss zuerst auf die Server-IP zeigen (FCrDNS-Voraussetzung). Prüfen mit host meinedomain.de – muss die Server-IP ausgeben.
7. Netcup SSH-Key nach Image-Installation nicht aktiv: Im SCP gespeicherte Keys werden nur bei Image-Installation eingebunden. Nach der Installation muss der Key manuell per ssh-copy-id oder authorized_keys hinterlegt werden.

Häufige Fragen

Welchen Provider soll ich nehmen – Hetzner oder Netcup?

Für den ersten VPS empfiehlt sich Hetzner Cloud: bessere Dokumentation, modernes REST-API mit hcloud CLI, stundengenaue Abrechnung ohne Mindestlaufzeit und kostenlose Cloud-Firewall. Netcup ist attraktiver für Dauerläufer-Server mit hohem Datenvolumen, da der Traffic unlimitiert ist und das RAM-pro-Euro-Verhältnis besser ist. Beide sind DSGVO-konform mit deutschen Rechenzentren.

Brauche ich sowohl die Hetzner Cloud Firewall als auch ufw auf dem Server?

Ja – das ist das Defense-in-Depth-Prinzip. Die Cloud-Firewall blockiert Traffic auf Netzwerkebene, bevor er den Server erreicht. ufw schützt zusätzlich auf OS-Ebene und ist unabhängig vom Provider. Falls die Cloud-Firewall versehentlich falsch konfiguriert wird, ist ufw das zweite Sicherheitsnetz. Außerdem schützt ufw vor Prozessen, die lokal auf dem Server Ports öffnen – das sieht die Cloud-Firewall nicht.

Was ist der Unterschied zwischen Hetzner Backup und Snapshot?

Automatische Backups kosten 20 % des Serverpreises monatlich, behalten bis zu 7 Versionen, werden aber beim Löschen des Servers mitgelöscht. Snapshots kosten 0,012 EUR/GB/Monat des belegten Speicherplatzes, sind manuell oder per API auslösbar, unbegrenzt aufbewahrbar und überleben Server-Löschungen. Snapshots werden zudem datacenter-übergreifend redundant gespeichert. Für Einsteiger sind manuelle Snapshots meist kostengünstiger und flexibler.

Kann ich den SSH-Port von 22 auf einen anderen Port ändern?

Das verringert das Rauschen in den Logs (weniger automatisierte Bot-Scans), ist aber kein echtes Sicherheitsmerkmal – Port-Scans finden auch unübliche Ports. Wenn geändert: In sshd_config Port 2222 setzen, ufw-Regel anpassen (ufw allow 2222/tcp), Cloud-Firewall-Regel anpassen und erst dann Port 22 schließen. fail2ban muss dann ebenfalls auf den neuen Port konfiguriert werden.

Wie nutze ich cloud-init bei Hetzner für eine automatische Ersteinrichtung?

Beim Erstellen des Servers gibt es das Feld „User Data". Hier kann ein cloud-init YAML eingefügt werden (max. 32 KiB), das beim ersten Start ausgeführt wird – z. B. Pakete installieren, Benutzer anlegen, SSH-Keys hinterlegen. Das erspart den manuellen ersten Login. Einmal ausgeführt, wird es bei Neustarts nicht wiederholt.

Warum muss ich rDNS/PTR setzen?

Der PTR-Eintrag ordnet einer IP-Adresse einen Hostnamen zu. Das ist für drei Szenarien relevant: (1) Mailserver – ohne korrekten PTR lehnen empfangende Mailserver E-Mails oft ab; (2) Professionelles Auftreten – Tools wie traceroute zeigen den Hostnamen; (3) Manche Sicherheitstools prüfen FCrDNS. Auch ohne Mailserver gehört der PTR-Eintrag zur sauberen Server-Konfiguration.

Fazit

Ein sicher konfigurierter VPS entsteht nicht durch einzelne Tools, sondern durch die richtige Reihenfolge: erst Admin-User mit SSH-Key, dann Root-Login sperren, dann Firewall aktivieren. Wer diese Sequenz umdreht, sperrt sich aus. Mit dem hier beschriebenen Setup hast du einen VPS, der Defense-in-Depth umsetzt (Cloud-Firewall plus ufw), automatisch sicher bleibt (unattended-upgrades), Brute-Force-Angriffe abwehrt (fail2ban) und mit Snapshots eine einfache Wiederherstellungsmöglichkeit bietet. Hetzner Cloud empfiehlt sich für den Einstieg wegen der besseren Tooling-Unterstützung und der kostenlosen Cloud-Firewall; Netcup ist die bessere Wahl für Dauerläufer mit hohem Datenvolumen. Beide Provider ermöglichen DSGVO-konformes Hosting in Deutschland – ein wichtiges Kriterium für KMU-Admins in der DACH-Region.

Weiterführende Anleitungen und Quellen

1. SSH-Key-Authentifizierung einrichten (Linux & Windows)
2. Linux-Server absichern mit ufw und fail2ban
3. Unattended-Upgrades: automatische Sicherheitsupdates unter Debian/Ubuntu
4. VPS absichern und härten: ufw, SSH-Keys, fail2ban
5. Reverse-DNS/PTR für Mailserver einrichten
6. 3-2-1-Backup-Strategie praktisch umsetzen

Quellen: Hetzner Docs: Cloud Server erstellen | Hetzner Docs: Cloud Firewall erstellen | Hetzner Docs: Cloud Server rDNS | netcup Helpcenter: First Use of Your Server | Ubuntu Server Docs: Automatic Updates