SSH-Hardening und Key-Management: Bastion-Hosts, Certificate Authorities und Key-Rotation

In vielen Umgebungen ist SSH noch immer der wichtigste Betriebszugang für Linux-Server, virtuelle Hosts, Netzwerkgateways und auch für Docker-Hosts. Genau deshalb ist SSH-Hardening keine „einmal einstellen und vergessen“-Aufgabe, sondern ein Zusammenspiel aus Protokollhärtung, Zugriffspfaden, Identitäten (Keys/Zertifikate) und einem belastbaren Lebenszyklus für Schlüsselmaterial. Wer nur einzelne Stellschrauben dreht (z. B. „Root-Login aus“), aber Key-Wildwuchs, fehlende Rotation oder unkontrollierte Sprungwege toleriert, verschiebt Risiken lediglich.

Dieser Beitrag zeigt eine praxistaugliche Zielarchitektur mit Bastion-Host (Jump Host als zentraler Einstiegspunkt), SSH Certificate Authority (CA zur Signierung kurzlebiger SSH-Zertifikate) und Key-Rotation als geplanter Betriebsprozess. Der Fokus liegt auf Betrieb, Administration, Auditierbarkeit, Troubleshooting, typischen Stolperfallen und einer Rückfallstrategie, die Sie nicht erst im Incident improvisieren müssen.

Warum SSH-Hardening ohne Key-Management oft scheitert

SSH selbst ist kryptografisch robust, aber die Praxis scheitert meist an drei Stellen:

• Identitätschaos: langlebige persönliche Keys ohne Ablauf, vielfach kopiert, ohne zentralen Überblick.
• Unkontrollierte Pfade: direkte Zugriffe aus beliebigen Netzen auf produktive Systeme, oft zusätzlich über VPN-Ausnahmen oder temporäre Firewall-Öffnungen.
• Schwache Betriebsdisziplin: keine Rotation, keine Entzugsmöglichkeit innerhalb von Minuten, keine nachvollziehbaren Änderungen an authorized_keys.

Die Folge sind schleichende Privilegienausweitung, schwierige Offboarding-Prozesse, hohe MTTR im Incident (weil unklar ist, welcher Key noch funktioniert) und Lücken in Compliance- und Audit-Anforderungen.

Zielbild: Bastion-Host, SSH-CA und kurzlebige Zugänge

Ein praxistaugliches Zielbild ist kein „Big Bang“, sondern lässt sich inkrementell einführen:

• Bastion-Host: Ein gehärteter, eng überwachter Einstiegspunkt, über den SSH-Verbindungen in interne Segmente laufen. Der Bastion-Host reduziert die Angriffsfläche, zentralisiert Logging und vereinfacht Netzwerkregeln.
• SSH-Zertifikate (OpenSSH Certificates): Statt öffentliche Keys auf jedem Zielsystem zu verteilen, werden kurzlebige Nutzerzertifikate durch eine SSH Certificate Authority signiert. Das Zielsystem vertraut der CA und entscheidet über Zugriffsrechte über Zertifikatsattribute und lokale Policies.
• Key-Rotation: Host-Keys, CA-Keys und (wo noch nötig) Nutzerkeys werden nach festen Regeln rotiert. Rotation ist dabei ein Betriebsprozess mit Messpunkten, nicht nur ein Kryptothema.

Wichtig: „Zero Trust“ wird oft als Buzzword verwendet; im SSH-Kontext bedeutet es konkret, dass Sie Identität, Kontext und Gültigkeit (kurze Laufzeiten) stärker gewichten als „wer im Netz ist, darf schon“.

Grundhärtung von OpenSSH: sshd_config, Kryptoparameter, Angriffsfläche

Die Basis bleibt die saubere Härtung des SSH-Daemons (sshd). Ziel ist: nur notwendige Funktionen, sichere Kryptoparameter, klare Authentifizierungswege.

Minimalprinzip für Authentifizierung und Features

Viele Risiken entstehen durch „kompatibel um jeden Preis“-Konfiguration. Typische Maßnahmen:

• Passwort-Login deaktivieren (wenn organisatorisch möglich) zugunsten von Keys oder Zertifikaten.
• Root-Login steuern (ideal: deaktivieren; alternativ: nur via Zertifikat und stark eingeschränkt).
• Port-Forwarding / Tunneling gezielt erlauben, statt global an.
• Login-Grants über Gruppen statt über einzelne Accounts.

