SSH auf VPS absichern Anleitung

Warum SSH die Priorität bei der Härtung ist

SSH dient der Steuerung Ihres Servers. Daher ist es das primäre Ziel für Angriffe. Sobald ein VPS online ist, suchen Scanner auf Port 22 nach Benutzernamen und Passwörtern. Diese Aktivitäten sind innerhalb weniger Minuten in Ihren Logs sichtbar. Die Härtung von SSH dient dazu, erratbare Angriffsflächen zu eliminieren: Deaktivieren Sie die Passwort-Authentifizierung vollständig, deaktivieren Sie den Root-Login und erlauben Sie nur kryptografische Schlüssel. Nach diesen Maßnahmen schlagen Brute-Force-Angriffe fehl, da kein Passwort mehr zum Erraten existiert.

Dies setzt voraus, dass SSH bereits funktionsfähig ist. Wenn Sie sich einloggen können, können Sie das System härten. Führen Sie die Schritte nacheinander aus. Lassen Sie Ihre aktuelle Session offen, bis eine neue Verbindung erfolgreich getestet wurde, um einen Ausschluss vom System zu verhindern.

Schritt 1: Stellen Sie sicher, dass die Schlüssel-Authentifizierung funktioniert

Die Schlüssel-Authentifizierung ersetzt ein Passwort durch ein Schlüsselpaar: einen privaten Schlüssel, der auf Ihrem Computer verbleibt, und einen öffentlichen Schlüssel, den Sie auf dem Server hinterlegen. Der Server verifiziert den Besitz des privaten Schlüssels, ohne dass dieser Ihr Gerät verlassen muss. Deaktivieren Sie Passwörter erst, wenn die Schlüssel-Authentifizierung erfolgreich getestet wurde, um einen Ausschluss vom System zu verhindern.

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

ssh-keygen -t ed25519

Kopieren Sie den öffentlichen Teil auf den Server:

ssh-copy-id user@your-server

Öffnen Sie anschließend eine neue SSH-Sitzung. Wenn der Zugriff ohne Passwortabfrage erfolgt, funktioniert der Schlüssel und Sie können die Passwort-Authentifizierung deaktivieren. Falls Sie mit Schlüsseln neu sind oder mehrere Computer nutzen, erklärt SSH-Schlüsselverwaltung Grundlagen das vollständige Modell: ein Schlüssel pro Gerät, die von sshd geforderten Berechtigungen und das Widerrufen eines Schlüssels bei Verlust eines Laptops.

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 sauberer, bleibt bei Paket-Upgrades erhalten und lässt sich bei Problemen leicht entfernen. Der Dateiname ist entscheidend: sshd behält den ersten gelesenen Wert für jede Einstellung bei. Ubuntu Cloud-Images enthalten 50-cloud-init.conf mit PasswordAuthentication yes in diesem Verzeichnis. Benennen Sie Ihre Datei 00-, damit sie vor der vorhandenen Datei sortiert wird und Vorrang erhält; eine 99--Datei wird ohne Fehlermeldung ignoriert. Erstellen Sie eine neue Datei:

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

Fügen Sie dies 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 eine Sicherheitslücke. PasswordAuthentication no ist die wichtigste Einstellung: Ohne Passwörter gibt es keine Angriffsfläche für Brute-Force-Attacken. KbdInteractiveAuthentication no schließt einen weiteren Authentifizierungspfad per Passwort. PermitRootLogin no bedeutet, dass ein Angreifer Ihren Benutzernamen kennen und Ihren Key besitzen muss, anstatt nur das Standard-Konto root anzugreifen, das auf jedem System existiert.

Schritt 3: Konfiguration testen und neu laden

Prüfen Sie die Konfiguration auf Fehler, bevor Sie sie anwenden. So verhindern Sie, dass ein Tippfehler den Dienst unterbricht:

sudo sshd -t

Wenn keine Ausgabe erfolgt, 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 stellen Sie sicher, dass keine Konfiguration durch eine andere Datei überschrieben wurde:

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

Beide Ausgaben sollten no anzeigen. Öffnen Sie nun, ohne die aktuelle Sitzung zu schließen, eine neue Sitzung in einem anderen Terminal. Wenn die Anmeldung mit Ihrem Key erfolgt, ist der Vorgang abgeschlossen. Falls ein Fehler auftritt, bleibt Ihre erste Sitzung offen, um den Fehler zu beheben. Diese parallele Sitzung dient als Sicherheitsnetz und darf niemals übersprungen werden.

Schritt 4: Der optionale nicht-standardisierte Port

Das Verschieben von SSH von Port 22 auf einen Port wie 2222 erhöht die Sicherheit nicht wesentlich, da ein entschlossener Angreifer alle Ports scannt. Es reduziert jedoch das Rauschen in den Logs, da die meisten automatisierten Scanner nur Port 22 testen. Wenn Sie dies nutzen möchten, fügen Sie Port 2222 Ihrer Konfigurationsdatei hinzu, erlauben Sie den neuen Port zuerst in der Firewall, führen Sie dann sudo systemctl daemon-reload && sudo systemctl restart ssh.socket aus und verbinden Sie sich mit ssh -p 2222. Unter Ubuntu 24.04 verwaltet ssh.socket den Listening-Port, daher bleibt sshd bei einem einfachen reload ssh auf Port 22. Erst durch das Neustarten des Sockets wird der neue Port übernommen. Betrachten Sie dies als Ordnungsvorgang, nicht als Schutzmaßnahme.

