SSH-Hardening 2026: Algorithmen, Zertifikate und Bastion-Hosts

Jedes Mal, wenn wir shodan.io oeffnen und nach port:22 filtern, finden wir hunderttausende Server, die weiterhin ssh-rsa mit SHA-1, im Internet exponierte Passwort-Authentifizierung und MACs wie hmac-sha1 akzeptieren. 2026 ist das keine vergessene Legacy-Konfiguration mehr, sondern technische Schuld, die Zinsen in Form von Vorfaellen zahlt. SSH-Hardening ist laengst keine Sechs-Zeilen-Checkliste in sshd_config mehr, sondern ein kleines Subsystem mit interner Zertifizierungsstelle, auditierbarem Bastion, kurzlebigem Schluesselmaterial und zentralisierter Telemetrie. Dieser Leitfaden geht den kompletten Stack durch, so wie ihn das Basilisk-Team im Labor aufbaut, bevor er in die Produktion geht, mit konkreter Konfiguration, echten Befehlen und den Fehlermustern, die uns immer wieder begegnen. Wichtig vorab: keine einzelne Direktive haertet SSH, es ist das Zusammenspiel aus starker Authentifizierung, enger Netzwerkexposition, kurzlebigem Schluesselmaterial und Detektion, das den Unterschied macht. Ein Host mit perfekten Algorithmen, aber geteiltem Root-Passwort ist genauso verwundbar wie einer mit schwachen Ciphers und Zertifikaten, nur an anderer Stelle. Deshalb behandeln wir das Thema als System und nicht als Liste einzelner Einstellungen.

Warum SSH weiterhin die Lieblingstuer der Angreifer ist

SSH ist das Fernwartungsprotokoll fuer praktisch das gesamte Linux-Oekosystem und die meiste Netzwerktechnik, was es zur wertvollsten Zugangsberechtigung im Bestand macht. Angreifer lieben es, weil ein einziger funktionierender Schluessel oder ein Passwort eine interaktive Shell mit den Rechten des Zielkontos liefert, ganz ohne Exploit-Kette. Die drei wiederkehrenden Ursachen sind: wiederverwendete oder nie rotierte Schluessel, die den Mitarbeiter ueberleben, der sie erstellt hat; Passwort-Authentifizierung, die von Botnetzen brute-forced wird; und der Downgrade auf schwache Algorithmen, der einem Netzwerkangreifer erlaubt, den Handshake zu manipulieren. Behandle SSH als Identitaetssystem, nicht als Werkzeug. Jede Designentscheidung unten reduziert eine dieser drei Klassen, und die Reihenfolge zaehlt: repariere Authentifizierung vor Telemetrie, denn einen Einbruch zu protokollieren, den du nicht verhindern kannst, sagt dir nur, wann du verloren hast.

Nicht verhandelbare sshd_config-Basis

Beginne beim Server-Daemon. In einer modernen /etc/ssh/sshd_config erzwinge PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no, UsePAM yes und PermitEmptyPasswords no. Ergaenze MaxAuthTries 3, LoginGraceTime 20 und ClientAliveInterval 300, damit halboffene Sitzungen sterben. Begrenze die Reichweite mit AllowGroups ssh-users statt jedem lokalen Konto Zugriff zu geben. Pruefe die Datei vor dem Reload mit sshd -t und aendere den Live-Port nie ohne zweite offene Sitzung, denn ein Tippfehler in einem Match-Block sperrt dich aus. Diese Direktiven sind das Fundament: keine kostet etwas, jede entfernt ein Angriffsprimitiv.

Moderne Algorithmen und post-quantensicherer Schluesselaustausch

Begrenze KexAlgorithms auf sntrup761x25519-sha512@openssh.com,curve25519-sha256, Ciphers auf chacha20-poly1305@openssh.com,aes256-gcm@openssh.com und MACs auf hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com. Das sntrup761-Hybrid liefert seit OpenSSH 9.0 post-quantum-Resistenz, und 2026 gibt es keinen Grund, das nicht zu aktivieren: es schuetzt heute aufgezeichneten Verkehr gegen die Quantenentschluesselung von morgen, das harvest-now-decrypt-later-Problem. Fuehre ssh-audit vorher und nachher aus. Der Unterschied zwischen C+ und A liegt im Wesentlichen im Abschalten von diffie-hellman-group14-sha1, CBC-Ciphers und verkuerzten MACs. Bevorzuge die etm-Varianten (encrypt-then-MAC), weil sie den Ciphertext authentifizieren, nicht den Klartext. Behandle das Bestehen von ssh-audit als Vorbedingung, nicht als Lieferergebnis.

Verstreute Schluessel durch eine interne SSH-CA ersetzen

