Server absichern
Updates, automatische Sicherheitsupdates, ein sudo-Benutzer, Login nur per Schlüssel und fail2ban.
6 Min. Lesezeit
Auf dieser Seite
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:
apt update && apt full-upgrade -yAlmaLinux und Rocky Linux:
dnf upgrade -yKam 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:
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgradesDie Frage beantwortest du mit Ja. Damit landen Sicherheitsupdates täglich von selbst. Ob es läuft:
systemctl status unattended-upgrades
unattended-upgrade --dry-run --debugDas Protokoll steht in /var/log/unattended-upgrades/.
AlmaLinux und Rocky Linux: dnf-automatic
dnf install -y dnf-automaticÖffne /etc/dnf/automatic.conf und setz im Abschnitt [commands]:
[commands]
upgrade_type = security
apply_updates = yesDann den Timer einschalten:
systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer3. Einen Benutzer mit sudo anlegen
Arbeite im Alltag nicht als root. Leg einen eigenen Benutzer an, hier alex.
Debian und Ubuntu:
apt install -y sudo
adduser alex
usermod -aG sudo alexAlmaLinux und Rocky Linux:
useradd -m -G wheel alex
passwd alexDas Passwort brauchst du später für sudo. Gib dem Benutzer denselben SSH-Schlüssel wie root:
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_keysTeste in einem zweiten Fenster:
ssh alex@203.0.113.10
sudo whoamisudo 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.
nano /etc/ssh/sshd_config.d/00-haertung.conf# 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 noPrüfe die Datei und lad SSH neu:
sshd -tKeine Ausgabe heißt: keine Fehler. Dann:
# Debian und Ubuntu
systemctl reload ssh
# AlmaLinux und Rocky Linux
systemctl reload sshdOb die Werte greifen:
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:
ssh alex@203.0.113.10
ssh -o PubkeyAuthentication=no alex@203.0.113.10Der 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:
apt install -y fail2ban python3-systemdAlmaLinux und Rocky Linux (fail2ban kommt aus EPEL):
dnf install -y epel-release
dnf install -y fail2ban fail2ban-firewalldLeg eine eigene Datei an, statt jail.conf zu bearbeiten:
nano /etc/fail2ban/jail.d/sshd.local[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1hbackend = systemd ist wichtig: Debian 12 und 13 schreiben kein /var/log/auth.log mehr, fail2ban liest dann aus dem Journal.
systemctl enable --now fail2ban
fail2ban-client status sshdDie Ausgabe zeigt Currently banned und Total banned. Eine gesperrte Adresse gibst du frei mit:
fail2ban-client set sshd unbanip 198.51.100.7Prüfen, ob alles sitzt
- Login als dein Benutzer per Schlüssel klappt,
sudo whoamigibtrootaus. - Login mit Passwort scheitert.
systemctl status unattended-upgradesbzw.systemctl list-timers dnf-automatic.timerzeigt aktiv.fail2ban-client status sshdantwortet.
Erst dann die root-Sitzung schließen.
Häufige Fehler
| Problem | Lösung |
|---|---|
Passwort-Login geht trotz PasswordAuthentication no | Eine 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 found | Debian ohne sudo: apt install sudo als root. |
alex is not in the sudoers file | Gruppe fehlt: usermod -aG sudo alex (Debian/Ubuntu) oder usermod -aG wheel alex (AlmaLinux/Rocky), dann neu anmelden. |
| fail2ban startet nicht | journalctl -u fail2ban -n 50. Meist fehlt backend = systemd oder python3-systemd. |
| Ausgesperrt | Konsole 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
- Firewall einrichten, damit nur die Ports offen sind, die du brauchst.
- Swap anlegen, wenn der RAM knapp wird.
- Hilfe: Ticket.