sshd_config härten: Checkliste mit Tests

Sitzung beim Testen offen halten

Das Neuladen von sshd beendet bestehende Verbindungen nicht. In unserem Test lief eine vor dem Reload geöffnete Sitzung weiter und endete danach normal. Lassen Sie also eine Sitzung mit root-Fähigkeit offen und testen Sie alles aus einem zweiten Terminal. Sperrt eine Einstellung Sie aus, beheben Sie das aus dem ersten.

Bevor Sie PasswordAuthentication no setzen, stellen Sie sicher, dass eine Schlüssel-Anmeldung funktioniert. Siehe SSH-Passwort-Anmeldung deaktivieren.

Drop-in-Datei nutzen und wissen, dass der erste Wert gewinnt

Bei den meisten Einstellungen behält sshd den ersten Wert, den es liest. Debian und Ubuntu haben Include /etc/ssh/sshd_config.d/*.conf am Anfang von sshd_config, ein Drop-in schlägt also eine Zeile weiter unten in der Hauptdatei. Auf unserem Testsystem hatte die Hauptdatei PasswordAuthentication yes in Zeile 125, und das Drop-in mit no gewann.

Dateien in diesem Ordner werden in der Reihenfolge ihrer Namen gelesen, und manche Cloud-Images bringen eigene mit, eine niedrige Nummer wie 10- ist also eine sichere Wahl. Hat Ihr System keine Include-Zeile, bearbeiten Sie sshd_config direkt und setzen die Einstellungen vor jeden Match-Block.

Die Einstellungen

# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

Einstellung	Upstream-Standard	Was die Änderung bewirkt
`PermitRootLogin no`	`prohibit-password`	root kann sich gar nicht anmelden, auch nicht mit Schlüssel. Man meldet sich als man selbst an und nutzt sudo, was festhält, wer was getan hat.
`PasswordAuthentication no`	`yes`	Beseitigt das Passwort-Raten als Angriff.
`KbdInteractiveAuthentication no`	`yes`	Schließt den anderen Weg zu einer Passwortabfrage. Lassen Sie es an, wenn Sie Einmalcodes über PAM nutzen.
`AllowUsers deploy`	Nicht gesetzt: jedes Konto kann es versuchen	Nur die aufgeführten Konten können sich anmelden. Ein Tippfehler hier sperrt alle aus, deshalb bleibt die erste Sitzung offen.
`MaxAuthTries 3`	6	Weniger Versuche pro Verbindung. Jeder von einem Client angebotene Schlüssel zählt, ein Client mit vielen Schlüsseln kann also an die Grenze stoßen. Siehe Too many authentication failures.
`LoginGraceTime 30`	120 Sekunden	Nicht authentifizierte Verbindungen werden früher getrennt.
`X11Forwarding no`	`no`, aber die Datei von Debian setzt `yes`	Schaltet eine Funktion ab, die die meisten Server nie nutzen.
`AllowAgentForwarding no`	`yes`	Siehe die Risiken von Agent-Forwarding.
`AllowTcpForwarding no`	`yes`	Verhindert SSH-Tunnel über diesen Server und seine Nutzung als Jump-Host. Setzen Sie es nicht, wenn Sie eines von beidem nutzen.

Das Handbuch ist bei einer Grenze eindeutig: Das Abschalten von TCP-Forwarding verbessert die Sicherheit nicht, solange Benutzern nicht auch die Shell verweigert wird, denn wer eine Shell hat, kann seinen eigenen Forwarder ausführen. Betrachten Sie es als Aufräumen für Konten mit Shell und als echte Einschränkung nur für Konten ohne.

Lassen Sie MaxStartups und PerSourcePenalties auf ihren Standardwerten, wenn Sie keinen Grund haben. Sie bremsen in aktuellen Versionen bereits Verbindungsfluten.

Vor dem Neuladen prüfen

sshd -t prüft Syntax und Host-Schlüssel. Es gibt nichts aus, wenn alles in Ordnung ist. Ein Tippfehler liefert einen Fehler und einen Exit-Code ungleich null:

$ sudo sshd -t
/etc/ssh/sshd_config.d/99-typo.conf: line 1: Bad configuration option: PermitRootLogn
/etc/ssh/sshd_config.d/99-typo.conf: terminating, 1 bad configuration options

sshd -T gibt die Werte aus, die sshd nach dem Zusammenführen aller Dateien wirklich verwenden wird. Die Namen erscheinen in Kleinbuchstaben:

sudo sshd -T | grep -iE '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers|maxauthtries|logingracetime|x11forwarding|allowagentforwarding|allowtcpforwarding) '

Nutzen Sie Match-Blöcke, ergänzen Sie -C, um das Ergebnis für eine bestimmte Verbindung zu sehen:

sudo sshd -T -C user=deploy,host=example.com,addr=203.0.113.10 | grep -i allowtcpforwarding

sshd -T liest die Dateien auf der Platte, nicht das, was der laufende Daemon geladen hat. Es zeigt, was Sie nach dem Reload erhalten.

Neu laden und aus einem zweiten Terminal testen

# Debian, Ubuntu
sudo systemctl reload ssh
# Red Hat family
sudo systemctl reload sshd

Probieren Sie dann jeden dieser Befehle. Der erste muss gelingen, die anderen müssen scheitern:

ssh deploy@server 'echo ok'
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password deploy@server
ssh root@server
ssh -N -L 8022:127.0.0.1:22 deploy@server

Der letzte Befehl scheitert nicht bei der Anmeldung. Er verbindet sich, und der Forward wird abgelehnt, sobald Sie den lokalen Port nutzen. Das Server-Log zeigt dann eine Zeile wie diese:

refused local port forward: originator 127.0.0.1 port 63434, target 127.0.0.1 port 22

Ein abgelehnter Root-Login erscheint im Log als User root from 203.0.113.10 not allowed because not listed in AllowUsers.

Moderne Algorithmen: nur wenn Sie sie einschränken müssen

Die aktuellen OpenSSH-Standards sind gut. Unter OpenSSH 10.0 beginnt die Standardliste für den Schlüsselaustausch mit dem hybriden Post-Quanten-Verfahren mlkem768x25519-sha256. Eigene Listen bedeuten, dass Sie sie pflegen müssen, tun Sie es also, wenn ein Audit es verlangt oder Ihr System alt ist. Dieser Satz behält nur moderne Optionen:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Ältere OpenSSH-Versionen kennen einige dieser Namen nicht. Führen Sie auf dem Server ssh -Q kex, ssh -Q cipher und ssh -Q mac aus und entfernen Sie, was nicht aufgeführt ist. Prüfen Sie, was ein Client wirklich aushandelt:

ssh -v deploy@server true 2>&1 | grep -E 'kex: algorithm|server->client cipher'

Alte Clients und Geräte scheitern mit dieser Meldung, für die es eine eigene Anleitung gibt:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found.

Diese Liste entfernt auch die NIST-Kurve und Diffie-Hellman-Austausche, testen Sie also jedes Gerät und jedes Skript, das sich mit dem Server verbindet, bevor Sie sie behalten.

Was das nicht abdeckt

Diese Einstellungen verkleinern, was gegen sshd versucht werden kann. Sie patchen OpenSSH nicht, halten Sie es also aktuell. Sie begrenzen auch nicht, was ein angemeldeter Benutzer tun kann. Bei wiederholten Angriffen in Ihren Logs siehe fail2ban für SSH.

Wer es versucht, zeigt SSH-Anmeldeversuche prüfen.

Fragen

Beendet ein Reload von sshd meine offene SSH-Sitzung?

Nein. Bestehende Sitzungen laufen nach dem Reload weiter. Nur neue Anmeldungen nutzen die neuen Einstellungen, deshalb testen Sie in einem zweiten Terminal.

Wohin gehören eigene sshd-Einstellungen?

In eine Datei unter /etc/ssh/sshd_config.d/ mit niedriger Nummer, etwa 10-hardening.conf. sshd behält den ersten gelesenen Wert, eine früh gelesene Drop-in-Datei gewinnt also.

Wie prüfe ich sshd_config auf Fehler?

Führen Sie sudo sshd -t aus. Bei gültiger Konfiguration gibt es nichts aus, sonst einen Fehler mit einem Exit-Code ungleich null.

Quellen

Mehr zu Server absichern

Alle Anleitungen