# Beispiel: konservatives sshd Hardening (an Ihre Policies anpassen)
# Datei: /etc/ssh/sshd_config

Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Nur gezielt erlauben, wenn Sie es wirklich brauchen
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Exponierte Angriffsfläche reduzieren
MaxAuthTries 4
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Zugriff politisch steuern (Beispiel)
AllowGroups ssh-admins ssh-ops

# Logging: für Nachvollziehbarkeit (ohne Logflut)
LogLevel VERBOSE

Warum das funktioniert: Jeder deaktivierte Authentifizierungsweg ist ein Angriffsvektor weniger (Credential Stuffing, schwache Passwörter, Phishing). Reduzierte Forwarding-Optionen verhindern, dass SSH als „Universal-Tunnel“ für laterale Bewegung genutzt wird.

Wann es scheitert: Wenn Sie parallel alte Automatisierungen haben (z. B. Backups/Deployments), die noch Passwort-Login oder Port-Forwarding benötigen. Daher: vor dem Abschalten Abhängigkeiten erfassen und testweise auf Pilot-Hosts umstellen.

Host Keys: Fingerprints, Algorithmen, planbares Trust-On-First-Use ersetzen

Viele Teams leben mit „Trust On First Use“ (TOFU): Beim ersten SSH-Kontakt wird der Host-Key akzeptiert und dann gecacht. Das ist in großen Umgebungen riskant, weil ein Man-in-the-Middle beim Erstkontakt schwer zu entdecken ist. Besser: Host-Zertifikate über eine SSH-CA oder zumindest verwaltete known_hosts-Distribution.

Wenn Sie Host-Keys rotieren oder von RSA auf modernere Defaults umstellen, planen Sie die Kaskade: Monitoring/Automation, Bastion, Konfigurationsmanagement, Entwickler-Laptops und Break-Glass-Clients.

Bastion-Host (Jump Host): Architektur, Betrieb und typische Stolperfallen

Ein Bastion-Host ist ein dedizierter Server in einem streng kontrollierten Segment, der als einziger SSH-Einstieg in ein internes Netz dient. Er ersetzt nicht die Härtung der Zielsysteme, aber er bündelt Zugangskontrollen und Telemetrie.

Netzwerk- und Firewall-Prinzipien

• Inbound nur aus definierten Admin-Netzen (z. B. VPN, Privileged Access Segment) auf Port 22 (oder einen festen Alternativport, aber nicht als „Security by Obscurity“ verstehen).
• Outbound vom Bastion-Host nur zu den notwendigen Zielsubnetzen/Ports (meist 22). Kein „Bastion darf überall hin“.
• Keine direkte Erreichbarkeit produktiver Hosts aus dem Nutzer-/Office-Netz.

Stolperfalle: Wenn Sie Docker-Hosts betreiben, liegen diese oft in Netzen, die „irgendwie erreichbar“ sind, weil Build-/Registry-Zugriffe historisch gewachsen sind. Trennen Sie Management-Zugänge (SSH) strikt von Datenpfaden (Registry, APIs) und vermeiden Sie, dass ein kompromittierter Build-Runner direkt SSH in Produktion sprechen kann.

Session-Kontrolle und Nachvollziehbarkeit

Für Audits zählt nicht nur „wer durfte“, sondern auch „wer hat wann was gemacht“. Klassische Ansätze:

• SSH-LogLevel VERBOSE für nachvollziehbare Key-/Zertifikats-Infos.
• Zentrale Log-Ableitung (z. B. via journald/rsyslog) an ein SIEM oder Log-Backend.
• Session Recording (Tastatureingaben/Terminal-Ausgabe) nur, wenn rechtlich und organisatorisch sauber geklärt; technisch sinnvoll vor allem bei hochprivilegierten Zugängen.

Wichtig: Bastion-Logging ersetzt nicht die lokalen Logs auf Zielsystemen. Im Incident brauchen Sie beide Perspektiven (Ingress und Host-Ereignisse).

Prüfschritte: Bastion-Host im Alltag validieren

# 1) Auf dem Bastion: eingehende SSH-Verbindungen prüfen (Linux)
ss -tnp | grep ':22 '

# 2) Journald: Authentifizierungsereignisse
journalctl -u ssh -S -2h --no-pager

# 3) Fail2ban/Rate-Limits (falls eingesetzt)
sudo fail2ban-client status sshd 2>/dev/null || true

Wenn Sie hier schon „Rauschen“ sehen (viele Fehlschläge aus nicht erwarteten Netzen), ist das ein Signal: Inbound-Regeln und vorgelagerte Controls (VPN, MFA, Conditional Access) sind zu offen.

SSH Certificate Authority: Schlüssel verteilen war gestern

