Einen SSH-Server härten, ohne sich selbst auszusperren

Ziel

Die Angriffsfläche eines SSH-Servers gegenüber erratenen Passwörtern, gestohlenen Agenten und Fehlkonfiguration verringern, dabei aber während der Änderung einen garantierten Weg zurück hinein behalten.

Voraussetzungen

Root- oder sudo-Rechte auf dem Host, ein Schlüsselpaar auf der Maschine der administrierenden Person (ssh-keygen -t ed25519 mit Passphrase), der öffentliche Schlüssel bereits in ~/.ssh/authorized_keys des zu verwendenden Kontos, sowie eine nachweislich funktionierende Out-of-Band-Konsole (Cloud-Provider-Konsole, IPMI).

Schritte

1. Eine zweite SSH-Sitzung öffnen und für den gesamten Vorgang offen lassen; eine laufende Sitzung übersteht einen Neustart von sshd und erlaubt es, einen Fehler rückgängig zu machen.
2. Bestätigen, dass der Schlüssel-Login in einer frischen Sitzung funktioniert (ssh -o PasswordAuthentication=no user@host).
3. /etc/ssh/sshd_config oder eine Datei in sshd_config.d/ bearbeiten: PasswordAuthentication no, KbdInteractiveAuthentication no (dessen Standard ist laut sshd_config(5) yes), PermitRootLogin no (oder prohibit-password, wo Root-Schlüssel unvermeidlich sind), PubkeyAuthentication yes.
4. Einschränken, wer sich anmelden darf, mit AllowUsers oder AllowGroups; für Automatisierungskonten einen Match User-Block mit ForceCommand, AllowTcpForwarding no und PermitTTY no ergänzen.
5. Das Fenster vor der Authentifizierung verengen: MaxAuthTries 3 (Standard 6), LoginGraceTime 30 (Standard 120 Sekunden), sowie PerSourcePenalties, falls die Serverversion es unterstützt.
6. Ungenutztes deaktivieren: X11Forwarding no, AllowAgentForwarding no, wo niemand es braucht (das Handbuch merkt an, dass dies nur hilft, wenn Nutzende auch keinen Shell-Zugriff haben).
7. sshd -t ausführen, um die Datei zu prüfen, dann den Dienst neu starten oder neu laden und sich aus einer dritten Sitzung anmelden, bevor die zweite geschlossen wird.
8. Auf Client-Seite ProxyJump verwenden, um Hosts hinter einem Bastion-Host zu erreichen, statt ForwardAgent; ssh(1) warnt, dass jeder, der die Dateiberechtigungen auf dem entfernten Host umgehen kann, einen weitergeleiteten Agenten nutzen kann. Ist Forwarding unvermeidlich, Schlüssel mit ssh-add -c laden, sodass jede Nutzung eine Bestätigung verlangt.
9. Die Änderung und den Fingerabdruck des Host-Schlüssels des Servers im Runbook festhalten.

Erwartetes Ergebnis

Passwortraten bringt nichts, root lässt sich nicht direkt anvisieren, nur gelistete Konten existieren als Ziele, und die administrierende Person kann sich weiterhin mit dem getesteten Schlüssel anmelden. journalctl -u ssh (oder sshd, je nach Distribution) zeigt fehlgeschlagene Versuche, die nach drei Versuchen abgebrochen werden.

Grenzen und Prüfbasis

Distributionspakete bringen eigene Standardwerte und Drop-in-Dateien mit; sshd_config(5) besagt, dass für ein Schlüsselwort der zuerst gefundene Wert verwendet wird, und dass Include-Globs in lexikalischer Reihenfolge expandiert werden, weshalb die effektive Konfiguration mit sshd -T geprüft werden sollte. Diese Checkliste deckt nur sshd-Einstellungen ab; Begrenzungen auf Netzwerkebene (Firewall, Port Knocking, Sperren nach Fail2ban-Art) und Zwei-Faktor-Authentifizierung sind separate Entscheidungen. Optionsnamen und Standardwerte stammen aus den zitierten Manpages; es wird keine Messung behauptet.