Die erste Stunde auf einem neuen Server

Ein frisch bestellter Server ist ab der ersten Minute im Netz erreichbar, und ab der zweiten Minute laufen die ersten automatisierten Login-Versuche auf Port 22. Das ist kein Angriff auf dich persönlich, das ist Grundrauschen. Es bedeutet nur: die Grundhärtung ist kein Projekt für nächste Woche.

Diese Anleitung geht von Debian 13 (trixie) aus. Auf Ubuntu 24.04 oder 26.04 ist alles identisch bis auf den Paketnamen für automatische Updates, der dort mitgeliefert wird.

Schritt 1: Anmelden und wissen, wo man ist#

ssh [email protected]

Beim ersten Verbinden zeigt SSH den Fingerabdruck des Hosts. Vergleiche ihn mit dem, was im Kundenpanel steht, das ist die einzige Gelegenheit, bei der du ihn ohne Vertrauensvorschuss prüfen kannst. Danach steht er in ~/.ssh/known_hosts und eine Abweichung ist ein Alarm.

Ein kurzer Blick auf das, was du gekauft hast:

hostnamectl                    # Kernel, OS, Virtualisierungstyp
free -h && df -h /             # RAM und Platte
ip -brief address              # welche IPs sind konfiguriert

Schritt 2: Alles aktualisieren#

apt update && apt full-upgrade -y
apt autoremove --purge -y

Images sind fast immer ein paar Wochen bis Monate alt. Wenn dabei ein neuer Kernel installiert wird, ist ein Neustart fällig, jetzt ist der beste Zeitpunkt dafür, weil noch nichts drauf läuft:

[ -f /var/run/reboot-required ] && reboot

Schritt 3: Einen eigenen Benutzer anlegen#

Dauerhaft als root zu arbeiten hat einen praktischen Nachteil, der schwerer wiegt als das Sicherheitsargument: Es gibt keine Zwischenstufe mehr. Ein Tippfehler in einem rm ist sofort endgültig.

adduser mauri                  # fragt nach Passwort und Namen
usermod -aG sudo mauri         # darf per sudo root werden

Prüfen, ob sudo wirklich funktioniert, bevor der Root-Login abgeschaltet wird:

su - mauri
sudo whoami                    # muss "root" ausgeben
exit

Schritt 4: SSH-Schlüssel einrichten#

Der wichtigste Schritt der ganzen Liste. Ein Schlüssel ist nicht nur sicherer als ein Passwort, er ist auch bequemer, weil kein Passwort mehr getippt wird.

Auf deinem eigenen Rechner (nicht auf dem Server) erzeugen, falls noch nicht vorhanden:

ssh-keygen -t ed25519 -C "mauri@laptop"

Ed25519 statt RSA: kürzer, schneller, seit Jahren Standard. Die Passphrase-Abfrage nicht überspringen, sie ist das, was den Schlüssel schützt, falls dein Laptop wegkommt.

Öffentlichen Teil auf den Server bringen:

ssh-copy-id [email protected]

Und in einer neuen Sitzung testen, dass es funktioniert, bevor irgendetwas abgeschaltet wird:

ssh [email protected]

Schritt 5: SSH absichern#

Erst wenn Schritt 4 nachweislich funktioniert. Datei /etc/ssh/sshd_config.d/10-haertung.conf anlegen, eine eigene Datei im Unterverzeichnis statt Änderungen an der Hauptdatei, dann überschreibt ein Paket-Update sie nicht:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

Konfiguration prüfen und erst danach neu laden:

sudo sshd -t && sudo systemctl reload ssh

sshd -t ist der Unterschied zwischen „Tippfehler bemerkt“ und „ausgesperrt“. Die bestehende Sitzung bleibt bei reload offen, teste den neuen Zugang in einem zweiten Fenster, bevor du das erste schließt.

Ausführlicher, mit MFA und Match-Blöcken: SSH-Schlüssel und Härtung.

Schritt 6: Firewall#

Standardhaltung: eingehend alles zu, außer was gebraucht wird. Ausgehend erst mal offen, das ist ein eigenes Thema, siehe Firewall auf dem VPS.

Mit ufw, weil es für den Anfang das Einfachste ist:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw enable
sudo ufw status verbose

Schritt 7: Automatische Sicherheitsupdates#

Der Schritt mit dem besten Verhältnis von Aufwand zu Wirkung. Fast jede kompromittierte Maschine wurde über eine Lücke übernommen, für die es seit Wochen einen Patch gab.

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Kontrollieren, dass die Sicherheitsquelle aktiviert ist, und einen Probelauf machen:

grep -A5 'Allowed-Origins' /etc/apt/apt.conf.d/50unattended-upgrades
sudo unattended-upgrades --dry-run --debug

Automatische Neustarts sind Geschmackssache. Bei einem einzelnen VPS ohne Redundanz stelle ich sie an, aber mit fester Uhrzeit:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Die letzten fünf Minuten#

Zeitzone und Zeitsynchronisation, wichtig, weil sonst jede Protokollzeile und jedes TLS-Zertifikat später Fragen aufwirft:

sudo timedatectl set-timezone Europe/Berlin
timedatectl status         # "System clock synchronized: yes"

Hostname setzen, damit die Maschine in Protokollen und Prompts wiedererkennbar ist:

sudo hostnamectl set-hostname web01

Einmal nachsehen, wer schon vorbeigeschaut hat. Nach ein paar Stunden Laufzeit ist die Liste erstaunlich lang:

sudo journalctl -u ssh --since "1 hour ago" | grep -c "Invalid user"

Genau deshalb steht Schritt 5 nicht in der Rubrik „später mal“.

Checkliste zum Abhaken#

Erst danach kommt der erste Dienst auf die Maschine. Wenn das ein Webdienst ist, geht es mit dem Reverse-Proxy weiter, der sorgt dafür, dass genau ein Port nach außen offen sein muss.