SSH auf einem VPS sicher härten: Anleitung

Warum SSH als Erstes abgesichert werden sollte

Mit SSH steuern Sie Ihren Server. Deshalb ist SSH das erste Ziel, das Angreifer prüfen. Sobald ein VPS online ist, beginnen Scanner, Benutzernamen und Passwörter auf Port 22 zu erraten. In Ihren Logs können Sie das innerhalb weniger Minuten beobachten. Beim Absichern von SSH entfernen Sie alles, was Angreifer erraten können: Deaktivieren Sie die Anmeldung mit Passwörtern vollständig, deaktivieren Sie die Anmeldung für root und erlauben Sie ausschließlich kryptografische Schlüssel. Danach können die ständigen Anmeldeversuche nicht mehr erfolgreich sein, weil kein Passwort vorhanden ist, das gefunden werden kann.

Dabei wird vorausgesetzt, dass SSH bereits funktioniert. Wenn Sie sich anmelden können, können Sie SSH absichern. Führen Sie die Schritte in der angegebenen Reihenfolge aus. Lassen Sie Ihre aktuelle Sitzung geöffnet, bis eine neue Sitzung funktioniert. So sperrt Sie ein Fehler nicht aus.

Schritt 1: Stellen Sie zuerst sicher, dass die Schlüsselauthentifizierung funktioniert

Bei der Schlüsselauthentifizierung wird ein Passwort durch ein Schlüsselpaar ersetzt: einen privaten Schlüssel, der auf Ihrem Computer bleibt, und einen öffentlichen Schlüssel, den Sie auf dem Server hinterlegen. Der Server kann so prüfen, dass Sie den privaten Schlüssel besitzen, ohne dass dieser jemals Ihren Computer verlässt. Deaktivieren Sie die Passwortauthentifizierung erst, nachdem Sie die Schlüsselauthentifizierung bestätigt haben. Andernfalls können Sie sich selbst aussperren.

Erstellen Sie auf Ihrem eigenen Computer einen Schlüssel, falls noch keiner vorhanden ist:

ssh-keygen -t ed25519

Kopieren Sie den öffentlichen Schlüssel auf den Server:

ssh-copy-id user@your-server

Öffnen Sie anschließend eine neue SSH-Sitzung. Wenn Sie sich anmelden können, ohne nach einem Passwort gefragt zu werden, funktioniert Ihr Schlüssel und Sie können die Passwortauthentifizierung sicher deaktivieren. Wenn die Anmeldung mit Permission denied (publickey) abgebrochen wird, verbirgt dieser eine Fehler fünf verschiedene Ursachen. Die Ausgabe von ssh -v zeigt Ihnen, welche Ursache vorliegt, bevor Sie weitere Änderungen vornehmen. Wenn Schlüssel für Sie neu sind oder Sie mehr als einen Computer verwenden, erklärt SSH-Grundlagen zur Schlüsselverwaltung das vollständige Modell: ein Schlüssel pro Gerät, die von sshd geforderten Berechtigungen und das Widerrufen eines Schlüssels, wenn ein Laptop verloren geht.

Schritt 2: sshd mit einer Drop-in-Datei absichern

Bearbeiten Sie /etc/ssh/sshd_config nicht direkt. Ubuntu 24.04 liest Drop-in-Dateien aus /etc/ssh/sshd_config.d/. Eine kleine Datei an dieser Stelle ist übersichtlicher, bleibt bei Paketaktualisierungen erhalten und lässt sich bei Problemen einfach entfernen. Der Name ist wichtig: sshd verwendet für jede Einstellung den ersten gelesenen Wert. Ubuntu-Cloud-Images liefern 50-cloud-init.conf mit PasswordAuthentication yes in diesem Verzeichnis aus. Nennen Sie Ihre Datei 00-, damit sie davor einsortiert wird und Vorrang hat. Eine Datei mit dem Namen 99- verliert stillschweigend. Erstellen Sie die Datei:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Fügen Sie Folgendes ein:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Jede Zeile schließt einen weiteren Zugangsweg. PasswordAuthentication no ist die wichtigste Einstellung: Wenn Passwörter deaktiviert sind, gibt es für einen Brute-Force-Angriff nichts zu erraten. KbdInteractiveAuthentication no schließt einen zweiten passwortbasierten Zugangsweg. PermitRootLogin no bedeutet, dass ein Angreifer Ihren Benutzernamen kennen und Ihren Schlüssel besitzen muss. Es reicht nicht, nur das einzige Konto namens root anzugreifen, das auf jedem System vorhanden ist.

