SSH absichern: Checkliste zur Härtung eines Linux-VPS

1. System aktualisieren und automatische Sicherheitsupdates einschalten

Installieren Sie zuerst die ausstehenden Updates: apt update aktualisiert die Paketlisten, apt upgrade installiert die neuen Paketversionen. [1]

sudo apt update
sudo apt upgrade

Unter Ubuntu werden Sicherheitsupdates automatisch über das Paket unattended-upgrades installiert. Es ist standardmäßig vorhanden und läuft einmal täglich. Beide Werte in /etc/apt/apt.conf.d/20auto-upgrades sollten „1“ lauten, und ein Probelauf zeigt, was installiert würde. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Einen Neustart führt unattended-upgrades nicht selbst aus, denn Unattended-Upgrade::Automatic-Reboot steht standardmäßig auf „false“. Starten Sie den Server deshalb von Hand neu, wenn ein Update das verlangt. [1] Fehlt unter Debian 12 das Paket oder die Datei, installieren Sie unattended-upgrades und legen die Datei mit den beiden oben gezeigten Zeilen an.

2. Einen eigenen Benutzer mit sudo-Rechten anlegen

Erledigen Sie Verwaltungsaufgaben unter einem persönlichen Benutzerkonto mit sudo. Dabei fragt sudo nach dem eigenen Passwort dieses Benutzers, nicht nach dem Root-Passwort. Mitglieder der Gruppe sudo erhalten darüber vollen Root-Zugriff. [2]

sudo adduser deploy
sudo adduser deploy sudo

Der Befehl adduser fragt nach einem Passwort und einigen optionalen Angaben. [2] Wählen Sie ein langes Passwort: SSH wird zwar Schlüssel verwenden, aber sudo fragt weiterhin danach. Prüfen Sie anschließend das Konto; sudo whoami sollte root ausgeben.

su - deploy
sudo whoami

Fehlt unter Debian 12 der Befehl sudo, installieren Sie ihn zuerst als root mit apt install sudo.

3. Einen ed25519-Schlüssel auf Ihrem Computer erzeugen

Erzeugen Sie das Schlüsselpaar auf Ihrem eigenen Computer, nicht auf dem Server. Ubuntu empfiehlt den Typ ed25519, weil seine Schlüssel kürzer sind und weniger Rechenaufwand erfordern. Beim Erzeugen fragt ssh-keygen nach einer Passphrase, die den privaten Schlüssel schützt. [3]

ssh-keygen -t ed25519

Übernehmen Sie den vorgeschlagenen Dateinamen. Der private Schlüssel liegt in ~/.ssh/id_ed25519, der öffentliche Schlüssel, den Sie auf Server kopieren, in ~/.ssh/id_ed25519.pub. [3]

Unter Windows führen Sie denselben Befehl in der PowerShell aus; er speichert das Schlüsselpaar im Ordner .ssh Ihres Benutzerprofils. Microsoft rät von einer leeren Passphrase ab und warnt, dass sich jeder, der an den privaten Schlüssel gelangt, als Sie anmelden kann. [4]

ssh-keygen -t ed25519

4. Den öffentlichen Schlüssel auf den Server kopieren

Unter Linux und macOS hängt ssh-copy-id Ihren öffentlichen Schlüssel an die Datei ~/.ssh/authorized_keys des Benutzers auf dem Server an. [3]

ssh-copy-id deploy@203.0.113.10

In der Anleitung von Microsoft werden Schlüssel stattdessen mit PowerShell oder scp kopiert. [4] Für einen Linux-Server hängt diese Zeile Ihren Schlüssel an und setzt die Rechte so, dass nur Sie in den Ordner und die Datei schreiben können:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Bevor sshd eine Anmeldung annimmt, prüft es diese Rechte über die Option StrictModes, die standardmäßig aktiv ist. [5] Führen Sie dann in einem neuen Terminal ssh deploy@203.0.113.10 aus: Die Anmeldung sollte ohne das Passwort des Kontos gelingen. Falls nicht, verfolgen Sie das SSH-Log des Servers, während Sie es erneut versuchen: [3]

