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 immer noch ssh-rsa mit SHA-1, im Internet exponierte Passwort-Authentifizierung und MACs wie hmac-sha1 akzeptieren. 2026 ist das keine vergessene Legacy-Konfiguration mehr: es ist 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 CA, auditierbarem Bastion, Schluesselrotation und zentralisierter Telemetrie. Dieser Beitrag zeigt, wie das Basilisk-Team diesen Stack im Labor aufbaut, bevor er in die Produktion geht, mit konkreten Zahlen und Werkzeugen, die du heute testen kannst.

Beginne mit den Grundlagen, aber richtig. In einer modernen /etc/ssh/sshd_config erzwinge PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no und UsePAM yes. Bei Algorithmen 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. sntrup761 liefert seit OpenSSH 9.0 hybride post-quantenkryptografische Resistenz, und 2026 gibt es keinen Grund mehr, das nicht zu aktivieren. Fuehre ssh-audit vorher und nachher aus: der Unterschied zwischen C+ und A liegt im Wesentlichen darin, diffie-hellman-group14-sha1 und Konsorten abzuschalten. Das ist eine Vorbedingung, kein Lieferergebnis. Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen

Der wirkliche Reifesprung kommt, wenn du verstreute authorized_keys durch eine interne SSH-CA ersetzt. Du erzeugst ein CA-Schluesselpaar (ed25519, passphraselos nur in einem HSM oder Offline-Host), signierst Benutzerzertifikate mit kurzer TTL (4 bis 12 Stunden) und verteilst nur den oeffentlichen CA-Schluessel ueber TrustedUserCAKeys auf den Servern. Der Benutzer authentifiziert sich mit einem von step-ca, Vault SSH oder Teleport ausgestellten Zertifikat, gebunden an das Firmen-SSO. Ergebnis: das Entziehen von Zugriff fuer einen ehemaligen Mitarbeiter ist keine Jagd nach authorized_keys auf 400 Hosts mehr, sondern schlicht das Nicht-Erneuern des Zertifikats. Bei internen Pentests bricht allein diese Aenderung die Haelfte der lateral-movement-Pfade ueber verwaiste Schluessel. Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab Lateral Movement im Lab: SMB, WMI und WinRM mit Detection-Fokus

Der Bastion-Host darf kein beliebiger Linux mit offenem SSH sein. 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, Boundary und die Kombination step-ca + auditd + tlog decken das ab. In einer typischen Konfiguration fuer einen Fintech-Kunden 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 IPs auf einen einzigen ueberwachten Punkt. Pivoting mit Chisel und Ligolo-ng: Segmentierte Netze im Pentest-Lab

Zentrales Logging schliesst den Kreis. Aktiviere LogLevel VERBOSE im sshd, sende /var/log/auth.log per journald-remote oder Fluent Bit nach Elastic oder Loki und schreibe Sigma-Regeln fuer Muster wie wiederholte Fehlversuche gefolgt von Erfolg, Login mit in weniger als einer Stunde ablaufendem Zertifikat oder verdaechtige Befehle via Session-Recording. In einer Red-Team-Simulation brauchten wir 11 Minuten, bis wir beim Wiederverwenden eines gestohlenen Schluessels erwischt wurden, weil der Zertifikats-Principal nicht zum SSO-Benutzer passte. Ohne diese Korrelation waeren es Tage gewesen. Wer Detektionen schreibt, weiss: SSH ist eine der reichsten und am wenigsten genutzten Quellen. Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel Hunting von Living-off-the-Land-Binaries unter Windows mit KQL

Vergiss die Client-Seite nicht. Erzwinge ~/.ssh/config mit HashKnownHosts yes, VerifyHostKeyDNS yes wo anwendbar, und nutze ssh-agent mit Touch-Bestaetigung auf einem YubiKey (sk-ed25519). Fuer Service-Schluessel in Pipelines keine statischen Schluessel im CI: gib kurze Zertifikate ueber GitHub Actions oder GitLab OIDC gegen deinen Vault aus. Damit verschwindet eine ganze Klasse von Vorfaellen, in denen ein in Logs geleakter Schluessel jahrelang gueltig bleibt. Parallel dazu pruefe Optionen: AllowAgentForwarding und StreamLocalBindUnlink koennen fast immer abgeschaltet werden. Supply Chain Security: Sigstore-Signatur und echte SBOMs in CI/CD Passwoerter und MFA: Umstieg auf Passkeys ohne Recovery zu zerstoeren

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