Simple SSH Hardening - SSH Zugriff absichern

Diese Anleitung beschränkt den SSH-Zugang auf Public-Key-Anmeldung mit einem normalen Benutzerkonto. Sie setzt einen Linux-Server mit OpenSSH, einen bereits funktionierenden Schlüsselzugang und einen administrativen Benutzer mit sudo voraus. Sie ist nicht für Setups gedacht, die zusätzlich PAM-basierte Zwei-Faktor-Anmeldung über Keyboard-Interactive benötigen.

Bestehenden Zugang zuerst prüfen

Halte die bestehende SSH-Sitzung während aller Änderungen offen. Stelle außerdem sicher, dass du bei einem Fehler über eine Serverkonsole oder einen anderen unabhängigen Zugang zurückkommst.

Öffne vor der Änderung ein zweites Terminal auf deinem Rechner und prüfe die Anmeldung mit deinem Schlüssel. Ersetze admin, server.example.com und den Schlüsselpfad durch deine Werte:

ssh -o ControlMaster=no -o ControlPath=none \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no \
  -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 admin@server.example.com

Mit ControlPath=none wird eine neue Verbindung aufgebaut, statt eine vorhandene SSH-Verbindung wiederzuverwenden. Eine Abfrage der lokalen Schlüssel-Passphrase ist dabei weiterhin möglich. Prüfe in der neuen Sitzung auch, dass sudo -v funktioniert.

Serverkonfiguration anpassen

Sichere die Konfigurationsdatei und alle eingebundenen Dateien, die du ändern wirst. Bearbeite anschließend auf dem Server die bestehende Konfiguration:

sudoedit /etc/ssh/sshd_config

Die folgenden Einstellungen gehören in den globalen Teil vor den ersten Match-Block. Bestehende Werte gezielt ändern, nicht denselben Block mehrfach anhängen:

Port 22
PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PermitEmptyPasswords no

KbdInteractiveAuthentication ist der aktuelle Name der Einstellung; ChallengeResponseAuthentication ist ein veralteter Alias. Bei vielen Optionen zählt der zuerst gelesene Wert. Prüfe deshalb auch Include-Dateien, etwa in /etc/ssh/sshd_config.d/, und benutzerspezifische Match-Regeln. Die Details stehen in der OpenSSH-Dokumentation zu sshd_config.

Der Standard-Port 22 bleibt hier unverändert. Falls dein Server bereits einen anderen Port nutzt, behalte diesen für die Umstellung bei und ergänze ihn beim Client mit -p. Ein Portwechsel ist kein Ersatz für sichere Authentifizierung und würde zusätzliche Änderungen an Firewall, Provider-Regeln und gegebenenfalls Socket-Aktivierung erfordern.

Prüfen, dann neu laden

Prüfe auf dem Server zuerst Konfiguration und Host-Schlüssel:

sudo sshd -t

Bei Fehlern nicht neu laden. Korrigiere die Konfiguration und wiederhole die Prüfung. Falls sshd nicht im Suchpfad liegt, verwende den vollständigen Pfad, beispielsweise /usr/sbin/sshd.

Prüfe zusätzlich die effektiven Werte. Ersetze im folgenden Beispiel Benutzer, Client-Hostname und Client-IP durch die Daten der tatsächlich zu prüfenden Verbindung; bei Regeln für lokale Adresse oder Port ergänze auch laddr und lport:

sudo sshd -T -C user=admin,host=client.example.com,addr=192.0.2.10

Kontrolliere insbesondere pubkeyauthentication yes, authenticationmethods publickey, passwordauthentication no, kbdinteractiveauthentication no und permitrootlogin no. So werden auch passende Match-Regeln berücksichtigt. sshd -t und -T starten keinen zusätzlichen SSH-Daemon; sie validieren die Konfiguration.

Bei einem bereits laufenden systemd-Dienst namens ssh.service, etwa unter Debian/Ubuntu, kannst du nach erfolgreicher Prüfung neu laden:

sudo sshd -t && sudo systemctl reload ssh.service

Heißt der Dienst auf deinem System sshd.service, verwende stattdessen diesen Namen. Prüfe bei anderen Dienstmanagern deren Reload-Verfahren. Das Beispiel ändert keine Listening-Ports und keine Socket-Konfiguration. Die Ubuntu-Dokumentation zeigt ebenfalls das Neuladen von ssh.service nach Konfigurationsänderungen.

Zweite Verbindung nach der Änderung testen

Wiederhole jetzt aus einem neuen Terminal den Schlüssel-Login aus dem ersten Abschnitt und prüfe erneut sudo -v. Schließe die ursprüngliche Sitzung erst, wenn dieser neue Login funktioniert. Scheitert er, stelle über die noch offene Sitzung oder die Serverkonsole die gesicherten Konfigurationsdateien wieder her, prüfe mit sshd -t und lade den Dienst erneut.

Für hardwaregestützte SSH-Schlüssel siehe auch meinen YubiKey-Guide zu OpenPGP und SSH.

Prüfstand

Der Konfigurationsblock wurde am 17. September 2026 mit OpenSSH 10.3p1 auf macOS in einer isolierten Testdatei und mit einem temporären Host-Schlüssel geprüft (sshd -t und sshd -T). Das ist keine vollständige Prüfung eines Linux-Deployments: Dienstname, bestehende Regeln, Schlüsselberechtigungen, Firewall und tatsächlicher Login müssen auf dem Zielserver geprüft werden.