OpenSSH unterstützt SSH-Zertifikate: Ein Nutzer besitzt weiterhin ein Schlüsselpaar, aber statt den Public Key auf jedem Server in authorized_keys zu hinterlegen, wird ein Zertifikat ausgestellt. Dieses Zertifikat enthält u. a. Identität (Principals), Gültigkeit (NotBefore/NotAfter) und optional Einschränkungen. Der Server vertraut der CA über einen TrustedUserCAKeys-Eintrag.

Vorteile im Betrieb

• Kurzlebige Zugänge (z. B. 8–24 Stunden) reduzieren das Risiko gestohlener Keys erheblich.
• Offboarding wird sofortig: CA-Ausstellung stoppen, optional Zertifikate kurz halten. Kein „authorized_keys“ auf 200 Hosts anfassen.
• Zentrale Policy: Principals können Rollen abbilden (z. B. „ops“, „db-admin“), statt pro Host Listen zu pflegen.
• Auditierbarkeit: Zertifikatsseriennummern und Principals tauchen in Logs auf.

Grundkonfiguration auf Zielhosts

Auf den Zielsystemen definieren Sie Vertrauen in die User-CA und mappen Principals auf lokale Berechtigungen (typisch über Unix-Gruppen und sudo-Regeln). Beispielkonzept:

• CA-Public-Key liegt als Datei auf dem Host.
• TrustedUserCAKeys zeigt darauf.
• AuthorizedPrincipalsFile oder AuthorizedPrincipalsCommand legt fest, welche Principals für welchen Account akzeptiert werden.

# Datei: /etc/ssh/sshd_config.d/10-ca.conf (Beispielpfad, distroabhängig)

# Vertrauen in die User-CA
TrustedUserCAKeys /etc/ssh/trusted-user-ca.pub

# Principals pro Ziel-User definieren
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# Zertifikate erzwingen (optional, abhängig von Ihrer Übergangsphase)
AuthenticationMethods publickey

# Principals-Dateien anlegen (Beispiel)
sudo install -d -m 0755 /etc/ssh/auth_principals

echo 'ops' | sudo tee /etc/ssh/auth_principals/admin >/dev/null
echo 'breakglass' | sudo tee /etc/ssh/auth_principals/emergency >/dev/null

sudo chmod 0644 /etc/ssh/auth_principals/*

# sshd neu laden
sudo systemctl reload sshd

Warum das funktioniert: Der Host prüft nicht mehr „steht der Public Key in meiner Datei“, sondern „ist dieses Zertifikat von meiner CA signiert und ist der Principal für diesen Account erlaubt“. Die CA wird damit zur zentralen Vertrauenswurzel.

Wann es scheitert: Wenn Zeitdrift besteht. Zertifikate sind zeitgebunden; bei falscher Systemzeit werden sie „noch nicht gültig“ oder „abgelaufen“ sein. NTP/Chrony ist deshalb nicht optional. Prüfen Sie Zeitstabilität besonders nach VM-Snapshots/Restores.

CA-Schlüssel schützen: das ist Ihr „Master Key“

Die User-CA ist hochkritisch. Wer den CA-Private-Key besitzt, kann beliebige Zugänge signieren. Mindestanforderungen:

• Offline oder stark isoliert (idealerweise nicht auf dem Bastion-Host selbst).
• Signierung über einen kontrollierten Workflow (z. B. Ticket/Approval, kurze Laufzeiten, Protokollierung).
• Backup und Recovery mit klarer Zugriffskontrolle.

Viele Teams nutzen hier eine interne PKI- oder Secrets-Plattform. Entscheidend ist nicht das Tool, sondern dass Ausstellung, Laufzeit und Widerruf/Stop sauber operationalisiert sind.

Key-Rotation: Host-Keys, User-Keys, CA-Keys – und was dabei gerne bricht

Key-Rotation ist das geplante Ersetzen von Schlüsseln, bevor sie kompromittiert sind. Im SSH-Umfeld gibt es drei Klassen, die Sie getrennt betrachten sollten:

• Host Keys: Identität des Servers gegenüber Clients. Rotation betrifft known_hosts, Automatisierung und Monitoring.
• User Keys / Zertifikate: Identität der Nutzer/Automationen gegenüber Servern. Mit SSH-Zertifikaten rotieren Sie vor allem die CA-Policy und die Nutzer-Schlüsselbasis seltener.
• CA Keys: Vertrauenswurzel. Rotation ist möglich, aber muss als Migrationsfenster geplant werden (mehrere CAs parallel vertrauen).

Rotation ohne Downtime: Parallelvertrauen und Migrationsfenster

Eine praxistaugliche Vorgehensweise ist „parallel erlauben, dann abschalten“:

• Neue CA einführen und auf Zielhosts zusätzlich vertrauen (TrustedUserCAKeys kann mehrere Keys enthalten, entweder in einer Datei oder über mehrere Dateien, je nach Aufbau).
• Clients erhalten neue Zertifikate von der neuen CA.
• Nach Ablauf der alten Zertifikate und definiertem Stichtag alte CA-Vertrauensstellung entfernen.

Für Host-Keys gilt ähnliches Prinzip über verwaltete known_hosts bzw. Host-Zertifikate.

Typische Stolperfallen bei Rotation

• Vergessene Automationen: CI-Runner, Backup-Server, Monitoring-Checks, Konfigurationsmanagement. Diese nutzen oft eigene Keys.
• Embedded Clients: Appliances oder alte Images mit hart verdrahteten known_hosts-Einträgen.
• „Einmal akzeptiert“: Admin-Workstations, auf denen Host-Key-Warnungen weggeklickt wurden. Das rächt sich bei echter Rotation.
• Zeitdrift (bei Zertifikaten) und DNS-/IP-Inkonsistenzen (Host-Key-Mismatch).

Umsetzung in Etappen: von Quick Wins zur sauberen Zielarchitektur

Wenn Sie heute ein heterogenes Feld haben (klassische Server, VMs, Docker-Hosts, eventuell Kubernetes-Nodes), ist ein Etappenplan realistischer als eine Komplettumstellung.

Etappe 1: Sichtbarkeit und Hygiene

• Inventarisieren: Wo ist Port 22 offen? Welche Systeme sind direkt erreichbar?
• Schlüsselhygiene: Welche authorized_keys liegen wo? Wer besitzt sie? Gibt es Shared Keys?
• Logging zentralisieren: Mindestens Bastion + kritische Serverklassen an ein Log-Backend.

# Grober Check: Welche Accounts haben authorized_keys?
sudo find /home /root -maxdepth 2 -type f -name authorized_keys -print

# Inhalte prüfen (Vorsicht: sensible Daten)
# Tipp: nur Fingerprints der Public Keys extrahieren
sudo awk '{print $1" "$2}' /home/*/.ssh/authorized_keys 2>/dev/null | sort -u | head