Der wirkliche Reifesprung kommt, wenn du authorized_keys-Dateien in Rente schickst und Zertifikate ausstellst. Erzeuge ein CA-Schluesselpaar (ssh-keygen -t ed25519 -f ssh_user_ca), dessen privater Teil nur in einem HSM oder auf einem Offline-Signierer liegt, und signiere Benutzerzertifikate mit kurzer TTL von 4 bis 12 Stunden: ssh-keygen -s ssh_user_ca -I alice@corp -n alice -V +8h user_key.pub. Auf jedem Server verteilst du nur den oeffentlichen CA-Schluessel via TrustedUserCAKeys /etc/ssh/ca.pub. Benutzer authentifizieren sich mit einem von step-ca, HashiCorp Vault SSH oder Teleport ausgestellten Zertifikat, gebunden an das Firmen-SSO. Das Entziehen von Zugriff fuer einen ehemaligen Mitarbeiter ist keine Jagd nach Schluesseln auf 400 Hosts mehr, sondern schlicht das Nicht-Erneuern des Zertifikats. Bei internen Pentests bricht allein diese Aenderung rund die Haelfte der Lateral-Movement-Pfade ueber verwaiste Schluessel, weil ein gestohlener Schluessel wertlos ist, sobald sein Zertifikat abgelaufen ist.

Der Bastion als Identitaets-Proxy, nicht als Jump-Box

Ein gehaerteter Bastion ist kein beliebiger Linux mit offenem SSH. Betrachte ihn als Identitaets-Proxy: er nimmt die Benutzerverbindung an, prueft das Zertifikat gegen die CA, zeichnet die gesamte Session auf (Input und Output) und oeffnet ueber ProxyJump eine zweite SSH-Verbindung zum Ziel. Teleport, HashiCorp Boundary und die Kombination step-ca + auditd + tlog decken das ab. In einer typischen Fintech-Konfiguration lebte der Bastion in einer isolierten VPC mit Security Group, die nur Port 22 vom Firmen-VPN zuliess, und die internen Server lehnten jede SSH-Verbindung ab, die nicht aus dem Bastion-CIDR kam. Damit kollabiert die Angriffsflaeche von hunderten aus dem Internet erreichbaren IPs auf einen einzigen ueberwachten Punkt, an dem jeder Tastenanschlag protokolliert und jede Session einer menschlichen Identitaet zurechenbar ist.

Client-seitiges Hardening und hardwaregestuetzte Schluessel

Vergiss den Client nicht. Erzwinge ~/.ssh/config mit HashKnownHosts yes, VerifyHostKeyDNS yes wo anwendbar, und erzeuge einen hardwaregestuetzten Schluessel mit ssh-keygen -t ed25519-sk, damit der private Teil nie einen YubiKey verlaesst und jede Authentifizierung eine physische Beruehrung braucht. Betreibe ssh-agent mit Bestaetigung (ssh-add -c), damit eine kompromittierte Workstation den Agent-Socket nicht stillschweigend wiederverwenden kann. Deaktiviere Optionen, die du nicht brauchst: AllowAgentForwarding no und AllowTcpForwarding no am Server, sofern kein dokumentierter Fluss sie verlangt, denn Agent-Forwarding zu einem nicht vertrauenswuerdigen Host erlaubt diesem, deinen Agent zu kapern, solange der Socket lebt.

CI/CD und Service-Schluessel ohne langlebige Geheimnisse

Maschinenidentitaeten sind meist der Ort, an dem gehaerteter menschlicher Zugriff wieder hereinleckt. Verbiete statische Schluessel in CI. Stelle stattdessen kurze Zertifikate ueber GitHub Actions oder GitLab OIDC gegen deinen Vault aus, sodass eine Pipeline ein nur minutenlang gueltiges Zertifikat erhaelt, das auf genau den Ziel-Host beschraenkt ist. Damit verschwindet die ganze Klasse von Vorfaellen, in denen ein im Build-Log geleakter Schluessel jahrelang gueltig bleibt. Fuer Deploy-Ziele nutze Match-Bloecke, die ein Service-Zertifikat mit ForceCommand und PermitOpen an einen einzigen Befehl binden und aus einer allgemeinen Shell eine schmale, auditierbare Aktion machen, die nicht in interaktiven Zugriff umgewidmet werden kann.

Zentrales Logging und Detektionen, die wirklich ausloesen

