Zum Inhalt springen
CitexNode
Alle Anleitungen

Server absichern

Updates, automatische Sicherheitsupdates, ein sudo-Benutzer, Login nur per Schlüssel und fail2ban.

6 Min. Lesezeit

Gilt für Debian 12/13, Ubuntu 22.04/24.04, AlmaLinux 9 und Rocky Linux 9. Du brauchst einen funktionierenden SSH-Login als root, siehe Per SSH verbinden.

Jeder Server im Internet bekommt nach wenigen Minuten die ersten Login-Versuche von Bots. Mit den Schritten hier laufen die ins Leere.

1. Updates einspielen

Debian und Ubuntu:

bash
apt update && apt full-upgrade -y

AlmaLinux und Rocky Linux:

bash
dnf upgrade -y

Kam ein neuer Kernel, starte neu (reboot) und verbinde dich danach wieder.

2. Automatische Sicherheitsupdates

Debian und Ubuntu: unattended-upgrades

Auf Ubuntu ist das Paket meist schon da, auf Debian installierst du es:

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

Die Frage beantwortest du mit Ja. Damit landen Sicherheitsupdates täglich von selbst. Ob es läuft:

bash
systemctl status unattended-upgrades
unattended-upgrade --dry-run --debug

Das Protokoll steht in /var/log/unattended-upgrades/.

AlmaLinux und Rocky Linux: dnf-automatic

bash
dnf install -y dnf-automatic

Öffne /etc/dnf/automatic.conf und setz im Abschnitt [commands]:

ini
[commands]
upgrade_type = security
apply_updates = yes

Dann den Timer einschalten:

bash
systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

3. Einen Benutzer mit sudo anlegen

Arbeite im Alltag nicht als root. Leg einen eigenen Benutzer an, hier alex.

Debian und Ubuntu:

bash
apt install -y sudo
adduser alex
usermod -aG sudo alex

AlmaLinux und Rocky Linux:

bash
useradd -m -G wheel alex
passwd alex

Das Passwort brauchst du später für sudo. Gib dem Benutzer denselben SSH-Schlüssel wie root:

bash
mkdir -p /home/alex/.ssh
cp /root/.ssh/authorized_keys /home/alex/.ssh/
chown -R alex:alex /home/alex/.ssh
chmod 700 /home/alex/.ssh
chmod 600 /home/alex/.ssh/authorized_keys

Teste in einem zweiten Fenster:

bash
ssh alex@203.0.113.10
sudo whoami

sudo whoami muss nach deinem Passwort fragen und dann root ausgeben.

4. SSH härten

Statt /etc/ssh/sshd_config zu bearbeiten, legst du eine eigene Datei in /etc/ssh/sshd_config.d/ an. Die bleibt bei Paket-Updates unberührt. Alle genannten Systeme lesen diesen Ordner.

Der Name muss mit 00- beginnen: SSH nimmt bei jeder Einstellung den ersten Wert, den es findet, und Cloud-Images bringen oft eigene Dateien wie 50-cloud-init.conf mit, die Passwort-Logins erlauben.

bash
nano /etc/ssh/sshd_config.d/00-haertung.conf
text
# Nur Schlüssel, keine Passwörter
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# root nur noch per Schlüssel (oder "no", wenn du nur noch deinen sudo-Benutzer nimmst)
PermitRootLogin prohibit-password

MaxAuthTries 3
X11Forwarding no

Prüfe die Datei und lad SSH neu:

bash
sshd -t

Keine Ausgabe heißt: keine Fehler. Dann:

bash
# Debian und Ubuntu
systemctl reload ssh

# AlmaLinux und Rocky Linux
systemctl reload sshd

Ob die Werte greifen:

bash
sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|kbdinteractive'

Erwartet: passwordauthentication no, permitrootlogin without-password (so heißt prohibit-password intern) und kbdinteractiveauthentication no.

Jetzt im zweiten Fenster testen:

bash
ssh alex@203.0.113.10
ssh -o PubkeyAuthentication=no alex@203.0.113.10

Der erste Befehl muss klappen, der zweite muss mit Permission denied (publickey) scheitern.

5. fail2ban

fail2ban sperrt Adressen für eine Weile, die zu oft falsch anmelden. Mit Login nur per Schlüssel ist das kein Muss, hält aber die Logs sauber.

Debian und Ubuntu:

bash
apt install -y fail2ban python3-systemd

AlmaLinux und Rocky Linux (fail2ban kommt aus EPEL):

bash
dnf install -y epel-release
dnf install -y fail2ban fail2ban-firewalld

Leg eine eigene Datei an, statt jail.conf zu bearbeiten:

bash
nano /etc/fail2ban/jail.d/sshd.local
ini
[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

backend = systemd ist wichtig: Debian 12 und 13 schreiben kein /var/log/auth.log mehr, fail2ban liest dann aus dem Journal.

bash
systemctl enable --now fail2ban
fail2ban-client status sshd

Die Ausgabe zeigt Currently banned und Total banned. Eine gesperrte Adresse gibst du frei mit:

bash
fail2ban-client set sshd unbanip 198.51.100.7

Prüfen, ob alles sitzt

  • Login als dein Benutzer per Schlüssel klappt, sudo whoami gibt root aus.
  • Login mit Passwort scheitert.
  • systemctl status unattended-upgrades bzw. systemctl list-timers dnf-automatic.timer zeigt aktiv.
  • fail2ban-client status sshd antwortet.

Erst dann die root-Sitzung schließen.

Häufige Fehler

ProblemLösung
Passwort-Login geht trotz PasswordAuthentication noEine andere Datei in /etc/ssh/sshd_config.d/ kommt vorher. sshd -T zeigt den wirksamen Wert; deine Datei muss alphabetisch zuerst kommen (00-…).
sudo: command not foundDebian ohne sudo: apt install sudo als root.
alex is not in the sudoers fileGruppe fehlt: usermod -aG sudo alex (Debian/Ubuntu) oder usermod -aG wheel alex (AlmaLinux/Rocky), dann neu anmelden.
fail2ban startet nichtjournalctl -u fail2ban -n 50. Meist fehlt backend = systemd oder python3-systemd.
AusgesperrtKonsole im Dashboard öffnen, als root mit dem Passwort aus Zugangsdaten anmelden, die Datei 00-haertung.conf korrigieren und systemctl reload ssh bzw. sshd. Das Passwort setzt im Reiter System Root-Passwort zurücksetzen neu.

Wie es weitergeht