sudo journalctl -fu ssh.service

5. Eigene Einstellungen in eine Drop-in-Datei schreiben

Unter Ubuntu beginnt /etc/ssh/sshd_config mit Include /etc/ssh/sshd_config.d/*.conf, und OpenSSH übernimmt bei den meisten Einstellungen den ersten Wert, den es liest. Dateien in diesem Ordner haben deshalb Vorrang vor der Hauptdatei. [3] Eingebundene Dateien werden in lexikalischer Reihenfolge gelesen, und für jedes Schlüsselwort gilt der erste Wert, den sshd erhält. [5] Nennen Sie Ihre Datei daher 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

Was die Optionen laut der Manpage von sshd_config bewirken:

• PermitRootLogin no verhindert, dass sich root per SSH anmeldet. Der Standardwert prohibit-password lehnt für root Passwörter ab, nimmt aber weiterhin Schlüssel an. [5]
• PasswordAuthentication no schaltet die Anmeldung per Passwort ab, die standardmäßig erlaubt ist. [5]
• KbdInteractiveAuthentication no schaltet die tastaturinteraktive Anmeldung (keyboard-interactive) ab, ein eigenes Verfahren, das ebenfalls standardmäßig aktiv ist. Früher hieß die Option ChallengeResponseAuthentication. [5]
• AllowUsers deploy (optional) erlaubt nur den aufgeführten Benutzern die Anmeldung. Anders als bei den meisten Schlüsselwörtern ergänzt jede AllowUsers-Zeile die Liste. [5] Schreiben Sie den Namen exakt richtig, sonst kann sich niemand mehr anmelden.

Behandeln Sie das sudo-Konto ab jetzt wie root: Laut den Hinweisen zum openssh-Paket von Ubuntu ist jedes Konto, von dem aus Sie Root-Rechte erlangen können, aus Sicht eines Angreifers von außen gleichwertig mit root. [6] Prüfen Sie unter Debian 12 zuerst mit grep -n Include /etc/ssh/sshd_config, ob die Include-Zeile vorhanden ist.

6. Nach Dateien suchen, die Passwort-Logins wieder erlauben

Da der erste Wert gilt, hat jede Datei Vorrang, die in der Sortierung vor Ihrer steht. Durchsuchen Sie den Ordner:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Auf Cloud-Images schreibt cloud-init die SSH-Einstellungen, die es verwaltet, in /etc/ssh/sshd_config.d/50-cloud-init.conf, sofern sshd_config diesen Ordner einbindet. [7] Steht in dieser Datei PasswordAuthentication yes, setzt sie sich gegen jede Datei durch, die nach ihr einsortiert ist. Deshalb beginnt der Name Ihrer Datei mit 00. Ändern Sie den Wert dort ebenfalls auf no, damit die Dateien übereinstimmen.

7. Konfiguration testen und SSH neu starten

Testen Sie die Dateien vor dem Neustart: Eine fehlerhafte Einstellung kann den Start von sshd verhindern, und SSH ist womöglich Ihr einziger Zugang. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Beheben Sie zuerst alles, was sshd -t meldet. Lassen Sie nach dem Neustart Ihre Sitzung offen und testen Sie von einem zweiten Terminal aus:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

Die erste Anmeldung sollte funktionieren, die zweite abgewiesen werden. Schlägt Ihre Anmeldung fehl, machen Sie die Änderung in der offenen Sitzung rückgängig und prüfen das SSH-Log aus Schritt 4. [3]

8. Den Port unter Ubuntu 24.04 ändern (optional)

Unter Ubuntu 24.04 lauscht ssh.socket per systemd-Socket-Aktivierung auf Port 22. Ein Generator wandelt die Port-Zeilen aus sshd_config und den zugehörigen Drop-in-Dateien in Socket-Einstellungen um. Nach einer Portänderung lassen Sie systemd deshalb seine Konfiguration neu einlesen und starten ssh.socket neu. [6]

Da sshd mehrere Port-Zeilen akzeptiert, [5] behalten Sie Port 22, während Sie den neuen Port testen:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Testen Sie den neuen Port von einem zweiten Terminal aus. Löschen Sie danach die Zeile Port 22, wiederholen Sie die drei Befehle und verwenden Sie in den Schritten 9 und 10 Port 2222.

ssh -p 2222 deploy@203.0.113.10

Prüfen Sie unter Debian 12 zuerst, ob der Socket genutzt wird. Ist er inaktiv, genügt ein Neustart des Dienstes, damit die Änderung greift.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. SSH in UFW freigeben, dann UFW aktivieren

UFW ist nach der Installation zunächst deaktiviert; sobald Sie es aktivieren, weist es eingehenden Traffic standardmäßig ab. Die Manpage warnt, dass ufw enable SSH-Verbindungen trennen kann; legen Sie die SSH-Regel deshalb zuerst an. [8]

Verwenden Sie für SSH limit statt allow. Eine limit-Regel lässt Verbindungen weiterhin zu, weist aber eine Adresse ab, die innerhalb von 30 Sekunden 6 oder mehr Verbindungen aufzubauen versucht. Legen Sie nicht beide Regeln an, denn UFW wendet die erste passende Regel an. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Wenn Sie UFW über SSH aktivieren, fragt es nach einer Bestätigung. [8] Haben Sie SSH auf einen anderen Port verlegt, setzen Sie die limit-Regel stattdessen für 2222/tcp. Fehlt unter Debian 12 der Befehl, installieren Sie UFW zuerst. Soll SSH gar nicht aus dem öffentlichen Internet erreichbar sein, greifen Sie nur noch über ein privates WireGuard-Netzwerk darauf zu. Für Schutz, der schon vor dem Server ansetzt, lesen Sie unsere Checkliste zum DDoS-Schutz für VPS.

10. Fail2ban mit dem sshd-Jail einrichten

Unter Ubuntu 24.04 bringt das Paket die Datei /etc/fail2ban/jail.d/defaults-debian.conf mit. Sie aktiviert das sshd-Jail, setzt backend = systemd und legt fest, dass Fail2ban über nftables sperrt. [9] Das systemd-Backend liest das systemd-Journal, das Jail braucht also keine eigene Logdatei. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

Mit den Standardwerten aus der mitgelieferten jail.conf sperrt Fail2ban eine Adresse für 10 Minuten, sobald sie innerhalb von 10 Minuten 5 Fehlversuche hatte. Die Datei selbst rät davon ab, sie zu bearbeiten: Eigene Änderungen gehören in jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Ersetzen Sie 198.51.100.7 durch Ihre eigene feste Adresse oder löschen Sie den Eintrag. Das Standard-Jail verwendet port = ssh; haben Sie SSH auf einen anderen Port verlegt, ergänzen Sie port = 2222. [10] Unter Debian 12 behalten Sie hier backend = systemd bei und installieren python3-systemd, die Python-Bibliothek für systemd, die dieses Backend nutzt. [10] Starten Sie Fail2ban danach neu und prüfen Sie, ob es läuft:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Prüfen, was sonst noch lauscht

Jeder offene Port ist ein weiterer möglicher Zugang. Der folgende UFW-Befehl zeigt jeden TCP-Port, auf dem ein Dienst lauscht, und jeden offenen UDP-Port, jeweils mit der Adresse (* steht für alle Schnittstellen), dem Programm dahinter und den Regeln, die dafür gelten. [8]

sudo ufw show listening

Ein an 127.0.0.1 gebundener Dienst ist nur vom Server selbst aus erreichbar. Öffentlich erreichbare Dienste, die Sie nicht brauchen, schalten Sie mit systemctl disable --now ab, so wie es die Hinweise zum openssh-Paket von Ubuntu für ssh.socket zeigen. [6]

sudo systemctl disable --now SERVICE_NAME