Neuen Rootserver einrichten: Checkliste für die ersten 30 Minuten

Ein neuer Rootserver ist ab der ersten Sekunde erreichbar und wird ab der ersten Minute gescannt. Die automatisierten Anmeldeversuche auf Port 22 beginnen erfahrungsgemäß, bevor Sie sich das erste Mal selbst eingeloggt haben. Diese Liste bringt einen frischen Server in etwa einer halben Stunde in einen Zustand, in dem Sie ihn ruhigen Gewissens laufen lassen können.

Alle Befehle setzen voraus, dass Sie als root arbeiten, so wie direkt nach der Bereitstellung. Sobald Sie mit Ihrem neuen Benutzer angemeldet sind, stellen Sie jedem Befehl ein sudo voran. Geprüft ist die Reihenfolge auf Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Wo sich die vier unterscheiden, steht es dabei.

Schritt 0: Den Rückweg sichern, bevor Sie etwas ändern

Der einzige Fehler in dieser Liste, den Sie nicht per SSH reparieren können, ist der, der Ihnen SSH nimmt. Deshalb gilt für die nächsten 30 Minuten eine einzige eiserne Regel: Öffnen Sie ein zweites Terminalfenster mit einer aktiven SSH-Verbindung und schließen Sie es nicht. Eine bestehende SSH-Sitzung überlebt sowohl einen Neustart des SSH-Dienstes als auch das Aktivieren der Firewall. Wenn eine neue Verbindung nach einer Änderung nicht mehr klappt, machen Sie die Änderung in der noch offenen Sitzung rückgängig.

Zusätzlich sollten Sie wissen, wo Sie den Konsolenzugang zu Ihrem Server finden, bevor Sie ihn brauchen. Bei KernelHost erreichen Sie ihn im Kundenbereich, unabhängig von SSH und unabhängig von der Firewall. Wer den Weg dorthin erst sucht, während er ausgesperrt ist, verliert Zeit.

Zwei Fehlermeldungen sollten Sie auseinanderhalten können, weil sie auf völlig verschiedene Ursachen zeigen:

• ssh: connect to host 203.0.113.10 port 22: Connection refused bedeutet, das Paket kam an, aber niemand hört auf dem Port. Der SSH-Dienst läuft nicht oder lauscht auf einem anderen Port.
• ssh: connect to host 203.0.113.10 port 22: Connection timed out bedeutet, das Paket wurde verworfen. Das ist fast immer die Firewall.
• Permission denied (publickey) bedeutet, der Dienst läuft und die Firewall lässt Sie durch, nur Ihr Schlüssel passt nicht.

Schritt 1: System aktualisieren

Ein frisch installiertes Abbild ist selten aktuell. Zwischen dem Bau des Abbilds und Ihrer Bestellung liegen oft Wochen, in denen Sicherheitsaktualisierungen erschienen sind.

cat /etc/os-release
apt update
apt full-upgrade -y

full-upgrade statt upgrade ist hier bewusst gewählt: Auf einem frischen System darf apt Pakete entfernen, wenn eine Abhängigkeit das verlangt. Auf einem laufenden Produktivsystem würden Sie zuerst prüfen, was entfernt werden soll.

Auf Ubuntu 22.04 und 24.04 ist needrestart vorinstalliert und unterbricht das Upgrade mit einer bunten Vollbildabfrage, welche Dienste neu gestartet werden sollen. Wenn Sie das nicht wollen, etwa in einem Skript:

NEEDRESTART_MODE=a DEBIAN_FRONTEND=noninteractive apt full-upgrade -y

Danach aufräumen und prüfen, ob ein Neustart nötig ist:

apt autoremove --purge -y
apt list --upgradable
test -f /var/run/reboot-required && echo "Neustart erforderlich" || echo "kein Neustart erforderlich"

