Den SSH-Server sicher einrichten

Modul 2: SSH und Schlüssel · Lesezeit: 12 Minuten

Lernziel: Nach dieser Lektion können Sie die Anmeldung mit Passwort und den Root-Login mit Passwort deaktivieren, prüfen, welche Einstellung tatsächlich gilt, und das alles, ohne sich selbst auszusperren.

Kernbegriffe: sshd, sshd_config, sshd_config.d, der erste Wert zählt, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, zweite Sitzung, cloud-init, ssh.socket

Zuerst das Sicherheitsnetz

In dieser Lektion schließen Sie eine Tür, durch die Sie selbst hindurch müssen. Ein Tippfehler kann bedeuten, dass Sie nicht mehr hineinkommen. Deshalb gilt immer, bevor Sie beginnen:

1. Zwei Schlüssel funktionieren (Lektion 2.1), und Sie haben in einem neuen Fenster geprüft, dass die Anmeldung mit einem Schlüssel klappt.
2. Ein Snapshot Ihres VPS. Bei WebOké erstellen Sie ihn in der VPS-Ansicht, bei anderen Anbietern heißt er ebenfalls Snapshot oder Image. Geht etwas schief, spielen Sie ihn zurück.
3. Die Konsole Ihres Anbieters kennen Sie: Darüber kommen Sie ohne SSH auf den Server.
4. Ihre aktuelle SSH-Sitzung bleibt bis zum Schluss geöffnet. Eine laufende Sitzung funktioniert weiter, auch wenn Sie die Einstellungen ändern oder den Dienst neu laden. Jede Änderung testen Sie in einem zweiten Fenster.

Wo die Einstellungen stehen

Der SSH-Server heißt sshd. Seine Einstellungen stehen in /etc/ssh/sshd_config. Unter Debian und Ubuntu steht ganz oben in dieser Datei folgende Zeile:

Include /etc/ssh/sshd_config.d/*.conf

Alle Dateien mit .conf im Verzeichnis sshd_config.d werden also vor dem Rest der Hauptdatei gelesen, und zwar in alphabetischer Reihenfolge. Das ist praktisch: Sie legen Ihre eigenen Einstellungen in einer eigenen Datei ab und lassen die Hauptdatei unverändert, sodass ein Update des Pakets Ihre Änderungen nicht berührt.

Das hat aber eine Folge, die viele überrascht. In sshd_config gilt: Für jede Einstellung zählt der erste Wert, auf den sshd stößt. Spätere Zeilen mit derselben Einstellung werden ignoriert. Wer also ganz unten in sshd_config PasswordAuthentication no einträgt, setzt sich nicht gegen eine Datei in sshd_config.d durch, in der yes steht.

Die Falle mit cloud-init

Viele VPS-Images werden beim ersten Start von cloud-init eingerichtet. Je nachdem, wie das Image und die Installation konfiguriert sind, schreibt cloud-init eine Datei wie /etc/ssh/sshd_config.d/50-cloud-init.conf mit beispielsweise diesem Inhalt:

PasswordAuthentication yes

Weil diese Datei vor der Hauptdatei gelesen wird, ist der Passwort-Login aktiv, egal was Sie in sshd_config eintragen. Gehen Sie also nicht einfach davon aus, sondern sehen Sie nach:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Es gibt zwei saubere Lösungen: Ändern Sie diese Datei auf no, oder legen Sie Ihre eigenen Einstellungen in einer Datei ab, die im Alphabet früher kommt, etwa 00-beveiliging.conf. Eine Datei 99-mijn.conf funktioniert gerade nicht, denn dann hat sich cloud-init bereits durchgesetzt.

Die Einstellungen, auf die es ankommt

Legen Sie Ihre eigene Datei an:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

mit diesem Inhalt:

# Anmeldung nur mit Schlüssel
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Was bedeutet jede Zeile?

• PasswordAuthentication no: Der Server akzeptiert kein Passwort mehr. Der Standardwert von OpenSSH ist yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" ist ein zweiter Weg, über PAM nach einem Passwort zu fragen. Lassen Sie diese Einstellung aktiv, kann jemand trotzdem ein Passwort ausprobieren, auch wenn PasswordAuthentication auf no steht. In älteren Anleitungen heißt diese Einstellung ChallengeResponseAuthentication; seit OpenSSH 8.7 ist das ein veralteter anderer Name für dasselbe. Debian setzt sie standardmäßig bereits auf no, tragen Sie sie aber trotzdem ein: Dann ist es eindeutig und stimmt auch auf anderen Systemen.
• PermitRootLogin prohibit-password: root darf sich anmelden, aber nur mit einem Schlüssel. Das ist seit OpenSSH 7.0 der Standard. Strenger ist PermitRootLogin no: root kommt überhaupt nicht per SSH hinein, Sie melden sich als normaler Benutzer an und verwenden sudo (Lektion 3.2). Setzen Sie no erst, wenn Sie sicher sind, dass die Anmeldung als dieser Benutzer und sudo funktionieren.

Optional, für alle, die mehr möchten:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers lässt nur die genannten Benutzer hinein; jeder andere Name wird abgewiesen, auch wenn er einen gültigen Schlüssel hat. Praktisch, aber vergessen Sie sich selbst nicht, und vergessen Sie nicht, die Liste zu ergänzen, wenn Sie einen zweiten Administrator hinzufügen. AuthenticationMethods publickey legt in einer Zeile fest, dass nur Schlüssel gelten.

Testen, anwenden, prüfen

Zuerst lassen Sie sshd die Datei prüfen. Das startet nichts und ändert nichts:

root@web1:~# sshd -t
root@web1:~#

Keine Ausgabe bedeutet: keine Fehler. Bei einem Tippfehler sehen Sie die Zeile und die Datei. Erst dann laden Sie den Dienst neu:

root@web1:~# systemctl reload ssh

Unter Debian und Ubuntu heißt der Dienst ssh, unter AlmaLinux und Rocky Linux sshd.

Anschließend prüfen Sie, welcher Wert tatsächlich gilt. sshd -T zeigt die vollständige, ausgewertete Konfiguration mit allen verarbeiteten Include-Dateien:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password ist der alte Name von prohibit-password. OpenSSH-Versionen vor 10.1, etwa unter Debian 13 und Ubuntu 24.04, zeigen noch den alten Namen; neuere zeigen prohibit-password. Die Bedeutung ist dieselbe.)

Und jetzt das Wichtigste: Testen Sie in einem zweiten Fenster, während das erste geöffnet bleibt.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Funktioniert das, versuchen Sie bewusst, sich mit einem Passwort anzumelden. Das muss fehlschlagen:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

Hinter Permission denied steht in Klammern, welche Anmeldemethoden der Server noch anbietet. Steht dort nur publickey, ist alles in Ordnung. Steht dort auch password oder keyboard-interactive, gilt irgendwo noch ein anderer Wert: Sehen Sie erneut mit sshd -T nach.

Genau diese Liste prüft auch die Kursaufgabe, und zwar von außen. Ihr SSH-Client fragt bei jeder Verbindung zuerst, welche Methoden erlaubt sind, mit einer Anfrage vom Typ "none". Der Server antwortet mit der Liste, ohne dass ein Passwort oder Schlüssel ausprobiert wird.

Ubuntu 24.04 und neuer: ssh.socket

Unter Ubuntu lauscht seit Version 22.10 nicht sshd selbst auf Port 22, sondern systemd, über ssh.socket. Erst wenn eine Verbindung eingeht, startet systemd den SSH-Dienst. Für die Einstellungen in dieser Lektion spielt das keine Rolle: systemctl reload ssh oder restart ssh genügt.

Es spielt aber eine Rolle, wenn Sie den Port oder die Lauschadresse ändern (Port, ListenAddress). Seit Ubuntu 24.04 liest systemd diese Werte aus sshd_config, allerdings erst nach:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Vergessen Sie das, lauscht der Server einfach weiter auf dem alten Port. Schlimmer noch: Stellen Sie zuerst Ihre Firewall auf einen neuen Port um und SSH bleibt auf dem alten, sperren Sie sich selbst aus. Prüfen Sie immer mit ss -tlnp | grep ssh, worauf tatsächlich gelauscht wird (Lektion 5.1), und tragen Sie den neuen Port in Ihre Firewall ein, bevor Sie den alten schließen. Ob ein anderer Port sinnvoll ist, lesen Sie in Lektion 2.3.

Wenn doch etwas schiefgeht

Kommen Sie nicht mehr hinein, öffnen Sie die Konsole Ihres Anbieters, melden sich als root an (mit dem Passwort, denn die Konsole ist eine "Tastatur am Server" und kein SSH) und machen Ihre Datei rückgängig:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Klappt auch das nicht, spielen Sie den Snapshot zurück. Bei WebOké können Sie in der VPS-Ansicht auch ein neues Root-Passwort setzen; andere Anbieter haben oft eine vergleichbare Schaltfläche oder einen Rettungsmodus (Rescue).

Unter AlmaLinux und Rocky Linux

Der Dienst heißt sshd (systemctl reload sshd). Auch dort steht ein Include /etc/ssh/sshd_config.d/*.conf ganz oben, und das System liefert eigene Dateien in diesem Verzeichnis mit; es gilt dieselbe Regel "der erste Wert zählt". Ändern Sie den Port, muss SELinux diesen Port ebenfalls erlauben (semanage port -a -t ssh_port_t -p tcp 2222) und firewalld ihn öffnen.

Zusammenfassung

• In sshd_config zählt der erste Wert; Dateien in sshd_config.d werden zuerst gelesen. Legen Sie Ihre eigenen Einstellungen in einer Datei wie 00-beveiliging.conf ab.
• Setzen Sie PasswordAuthentication no und KbdInteractiveAuthentication no; root nur mit Schlüssel (prohibit-password) oder überhaupt nicht (no).
• Prüfen Sie mit sshd -t vor dem Neuladen und mit sshd -T, welcher Wert tatsächlich gilt; achten Sie auf ein 50-cloud-init.conf.
• Testen Sie in einem zweiten Fenster und lassen Sie die erste Sitzung geöffnet. Kennen Sie die Konsole und erstellen Sie vorab einen Snapshot.
• Unter Ubuntu 24.04+ erfordert ein anderer Port systemctl daemon-reload und systemctl restart ssh.socket.

Quiz

Aufgabe

Aufgabe Z2.2: Passwort-Login ist deaktiviert. Deaktivieren Sie den Passwort-Login und keyboard-interactive wie in dieser Lektion beschrieben, und lassen Sie dann das Programm von außen nachsehen. Geben Sie die IP-Adresse oder den Hostnamen Ihres Servers ein, den SSH-Port (standardmäßig 22) und den Benutzernamen, mit dem Sie sich selbst anmelden (zum Beispiel anna, nicht root oder einen erfundenen Namen). Das Programm meldet sich nicht an: Es fragt nur, wie jeder SSH-Client vor der Anmeldung, welche Anmeldemethoden Ihr Server für diesen Benutzer anbietet. Richtig ist: nur publickey.

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die VPS-Ansicht von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• Ihren VPS absichern: die ersten fünf Minuten
• Kein Zugriff mehr auf Ihren VPS: Was nun?
• Snapshots und Backups Ihres VPS
• Handbuch zu sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189