Etappe 2: Bastion-Host erzwingen

Technisch erzwingen Sie das über Netzwerkregeln (Security Groups/Firewall) und über SSH-Server-Policies auf Zielhosts (nur Bastion-IP darf Port 22 erreichen). Organisatorisch müssen Admin-Tools/Runbooks angepasst werden (ProxyJump, ProxyCommand).

# Beispiel: Client-Konfiguration ~/.ssh/config
Host bastion
  HostName bastion.example.net
  User admin

Host internal-*
  User admin
  ProxyJump bastion
  ServerAliveInterval 60

Stolperfalle: Wenn Sie Bastion als Single Point of Failure betreiben, tauschen Sie ein Risiko gegen ein anderes. Planen Sie mindestens Redundanz (z. B. zwei Bastions, getrennte Failure Domains) und einen dokumentierten Break-Glass-Weg.

Etappe 3: SSH-CA für Nutzerzugänge einführen

Starten Sie mit einem Pilot-Segment. Setzen Sie kurze Laufzeiten (z. B. ein Arbeitstag) und definieren Sie Principals so, dass sie zu Ihren Rollen passen. Bauen Sie parallel eine Entzugsmöglichkeit auf: Wenn Sie Ausstellung stoppen können, ist der maximale Schaden durch ein kompromittiertes Zertifikat auf die Laufzeit begrenzt.

Etappe 4: Automationen sauber abbilden (nicht „Admin-Key für alles“)

Automationen brauchen eigene Identitäten. Trennen Sie:

• Human Admin Access (interaktiv, kurzlebig, nachvollziehbar)
• Machine Access (nicht interaktiv, streng begrenzt, idealerweise ebenfalls per Zertifikatslogik oder klar isolierten Deploy-Keys)

Wenn Sie Docker-Hosts per SSH administrieren (z. B. für Notfälle), definieren Sie dafür eigene Principals/Accounts und vermeiden Sie, dass CI-Systeme denselben Pfad nutzen.

Troubleshooting: Wenn SSH-Zertifikate oder Bastion-Verbindungen nicht funktionieren

In der Praxis brauchen Sie schnelle Prüfschritte, die ohne Spezialwissen funktionieren.

1) Zertifikat ist abgelaufen oder „noch nicht gültig“