Unterschied zwischen den Distributionen: Die Datei /var/run/reboot-required legt nur Ubuntu zuverlässig an, sie stammt aus dem Paket update-notifier-common. Debian meldet einen nötigen Neustart standardmäßig gar nicht. Auf Debian installieren Sie dafür needrestart nach, es sagt Ihnen beim Aufruf, ob ein neuer Kernel bereitliegt. Debian 13 bringt außerdem eine neuere apt-Generation mit farbiger, spaltenweise formatierter Ausgabe mit, das ist kein Fehler, sondern nur ungewohnt.

Erfolgskontrolle: apt list --upgradable gibt außer der Kopfzeile Listing... nichts mehr aus. Kommt beim Update die Meldung Release file for ... is not valid yet, geht die Uhr Ihres Servers falsch, springen Sie zu Schritt 5 und wiederholen Sie dann Schritt 1.

Mehr dazu, auch zum Umgang mit zurückgehaltenen Paketen und Fremdquellen: Linux-Server aktualisieren mit apt.

Schritt 2: Benutzer anlegen statt als root arbeiten

Als root arbeitet man nicht, weil jeder Tippfehler sofort das ganze System trifft und weil jeder Angreifer den Benutzernamen root bereits kennt. Auf Debian-Minimalabbildern ist sudo oft nicht einmal installiert:

apt install -y sudo
adduser --disabled-password --gecos "" kernel
usermod -aG sudo kernel

Der Schalter --disabled-password legt den Benutzer ohne Passwort an, was für eine reine Schlüsselanmeldung genau richtig ist. Wenn Sie zusätzlich ein Passwort setzen wollen, etwa für sudo über die Konsole, dann mit passwd kernel.

Unterschied zwischen den Distributionen: Auf Debian und Ubuntu heißt die Administratorengruppe sudo. Nur wenn Sie von einem RHEL-artigen System kommen, suchen Sie wheel, das gibt es hier nicht.

Jetzt der öffentliche Schlüssel. Legen Sie das Verzeichnis mit den richtigen Rechten an, denn falsche Rechte sind die häufigste Ursache für eine abgelehnte Schlüsselanmeldung:

mkdir -p /home/kernel/.ssh
chmod 700 /home/kernel/.ssh
touch /home/kernel/.ssh/authorized_keys
chmod 600 /home/kernel/.ssh/authorized_keys
chown -R kernel:kernel /home/kernel/.ssh

Den Inhalt Ihres öffentlichen Schlüssels tragen Sie in authorized_keys ein, bequemer geht es von Ihrem Arbeitsrechner aus mit ssh-copy-id kernel@203.0.113.10.

Erfolgskontrolle, und zwar bevor Sie SSH umstellen:

id kernel
sudo -l -U kernel

Die zweite Zeile muss (ALL : ALL) ALL enthalten. Melden Sie sich dann in einem dritten Fenster als kernel an und führen Sie einmal sudo -v aus. Erst wenn das klappt, geht es weiter. Details: Benutzer anlegen und sudo einrichten sowie SSH-Schlüssel erstellen und hinterlegen.

Schritt 3: SSH absichern

Auf sehr schlanken Debian-Abbildern ist der SSH-Server nicht einmal installiert, dann holen Sie ihn zuerst nach:

apt install -y openssh-server

Alle vier hier behandelten Systeme lesen zusätzliche Konfiguration aus /etc/ssh/sshd_config.d/. Bearbeiten Sie also nicht die große sshd_config, sondern legen Sie eine eigene Datei an. Die überlebt Paketaktualisierungen ohne Rückfrage.