Schritt 3: Konfiguration prüfen und anschließend neu laden

Prüfen Sie die Konfiguration auf Fehler, bevor Sie sie anwenden. Dadurch kann ein Tippfehler den Dienst nicht außer Betrieb setzen:

sudo sshd -t

Wenn keine Ausgabe erscheint, ist die Konfiguration gültig. Laden Sie SSH neu:

sudo systemctl reload ssh

Prüfen Sie anschließend die tatsächlich von sshd verwendeten Einstellungen. So erkennen Sie, ob ein Drop-in von einer anderen Datei überschrieben wurde:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Beide Ausgaben sollten no enthalten. Öffnen Sie jetzt in einem anderen Terminal eine völlig neue Sitzung, ohne die aktuelle Sitzung zu schließen. Wenn Sie mit Ihrem Schlüssel angemeldet werden, ist die Konfiguration fertig. Falls etwas nicht stimmt, bleibt Ihre erste Sitzung geöffnet, damit Sie den Fehler beheben können. Diese parallele Sitzung dient als Sicherheitsnetz. Überspringen Sie diesen Schritt daher niemals.

Schritt 4: Der optionale nicht standardisierte Port

Die Verlagerung von SSH von Port 22 auf beispielsweise 2222 macht den Dienst nicht wirklich sicherer, weil ein entschlossener Angreifer alle Ports scannt. Sie reduziert jedoch die Menge der Logeinträge, da die meisten automatisierten Scanner nur Port 22 prüfen. Wenn Sie diesen Schritt durchführen möchten, fügen Sie Port 2222 in Ihre Drop-in-Datei ein, erlauben Sie den neuen Port zuerst in der Firewall und führen Sie anschließend sudo systemctl daemon-reload && sudo systemctl restart ssh.socket aus. Stellen Sie die Verbindung mit ssh -p 2222 her. Unter Ubuntu 24.04 verwaltet ssh.socket den Listening-Port. Ein einfaches reload ssh lässt sshd daher weiterhin auf Port 22 lauschen. Erst ein Neustart des Sockets übernimmt den neuen Port. Betrachten Sie diese Änderung als Aufräumarbeit, nicht als Schutzmaßnahme.

Schritt 5: Zusätzliche Schutzmaßnahmen einrichten

Abgesicherte SSH-Schlüssel sind die Grundlage. Darauf bauen zwei weitere Schutzschichten auf.

Fail2ban überwacht Ihre Logs und sperrt Adressen, von denen wiederholt fehlgeschlagene Anmeldeversuche ausgehen. Dadurch wird das Scan-Rauschen reduziert und der Zugriff dieser Adressen frühzeitig blockiert. Fail2ban ergänzt die Authentifizierung ausschließlich mit Schlüsseln sinnvoll: Fail2ban unter Ubuntu einrichten, um SSH-Angriffe zu stoppen.

Noch wirksamer ist es, SSH vollständig aus dem öffentlichen Internet herauszuhalten. Wenn Sie SSH hinter einem WireGuard-VPN betreiben und Port 22 auf den Tunnel beschränken, kann niemand außerhalb des VPN den Dienst erreichen. Brute-Force-Versuche sind dann nicht nur schwierig, sondern grundsätzlich nicht möglich. Voraussetzung ist eine Firewall mit standardmäßiger Sperre für nicht erlaubten Datenverkehr. Eine solche Firewall wird unter UFW auf dem VPS einrichten beschrieben.

SSH ist nur ein Punkt einer größeren Checkliste: Die ersten 10 Minuten auf einem neuen VPS ordnen die Schritte. Automatische Sicherheitsupdates unter Ubuntu halten den Server anschließend auf dem aktuellen Stand. Das Absichern von SSH schützt jedoch nicht die dahinterliegenden Dienste. Wenn derselbe VPS beispielsweise einen Passwort-Tresor betreibt, behandelt Vaultwarden absichern die beiden Bereiche, die die Schlüsselauthentifizierung nicht abdeckt: das Admin-Token und die Backup-Datei.