Schritt 5: Weitere Verteidigungsebenen hinzufügen

Gehärtete SSH-Keys bilden die Basis. Zwei weitere Ebenen ergänzen diese Absicherung.

Fail2ban überwacht die Logs und sperrt IP-Adressen nach wiederholten Fehlversuchen. Dies reduziert das Rauschen durch Scanner und entfernt Angreifer frühzeitig. Fail2ban lässt sich ideal mit einer reinen Key-Authentifizierung kombinieren: siehe Fail2ban auf Ubuntu zur Abwehr von SSH-Angriffen.

Noch effektiver ist es, SSH vollständig vom öffentlichen Internet zu isolieren. Wenn Sie SSH hinter ein WireGuard VPN stellen und den Port 22 nur für den Tunnel freigeben, ist der Dienst von außerhalb des VPNs nicht erreichbar. Brute-Force-Angriffe sind dann nicht mehr nur schwierig, sondern unmöglich. Dies setzt eine Firewall mit einer Default-Deny-Policy voraus, wie sie in UFW auf dem VPS konfiguriert ist.

SSH ist nur ein Punkt auf einer umfassenderen Checkliste: Die ersten 10 Minuten auf einem neuen VPS ordnet die notwendigen Schritte, und Automatische Sicherheitsupdates auf Ubuntu halten das System dauerhaft auf dem neuesten Stand.

FAQ

Wie deaktiviere ich die Passwort-Anmeldung für SSH auf Ubuntu 24.04?

Erstellen Sie eine Drop-in-Datei unter /etc/ssh/sshd_config.d/00-hardening.conf (der Präfix 00 sorgt dafür, dass diese vor 50-cloud-init.conf sortiert wird, da sonst der Wert von PasswordAuthentication yes gewinnt, weil sshd den ersten gelesenen Wert verwendet). Die Datei muss PasswordAuthentication no und KbdInteractiveAuthentication no enthalten. Führen Sie sudo sshd -t zur Überprüfung aus und anschließend sudo systemctl reload ssh. Bestätigen Sie die Anmeldung per Key in einer neuen Session, bevor Sie sich darauf verlassen. Das Bearbeiten einer Drop-in-Datei anstatt der sshd_config bleibt bei Paket-Upgrades erhalten und lässt sich leicht rückgängig machen.

Sollte ich den Root-Login über SSH deaktivieren?

Ja. Setzen Sie PermitRootLogin no, damit sich niemand direkt als root anmelden kann. Melden Sie sich als normaler Benutzer an und nutzen Sie sudo für Administratoraufgaben. Root existiert auf jedem Linux-System; eine Erreichbarkeit bietet Angreifern einen bekannten Benutzernamen als Ziel. Durch die Deaktivierung müssen Angreifer Ihren Kontonamen kennen und Ihren Key besitzen.

Erhöht das Ändern des SSH-Ports die Sicherheit meines Servers?

Nicht signifikant. Das Verschieben von Port 22 verbirgt Sie vor einfachen Scannern, die nur Port 22 prüfen. Dies reduziert das Rauschen in den Logs, aber ein echter Angreifer scannt jeden Port und findet ihn trotzdem. Die reine Key-Authentifizierung verhindert Einbrüche effektiv. Wenn Sie den Port ändern, öffnen Sie zuerst den neuen Port in der Firewall und führen Sie dann sudo systemctl daemon-reload && sudo systemctl restart ssh.socket aus; unter Ubuntu 24.04 verwaltet der Socket den Listener, weshalb ein einfacher Reload sshd weiterhin auf Port 22 belässt.

Benötige ich Fail2ban, wenn ich SSH-Keys verwende?

Es ist optional, aber dennoch nützlich. Bei reiner Key-Authentifizierung können Passwort-Ratenversuche nicht erfolgreich sein; Fail2ban verhindert also nicht den Einbruch selbst. Es begrenzt die Rate wiederholter Fehlversuche von einer Adresse, was das Rauschen durch Scanner in den Logs reduziert und wiederholte Täter frühzeitig sperrt. Ein langsamer, verteilter Angriff bleibt jedoch unter der Sperrschwelle. Nutzen Sie Fail2ban zusätzlich zur Key-Authentifizierung und halten Sie SSH idealerweise hinter einem VPN.

Wie stelle ich die Verbindung wieder her, wenn ich mich bei SSH ausgesperrt habe?

Nutzen Sie die Web-Konsole Ihres Providers. Diese erreicht den Server über eine serielle oder VNC-Verbindung, die nicht über SSH läuft. Von dort aus können Sie sich anmelden, die sshd Drop-in-Datei korrigieren und den Dienst neu laden. Genau deshalb testet man eine neue SSH-Konfiguration in einem zweiten Terminal, bevor man die erste Session schließt, und warum die Key-Authentifizierung bereits funktionieren muss, bevor man Passwörter deaktiviert.