Ein Detail, das fast alle Anleitungen falsch machen: In der SSH-Konfiguration gewinnt der erste gefundene Wert, nicht der letzte. Die Zeile Include /etc/ssh/sshd_config.d/*.conf steht bei Debian und Ubuntu ganz oben, und die Dateien darin werden in alphabetischer Reihenfolge gelesen. Auf Ubuntu-Abbildern liegt dort häufig bereits 50-cloud-init.conf mit PasswordAuthentication yes. Eine Datei namens 99-... würde also wirkungslos bleiben. Schauen Sie zuerst nach, was schon da ist:

ls -l /etc/ssh/sshd_config.d/

cat > /etc/ssh/sshd_config.d/10-kernelhost.conf <<'EOF'
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
EOF

prohibit-password statt no ist eine bewusste Entscheidung: root darf sich weiterhin mit Schlüssel anmelden, aber nie mit Passwort. Das rettet Sie, wenn mit dem sudo-Benutzer etwas schiefgeht. Wer härter absichern will, setzt no, sollte dann aber den Konsolenzugang wirklich getestet haben.

Vor jedem Neustart des Dienstes die Syntax prüfen:

ssh-keygen -A
sshd -t && echo "Konfiguration ok"
sshd -T | grep -E "^(permitrootlogin|passwordauthentication|pubkeyauthentication|port) "

sshd -T zeigt die tatsächlich wirksamen Werte, nach Auflösung aller Include-Dateien. Das ist der einzige verlässliche Nachweis, dass Ihre Änderung angekommen ist. Meldet der Befehl sshd: no hostkeys available -- exiting, fehlen die Hostschlüssel, ssh-keygen -A erzeugt sie. Bricht die Prüfung dagegen mit Missing privilege separation directory: /run/sshd ab, lief der Dienst seit dem Start des Systems noch nie und das Laufzeitverzeichnis fehlt. Ein mkdir -p /run/sshd oder ein systemctl restart ssh legt es an, danach bewertet sshd -t wieder Ihre Konfiguration.

Eine Ausgabe irritiert regelmäßig: sshd -T gibt für PermitRootLogin prohibit-password die Zeile permitrootlogin without-password aus. Das ist derselbe Wert unter seinem älteren Namen und kein Hinweis darauf, dass Ihre Einstellung nicht angekommen wäre.

Erst danach:

systemctl restart ssh

Die Socket-Falle bei Ubuntu 24.04 und Debian 13

Seit Ubuntu 22.10, und damit auch in 24.04, wird SSH per Socket-Aktivierung gestartet. Die Folge: Eine Port-Zeile in der sshd-Konfiguration wird ignoriert, der Port kommt aus ssh.socket. Wer den Port ändern will, braucht ein systemd-Overlay:

systemctl edit ssh.socket

Dort hinein, wobei die leere erste Zeile die Voreinstellung löscht:

[Socket]
ListenStream=
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222

Danach systemctl daemon-reload und systemctl restart ssh.socket. Ubuntu 22.04 kennt das noch nicht, dort genügt die Port-Zeile in der Konfiguration.

Auf Debian 13 tritt eine verwandte Kuriosität auf. Manche frischen Abbilder haben ssh.socket aktiv, aufgerüstete Systeme von Debian 12 nicht. Ist beides gleichzeitig aktiv, scheitert ein Reload mit fatal: Cannot bind any address., weil sich Dienst und Socket um Port 22 streiten. Prüfen und im Zweifel entscheiden:

systemctl is-enabled ssh.socket
systemctl disable --now ssh.socket
systemctl enable --now ssh.service

Erfolgskontrolle: ss -tlnp | grep ssh zeigt den erwarteten Port, und ein neuer Verbindungsversuch aus einem frischen Fenster klappt. Ausführlich: SSH absichern und Root-Login deaktivieren und SSH-Port ändern.

Schritt 4: Firewall aktivieren

Auf Ubuntu ist ufw installiert, aber inaktiv. Auf Debian-Minimalabbildern fehlt es ganz. Die Reihenfolge ist hier lebenswichtig: erst SSH erlauben, dann einschalten.

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Der letzte Befehl ist der wichtigste der ganzen Liste. Regeln und Standardrichtlinien allein filtern nichts, erst ufw enable schaltet die Firewall scharf. Wer ihn auslässt, hat am Ende eine vollständig konfigurierte, aber wirkungslose Firewall.

Beim Einschalten fragt ufw: Command may disrupt existing ssh connections. Proceed with operation (y|n)?. Diese Warnung ist ernst gemeint, aber wenn die Regel für Port 22 (oder Ihren geänderten Port) davor steht, passiert nichts, und genau deshalb steht ufw allow 22/tcp in der Liste oberhalb von ufw enable. Haben Sie in Schritt 3 den Port geändert, muss hier ufw allow 2222/tcp stehen, sonst sperren Sie sich aus. In einem Skript oder in einer nicht interaktiven Sitzung nehmen Sie ufw --force enable, das überspringt die Rückfrage.

Erfolgskontrolle:

ufw status verbose

Erwartet wird Status: active, darunter Default: deny (incoming), allow (outgoing) und in der Regelliste eine Zeile 22/tcp ALLOW IN für Ihren SSH-Port. Steht dort weiterhin Status: inactive, fehlt ufw enable und es ist nichts geschützt, egal wie vollständig die Regeln aussehen. Öffnen Sie danach ein neues Fenster und verbinden Sie sich, bevor Sie das alte schließen.

Ergänzend gehört ein Sperrmechanismus gegen Anmeldeversuche dazu:

apt install -y fail2ban python3-systemd

cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
backend = systemd
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
EOF

Warum backend = systemd: Debian installiert seit Version 12 kein rsyslog mehr mit, es gibt also keine /var/log/auth.log. Der Standard backend = auto sucht genau diese Datei und fail2ban startet dann gar nicht, mit der Meldung Failed during configuration: Have not found any log file for sshd jail. Das Paket python3-systemd ist die Voraussetzung dafür, dass der Journal-Zugriff überhaupt funktioniert. Unter Ubuntu 22.04 und 24.04 existiert die Datei dank rsyslog noch, die systemd-Variante funktioniert dort aber ebenso und ist die zukunftssichere Wahl. Nachsehen können Sie mit:

test -f /var/log/auth.log && echo "auth.log vorhanden" || echo "kein auth.log, backend systemd nötig"
fail2ban-client -t

Erfolgskontrolle: fail2ban-client status sshd zeigt eine Zeile Currently banned. Kommt stattdessen Sorry but the jail 'sshd' does not exist, wurde die Konfiguration nicht geladen. Mehr in UFW-Firewall einrichten und Fail2ban einrichten.

Schritt 5: Zeitzone und Uhrzeit

Eine falsche Uhr macht Protokolle wertlos, lässt Zertifikatsprüfungen scheitern und kann apt mit Release file is not valid yet blockieren. Auf einem echten Server:

timedatectl set-timezone Europe/Vienna
timedatectl status

In der Ausgabe müssen zwei Zeilen stimmen: Time zone: Europe/Vienna und System clock synchronized: yes sowie NTP service: active. Steht dort NTP service: inactive, läuft keine Zeitsynchronisation. Ubuntu bringt systemd-timesyncd standardmäßig mit, Debian-Minimalabbilder häufig nicht:

DEBIAN_FRONTEND=noninteractive apt install -y systemd-timesyncd tzdata
date

Viele Betreiber lassen Server bewusst auf UTC laufen, damit Protokolle verschiedener Standorte vergleichbar bleiben. Beides ist vertretbar, entscheidend ist, dass Sie es wissen. Wenn timedatectl in einer Containerumgebung nicht verfügbar ist, geht es auch klassisch:

ln -sf /usr/share/zoneinfo/Europe/Vienna /etc/localtime
dpkg-reconfigure -f noninteractive tzdata

Vertiefung: Zeitzone und Zeitsynchronisation einrichten.

Schritt 6: Hostname setzen

Der Hostname taucht in Protokollen, in ausgehenden E-Mails und in Monitoring-Meldungen auf. Setzen Sie ihn früh, sonst heißen später alle Ihre Server gleich.

hostnamectl set-hostname srv01.ihre-domain.de
hostname -f

Danach gehört ein passender Eintrag in /etc/hosts, sonst begrüßt Sie bei jedem sudo-Aufruf die Meldung sudo: unable to resolve host srv01: Name or service not known mit spürbarer Verzögerung. Die Zeile lautet sinngemäß 127.0.1.1 srv01.ihre-domain.de srv01.

Die Falle: Auf Abbildern mit cloud-init, was bei Ubuntu die Regel ist, wird der Hostname beim nächsten Neustart zurückgesetzt. Der Schalter dagegen:

command -v cloud-init || echo "cloud-init nicht installiert"

mkdir -p /etc/cloud/cloud.cfg.d
printf 'preserve_hostname: true\n' > /etc/cloud/cloud.cfg.d/99_hostname.cfg

Erfolgskontrolle: Nach einem Neustart liefert hostnamectl immer noch Ihren Namen. Details: Hostname unter Linux dauerhaft ändern.

Schritt 7: Automatische Sicherheitsupdates

Ein Server, den niemand mehr anfasst, ist der gefährlichste. Automatische Sicherheitsaktualisierungen sind der wirksamste einzelne Schritt dieser Liste.

apt install -y unattended-upgrades

cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

Das Installieren des Pakets allein genügt nicht überall, erst diese Datei schaltet den täglichen Lauf scharf. Eigene Feineinstellungen gehören in eine Datei mit höherer Nummer als die mitgelieferte 50unattended-upgrades, damit sie gewinnen und bei einem Paketupdate nicht überschrieben werden:

cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::MinimalSteps "true";
EOF

Standardmäßig zieht das Werkzeug auf beiden Distributionen nur aus der Sicherheitsquelle, nicht die normalen Aktualisierungen. Das ist Absicht und für Produktivsysteme meist genau richtig. Wenn Sie Automatic-Reboot "true" setzen, setzen Sie unbedingt auch eine Uhrzeit, sonst startet der Server neu, wann es dem Zeitgeber passt.

Erfolgskontrolle: Ein Probelauf zeigt, welche Pakete infrage kämen, ohne etwas zu installieren. Achten Sie auf die Einzahl im Befehlsnamen:

unattended-upgrade --dry-run --debug
apt-config dump | grep -iE "unattended|periodic"

Im Protokoll unter /var/log/unattended-upgrades/ muss nach dem ersten Lauf etwas stehen. Bleibt es leer, greift die Konfiguration nicht. Ausführlich: Automatische Sicherheitsupdates einrichten.

Schritt 8: Überwachung

Überwachung heißt in den ersten 30 Minuten nicht, ein Grafana aufzubauen. Es heißt, dass Sie erfahren, wenn der Server steht oder die Platte volläuft.

apt install -y htop tmux curl
df -h /
free -m

Drei Dinge reichen für den Anfang. Erstens ein externer Erreichbarkeitstest, der von außen prüft und Sie benachrichtigt, denn ein Server, der abgestürzt ist, schickt keine Warnung mehr über sich selbst. Zweitens eine Plattenplatzwarnung, denn ein volles Dateisystem ist die häufigste Ursache für Ausfälle, die niemand kommen sah. Drittens der Blick ins Journal, wenn etwas seltsam ist:

journalctl -p 3 -b --no-pager | tail -n 30
systemctl --failed

systemctl --failed sollte 0 loaded units listed ausgeben. Jede Zeile dort ist ein Dienst, der nicht startet, und den Sie jetzt reparieren wollen und nicht in drei Monaten. Mehr dazu: Server-Monitoring einrichten.

Schritt 9: Sicherung, bevor es etwas zu verlieren gibt

Der beste Zeitpunkt für die erste Sicherung ist, bevor Daten da sind. Dann üben Sie den Ablauf ohne Druck. Zwei Dinge sind es wert, sofort weggeschrieben zu werden, weil ihre Rekonstruktion am meisten Zeit kostet: die Konfiguration unter /etc und die Liste der installierten Pakete.

tar -czf /root/etc-backup-$(date +%F).tar.gz /etc
dpkg --get-selections > /root/pakete.txt
tar -tzf /root/etc-backup-$(date +%F).tar.gz | wc -l

Damit haben Sie noch keine Sicherung, sondern nur eine Kopie auf demselben Datenträger. Eine Sicherung liegt auf einem anderen System, idealerweise an einem anderen Ort. Ein Werkzeug mit Verschlüsselung und Zwischenspeicherung gleicher Blöcke lohnt sich vom ersten Tag an:

apt install -y borgbackup
borg --version

Die unbequeme Wahrheit: Eine Sicherung, aus der noch nie etwas zurückgeholt wurde, ist eine Vermutung. Nehmen Sie sich für die erste Rücksicherung einen Termin und stellen Sie eine einzelne Datei wieder her. Der Weg dorthin steht in Backup-Strategie für Rootserver.

Wenn Sie sich ausgesperrt haben

Es passiert, meist in Schritt 3 oder 4. Der Weg zurück ist immer derselbe: über die Konsole im Kundenbereich anmelden, dort mit Benutzername und Passwort statt mit Schlüssel. Anschließend je nach Ursache:

• Firewall zu streng: ufw disable, Regel korrigieren, ufw enable.
• SSH-Konfiguration kaputt: rm /etc/ssh/sshd_config.d/10-kernelhost.conf, dann sshd -t und systemctl restart ssh.
• Falscher Port nach Socket-Änderung: systemctl revert ssh.socket setzt das Overlay zurück, danach systemctl daemon-reload und systemctl restart ssh.socket.
• Von fail2ban ausgesperrt: fail2ban-client set sshd unbanip 203.0.113.10. Damit Ihnen das nicht wieder passiert, tragen Sie Ihre feste Adresse unter ignoreip in der jail.local ein.
• Schlüssel wird abgelehnt: Fast immer Rechte. chmod 700 auf das Verzeichnis, chmod 600 auf die Datei, und beides muss dem Benutzer gehören, nicht root.

Die Abschlusskontrolle

Ein Befehl gibt keinen Fehler zurück, bedeutet nicht, dass er gewirkt hat. Diese sechs Prüfungen zeigen den tatsächlichen Zustand:

1. sshd -T | grep -E "^(permitrootlogin|passwordauthentication|port) " zeigt die wirksamen Werte, nicht die gewünschten.
2. ufw status verbose meldet Status: active mit einer Regel für Ihren SSH-Port.
3. timedatectl status meldet System clock synchronized: yes.
4. systemctl --failed listet nichts auf.
5. unattended-upgrade --dry-run --debug läuft ohne Fehlermeldung durch.
6. Eine neue SSH-Verbindung aus einem frisch geöffneten Fenster klappt, mit Schlüssel, ohne Passwortabfrage.

Erst wenn Punkt sechs sitzt, dürfen Sie das alte Terminalfenster schließen.

Was danach kommt

Ein Wort zur Wahl der Distribution, weil sie über die nächsten Jahre entscheidet. Debian 12 ist seit Juli 2026 aus der regulären Unterstützung heraus und wird bis Mitte 2028 vom LTS-Team weitergepflegt, mit eingeschränktem Paketumfang. Wer heute neu aufsetzt, nimmt Debian 13 oder Ubuntu 24.04 LTS. Ubuntu 22.04 LTS ist noch bis 2027 in der Standardunterstützung, für einen Server, der Jahre laufen soll, ist es aber nicht mehr die erste Wahl. Debian 10 und Ubuntu 20.04 sind seit Juni 2024 beziehungsweise Mai 2025 endgültig durch und gehören auf keinen neuen Server.

Praktisch relevant sind auch die Versionsunterschiede in den Paketquellen. Debian liefert grundsätzlich kein mysql-server, dort ist MariaDB der Standard. Wer eine bestimmte PHP-, Node- oder Java-Version braucht, prüft besser vorher, was die Distribution mitbringt, statt später Fremdquellen einzubinden. Und wenn Sie Fremdquellen einbinden: apt-key ist abgekündigt, Schlüssel gehören nach /etc/apt/keyrings/ und werden in der Quellenangabe per signed-by referenziert.

Damit steht ein Server, der aktualisiert ist, sich selbst aktuell hält, nur Sie hereinlässt und meldet, wenn etwas nicht stimmt. Alles Weitere, Webserver, Datenbank, Zertifikate, baut darauf auf und nicht daneben.