FAQ

Wie deaktiviere ich die Passwortanmeldung für SSH unter Ubuntu 24.04?

Erstellen Sie eine Drop-in-Datei unter /etc/ssh/sshd_config.d/00-hardening.conf. Das Präfix 00 sorgt dafür, dass sie vor 50-cloud-init.conf einsortiert wird. Andernfalls würde der Wert in PasswordAuthentication yes gewinnen, weil sshd den ersten gelesenen Wert beibehält. Die Datei muss PasswordAuthentication no und KbdInteractiveAuthentication no enthalten. Führen Sie anschließend sudo sshd -t zur Prüfung aus und danach sudo systemctl reload ssh. Bestätigen Sie in einer neuen Sitzung, dass die Anmeldung per Schlüssel funktioniert, bevor Sie sich darauf verlassen. Wenn Sie eine Drop-in-Datei statt sshd_config bearbeiten, bleibt die Konfiguration bei Paketaktualisierungen erhalten und lässt sich einfach zurücknehmen.

Sollte ich die Root-Anmeldung über SSH deaktivieren?

Ja. Setzen Sie PermitRootLogin no, damit sich niemand direkt als root anmelden kann. Melden Sie sich als normaler Benutzer an und verwenden Sie sudo für administrative Aufgaben. root ist auf jedem Linux-System vorhanden. Wenn das Konto erreichbar bleibt, erhält ein Angreifer einen bekannten Benutzernamen als Ziel. Nach der Deaktivierung muss der Angreifer sowohl Ihren Kontonamen kennen als auch Ihren Schlüssel besitzen.

Macht eine Änderung des SSH-Ports meinen Server sicherer?

Nicht wesentlich. Wenn Sie den Port 22 ändern, werden Sie von einfachen Scannern nicht mehr erfasst, die nur Port 22 prüfen. Das reduziert die Log-Menge. Ein echter Angreifer scannt jedoch alle Ports und findet den Dienst trotzdem. Eine Authentifizierung ausschließlich per Schlüssel verhindert Einbrüche tatsächlich. Wenn Sie den Port ändern, geben Sie den neuen Port zuerst in der Firewall frei und führen Sie dann sudo systemctl daemon-reload && sudo systemctl restart ssh.socket aus. Unter Ubuntu 24.04 verwaltet der Socket den Listener. Ein einfaches Neuladen lässt sshd daher weiterhin auf Port 22 lauschen.

Benötige ich Fail2ban, wenn ich SSH-Schlüssel verwende?

Fail2ban ist optional, aber weiterhin nützlich. Bei einer Authentifizierung ausschließlich per Schlüssel können Passwortversuche nicht erfolgreich sein. Fail2ban hält Angreifer daher nicht vom Zugriff ab. Es begrenzt die Rate wiederholter Fehler von einer Adresse. Dadurch sinkt die Menge von Scanner-Meldungen in Ihren Logs, und wiederholte Angreifer werden frühzeitig gesperrt. Ein langsamer, verteilter Angriff bleibt jedoch unter dem Schwellenwert für die Sperre. Sie können Fail2ban zusätzlich zur Schlüsselauthentifizierung einsetzen. Idealerweise betreiben Sie SSH außerdem hinter einem VPN.

Wie stelle ich den SSH-Zugriff wieder her, wenn ich mich ausgesperrt habe?

Verwenden Sie die Webkonsole Ihres Providers. Sie erreicht den Server über eine serielle Verbindung oder eine VNC-Verbindung, die nicht über SSH läuft. Dort können Sie sich anmelden, die Drop-in-Datei sshd korrigieren und den Dienst neu laden. Genau deshalb sollten Sie eine neue SSH-Konfiguration in einem zweiten Terminal testen, bevor Sie die erste Sitzung schließen. Außerdem sollte die Schlüsselauthentifizierung bereits funktionieren, bevor Sie Passwörter deaktivieren.