Symptom: Login schlägt trotz korrekter Konfiguration fehl. Ursache ist oft Zeitdrift. Prüfen:

# Auf Client und Zielhost: Zeit prüfen
date -u

# NTP/Chrony Status (Beispiel, distroabhängig)
chronyc tracking 2>/dev/null || true
timedatectl status

Wenn die Zeit nicht stimmt: erst Zeitproblem lösen, dann erneut testen. Zertifikatsauthentifizierung ist hier gnadenlos korrekt.

2) Server vertraut der falschen CA (oder keiner)

Prüfen, ob der CA-Public-Key korrekt und geladen ist:

sudo sshd -T | grep -i 'trustedusercakeys|authorizedprincipals'

# Datei vorhanden?
sudo ls -l /etc/ssh/trusted-user-ca.pub

Stolperfalle: Konfigurationssplit über sshd_config.d und die Reihenfolge. Validieren Sie immer mit sshd -T, weil das die effektive Konfiguration zeigt.

3) Bastion-Proxy bricht ab (Netz/Firewall)

Wenn ProxyJump hängt oder abbricht, ist es häufig kein SSH-Problem, sondern ein Routing-/Firewall-Thema. Prüfen Sie vom Bastion aus den Zielport:

# Auf dem Bastion-Host: Zielhost erreichbar?
TARGET=internal-host-01
nc -vz $TARGET 22

# Alternativ mit bash TCP (ohne nc)
timeout 3 bash -c "</dev/tcp/$TARGET/22" && echo OK || echo FAIL

Wenn das scheitert, helfen SSH-Logs auf dem Client wenig. Dann sind Netzwerkpfad und Security Groups die richtige Ebene.

Checkliste: SSH-Hardening in Unternehmensumgebungen (betrieblich gedacht)

• Netzwerk: Port 22 nur aus Admin-Segment/Bastion erreichbar, keine direkten Ausnahmen „temporär“ ohne Ablauf.
• Auth: Passwortlogin deaktiviert oder stark begrenzt; klare Gruppensteuerung (AllowGroups).
• Bastion: gehärtet, minimaler Softwarestand, restriktives Outbound, zentrale Logs, definierter Break-Glass-Prozess.
• Zertifikate: SSH-CA eingeführt, kurze Laufzeiten, Principals rollenbasiert, Zeit/NTP stabil.
• Rotation: Host-Keys/CA-Keys/User-Keys mit Plan, Parallelvertrauen im Migrationsfenster, Automationen inventarisiert.
• Audit: LogLevel, zentrale Log-Korrelation, Nachvollziehbarkeit von Admin-Zugriffen.

Rückfallstrategie: Was tun, wenn die neue Authentifizierung blockiert?

Jede Härtung kann bei einem Fehler zu einem „Self-Inflicted Outage“ führen. Planen Sie daher explizit eine Rückfallstrategie:

• Out-of-Band Zugriff: Konsole/iDRAC/IPMI/Cloud-Serial-Console – aber abgesichert und getestet.
• Break-Glass Account: dedizierter Account mit streng kontrolliertem Zugang, idealerweise nur über Bastion und zeitlich begrenzt aktiv.
• Staged Rollout: erst Pilot, dann Wellen. Nie die gesamte Flotte gleichzeitig umstellen.
• Konfigurationswechsel atomar: Änderungen so ausrollen, dass ein Reload möglich ist (und kein erzwungener Restart mitten im Fehler).

Praktisch bewährt: Vor jeder Änderung an sshd_config eine zweite, bereits offene Session behalten, syntaktisch prüfen (sshd -t) und dann erst reloaden.

# Sichere Prüfsequenz vor dem Reload
sudo sshd -t && echo "Config OK" || echo "Config ERROR"

# Erst wenn OK:
sudo systemctl reload sshd

Fazit: SSH-Hardening wird mit CA und Rotation wirklich beherrschbar

SSH-Hardening ist am wirksamsten, wenn Sie nicht nur „sshd härten“, sondern den gesamten Zugriffspfad operationalisieren: Bastion-Hosts reduzieren Angriffsflächen und bündeln Telemetrie; eine SSH Certificate Authority macht Identitäten steuerbar und kurzlebig; Key-Rotation wird von einer lästigen Ausnahme zu einem geplanten Prozess. Entscheidend ist, dass Sie Zeitstabilität (NTP), Abhängigkeiten (Automationen) und eine getestete Rückfallstrategie von Anfang an mitdenken. Dann wird SSH nicht nur sicherer, sondern im Alltag auch besser administrierbar.

Für dieses Thema sind auch Ssh Key Management und Ssh Zertifikate wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.