Logging schliesst den Kreis. Setze LogLevel VERBOSE im sshd, damit Schluessel-Fingerprints aufgezeichnet werden, sende /var/log/auth.log per journald-remote oder Fluent Bit nach Elastic oder Loki und schreibe Sigma-Regeln fuer die relevanten Muster: wiederholte Fehlversuche gefolgt von einem Erfolg aus derselben Quelle, Login mit einem in unter einer Stunde ablaufenden Zertifikat, ein Zertifikats-Principal, der nicht zum SSO-Benutzer passt, oder verdaechtige Befehle aus dem Session-Recording. In einer Red-Team-Simulation dauerte es 11 Minuten, bis wir beim Wiederverwenden eines gestohlenen Schluessels erwischt wurden, gerade weil der Zertifikats-Principal nicht zur SSO-Identitaet passte und die Korrelationsregel alarmierte. Ohne diese Korrelation waeren es Tage gewesen. SSH ist eine der reichsten und am wenigsten genutzten Telemetriequellen, die du besitzt. Achte besonders auf die Zuordnung von Verbindung zu Identitaet: mit Zertifikaten steht der Principal im Log, sodass du eine Session ohne Umweg einem SSO-Benutzer zuordnen kannst, waehrend rohe Schluessel-Fingerprints eine separate Zuordnungstabelle erfordern, die im Ernstfall veraltet ist. Ergaenze die Detektion um Geschwindigkeits- und Geolokations-Anomalien (unmoegliches Reisen zwischen zwei Logins) und um neue Quell-ASNs, die vorher nie SSH sprachen, denn diese schwachen Signale fangen genau die Faelle, in denen ein gueltiges Zertifikat auf einer fremden Maschine landet.

Haeufige Fallstricke, die dein Hardening leise aufheben

Die wiederkehrenden Fehler: PermitRootLogin prohibit-password stehen lassen und es fuer erledigt halten, waehrend ein geteilter Root-Schluessel weiter existiert; den Daemon haerten, aber ~/.ssh/authorized_keys fuer den Benutzer schreibbar lassen, sodass jede Codeausfuehrung einen Schluessel wieder hinzufuegt; vergessen, dass Match-Bloecke von oben nach unten ausgewertet werden und ein breiter frueher Match einen strengen spaeteren verdeckt; und Host-Schluessel rotieren, ohne die Verteilung der known_hosts zu aktualisieren, was Benutzern beibringt, Host-Key-Warnungen wegzuklicken. Ein weiterer stiller Killer ist ein unbegrenztes MaxStartups, das eine Verbindungsflut den Daemon erschoepfen laesst. Pruefe das explizit; nichts davon erscheint als Fehler, es laesst nur die Tuer angelehnt.

Hardening-Checkliste

Bevor du einen Host als gehaertet bezeichnest, verifiziere: ssh-audit-Note A; Passwort- und Keyboard-Interactive-Auth deaktiviert; Root-Login aus; nur moderne KEX, Cipher und MAC; CA-ausgestellte Zertifikate mit TTL unter 12 Stunden; TrustedUserCAKeys gesetzt und keine verirrten authorized_keys; Bastion-only-Ingress auf Netzwerkebene erzwungen; Session-Recording an; VERBOSE-Logs versendet und mindestens drei Sigma-Regeln aktiv; hardwaregestuetzte Client-Schluessel; keine statischen Schluessel in CI; und ein Notfall-Runbook, das die gesamte Flotte in unter einer Stunde widerrufen und neu ausstellen kann. Ist eine Zeile ungeprueft, ist der Host nicht fertig.

FAQ: Ist zertifikatsbasiertes SSH fuer ein kleines Team uebertrieben?

Nein. Selbst bei fuenf Ingenieuren beseitigt eine interne CA das schlimmste Betriebsrisiko, verwaiste Schluessel, und ist mit step-ca in einem Nachmittag aufgesetzt. Der Break-even ist nicht die Flottengroesse, sondern der Moment, in dem eine zweite Person Zugriff auf einen zweiten Host braucht, denn dann beginnt die manuelle authorized_keys-Verwaltung zu driften. Beginne mit einer 8-Stunden-TTL, gebunden an deinen Identity-Provider, und wachse von dort.

FAQ: Bricht das Aktivieren von sntrup761 aeltere Clients?

Clients mit OpenSSH aelter als 9.0 handeln das Hybrid-KEX nicht aus und fallen schlicht auf curve25519-sha256 zurueck, weshalb du es in der Liste behaeltst. Die praktische Antwort ist, Clients zu aktualisieren: jede Workstation mit einem OpenSSH vor 9.0 ist ohnehin ueberfaellig fuer Patches. Halte das post-quantum-KEX in der Praeferenz vorne, damit moderne Clients es automatisch bekommen.

Praktisches Take-away: baue ein Labor mit drei VMs (CA, Bastion, Ziel) mit step-ca, setze eine TTL von 8 Stunden, erzwinge die modernen Algorithmen, fahre ssh-audit bis A und versuche dann, dich mit einem alten Schluessel anzumelden. Klappt es, ist deine Konfiguration noch nicht gehaertet. Wiederhole das quartalsweise, rotiere den CA-Schluessel jaehrlich und halte das Notfall-Runbook getestet. SSH bleibt 2026 die Lieblings-Tuer der Angreifer, gerade weil wir es wie unsichtbare Infrastruktur behandeln. Hoer damit auf.