SSH-Sicherheit und Authentifizierung 19 Min. Lesezeit

SSH-Härtung 2026: Post-Quanten-Kryptografie, FIDO2-Keys und Zertifikate in OpenSSH 10.x

Praxisleitfaden zur SSH-Absicherung mit OpenSSH 10.x: Post-Quanten-Schlüsselaustausch (ML-KEM), FIDO2-Hardware-Schlüssel, zertifikatsbasierte Authentifizierung, Bastion-Host-Architektur und automatisierte Sicherheitsaudits konfigurieren.

Editorial Team

Einleitung: Warum SSH-Sicherheit 2026 eine völlig neue Dimension erreicht

SSH ist das Rückgrat jeder Linux-Administration — das ist keine Übertreibung. Ob Servereinrichtung, Deployment-Pipeline oder der panische Notfall-Zugriff um 3 Uhr morgens: Fast alles läuft über Secure Shell. Und genau deshalb ist SSH auch das Ziel Nummer eins für Angreifer.

Die Zahlen aus dem vierten Quartal 2025 sprechen eine deutliche Sprache: Der Wurm P2PInfect war für satte 80,4 Prozent aller SSH-Malware-Infektionen verantwortlich, und Brute-Force-Angriffe machten 89 Prozent aller Endpoint-Aktivitäten auf öffentlich erreichbaren Linux-Systemen aus. Wer seinen SSH-Zugang nicht konsequent absichert, spielt schlicht mit dem Feuer.

Gleichzeitig hat sich auf der Verteidigungsseite enorm viel getan. OpenSSH 10.0 (April 2025) und OpenSSH 10.1 (Oktober 2025) bringen fundamentale Änderungen mit: Post-Quanten-Kryptografie ist standardmäßig aktiviert, der veraltete DSA-Algorithmus wurde komplett entfernt, und eine neue Binär-Aufteilung (sshd-auth) reduziert die Angriffsfläche vor der Authentifizierung drastisch. Dazu kommt die zunehmende Verbreitung von FIDO2-Hardware-Schlüsseln und SSH-Zertifikaten als Ersatz für klassische Public-Key-Authentifizierung.

In diesem Leitfaden gehen wir systematisch durch alle Ebenen der SSH-Absicherung — von der Grundkonfiguration über Post-Quanten-Schlüsselaustausch und FIDO2-gestützte Authentifizierung bis hin zu zertifikatsbasiertem Zugang und fortgeschrittener Verteidigung mit Bastion-Hosts. Jeder Abschnitt enthält sofort einsetzbare Konfigurationen und Befehle für aktuelle Linux-Distributionen. Also, legen wir los.

OpenSSH 10.x: Architektur und Sicherheitsneuerungen

Die neue Binär-Aufteilung mit sshd-auth

Eine der wichtigsten Änderungen in OpenSSH 10.0 ist die Auslagerung des Authentifizierungscodes in eine eigenständige Binärdatei namens sshd-auth. Bisher war der gesamte Authentifizierungscode Teil des sshd-session-Prozesses — das bedeutete, dass ein Angreifer, der eine Schwachstelle in der Pre-Authentifizierungsphase ausnutzen konnte, potenziell Zugriff auf den gesamten Adressraum des SSH-Daemons hatte. Nicht ideal, gelinde gesagt.

Durch die Auslagerung in sshd-auth läuft die Pre-Authentifizierungs-Phase jetzt in einem komplett separaten Adressraum. Sobald die Authentifizierung abgeschlossen ist, wird der sshd-auth-Prozess beendet und sein Speicher freigegeben. Das bringt zwei Vorteile gleichzeitig: eine drastisch reduzierte Angriffsfläche und eine spürbare Einsparung an Arbeitsspeicher pro Verbindung.

# Prüfen, welche sshd-Binärdateien installiert sind
ls -la /usr/sbin/sshd /usr/lib/openssh/sshd-auth /usr/lib/openssh/sshd-session 2>/dev/null

# Alternativ für verschiedene Distributionen:
find / -name "sshd-auth" -o -name "sshd-session" 2>/dev/null

# OpenSSH-Version anzeigen
ssh -V
# Erwartete Ausgabe: OpenSSH_10.1p1, OpenSSL 3.x.x ...

DSA ist Geschichte — und das ist gut so

OpenSSH 10.0 entfernt die Unterstützung für den DSA-Signaturalgorithmus vollständig. Ehrlich gesagt, wurde das höchste Zeit. DSA war bereits seit Jahren als veraltet markiert und nutzte standardmäßig nur 1024-Bit-Schlüssel — für heutige Verhältnisse absolut unzureichend. Wenn Sie noch DSA-Schlüssel in Ihren authorized_keys-Dateien haben, ist jetzt der Zeitpunkt zum Aufräumen:

# Alle DSA-Schlüssel in authorized_keys finden
grep "ssh-dss" ~/.ssh/authorized_keys

# Systemweit nach DSA-Schlüsseln suchen
find /home -name "authorized_keys" -exec grep -l "ssh-dss" {} \;
find /home -name "id_dsa*" 2>/dev/null

# Alte DSA-Schlüssel durch Ed25519 ersetzen
ssh-keygen -t ed25519 -C "admin@server01 - $(date +%Y-%m)"

SHA-1-Deprecation und Finite-Field-DH

OpenSSH 10.1 kennzeichnet SHA-1-basierte SSHFP-Records als veraltet. Der Befehl ssh-keygen -r erzeugt standardmäßig nur noch SHA-256-Fingerprints. Außerdem ist der Finite-Field-Diffie-Hellman-Schlüsselaustausch auf der Serverseite standardmäßig deaktiviert — ein konsequenter Schritt weg von klassischen, potenziell quantenanfälligen Algorithmen.

Was heißt das konkret? Wenn Sie DNS-basierte Host-Verifizierung über SSHFP-Records nutzen, müssen Sie sicherstellen, dass Ihre DNS-Zone SHA-256-Fingerprints enthält. Ältere SHA-1-basierte Records werden in einer zukünftigen OpenSSH-Version schlicht ignoriert:

# SSHFP-Records generieren (nur noch SHA-256)
ssh-keygen -r server01.example.com -f /etc/ssh/ssh_host_ed25519_key.pub

# Ausgabe zum Einfügen in die DNS-Zone:
# server01.example.com IN SSHFP 4 2 abc123...

# Bestehende SSHFP-Records prüfen
dig SSHFP server01.example.com

# SSH-Verifizierung über DNS aktivieren
# ~/.ssh/config
Host *.example.com
    VerifyHostKeyDNS yes

Upgrade-Planung: Migration auf OpenSSH 10.x

Ein Upgrade auf OpenSSH 10.x erfordert sorgfältige Planung, da es einige rückwärts-inkompatible Änderungen gibt. Hier eine Checkliste für die Migration:

  • DSA-Schlüssel identifizieren und ersetzen — Da DSA-Unterstützung entfernt wurde, müssen alle DSA-Schlüssel vor dem Upgrade durch Ed25519 oder RSA (mindestens 3072 Bit) ersetzt werden.
  • Kompatibilität prüfen — Ältere SSH-Clients, die nur klassischen Diffie-Hellman unterstützen, können sich möglicherweise nicht mehr verbinden. Testen Sie alle Client-Systeme vor dem Upgrade.
  • Konfigurationsdateien bereinigen — Entfernen Sie veraltete Direktiven wie DSAAuthentication oder explizite DSA-Algorithmen aus PubkeyAcceptedKeyTypes.
  • Firewall-Regeln prüfen — Die neuen Post-Quanten-Pakete sind etwas größer als klassische Schlüsselaustauschnachrichten. Stellen Sie sicher, dass Ihre Paketgrößen-Limits das nicht blockieren.

Post-Quanten-Kryptografie in OpenSSH konfigurieren

Warum Post-Quanten-Kryptografie jetzt relevant ist

Quantencomputer, die RSA oder elliptische Kurven brechen können, existieren heute noch nicht in praxisrelevanter Größe. Aber — und das ist der entscheidende Punkt — das Bedrohungsszenario „Jetzt aufzeichnen, später entschlüsseln" ist absolut real. Geheimdienste und fortgeschrittene Angreifer können heute verschlüsselten SSH-Verkehr mitschneiden und ihn zu einem späteren Zeitpunkt entschlüsseln, wenn leistungsfähige Quantencomputer verfügbar werden.

Genau deshalb ist es wichtig, jetzt auf quantenresistente Algorithmen umzustellen. Nicht morgen, nicht nächstes Quartal.

ML-KEM und der hybride Schlüsselaustausch

OpenSSH setzt auf einen hybriden Ansatz, und das ist meiner Meinung nach genau die richtige Strategie. Der Algorithmus mlkem768x25519-sha256 kombiniert den NIST-standardisierten Post-Quanten-Algorithmus ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) mit dem bewährten klassischen X25519. Damit bekommt man das Beste aus beiden Welten:

  • Quantenresistenz durch ML-KEM: Selbst ein leistungsfähiger Quantencomputer könnte den ML-KEM-Anteil des Schlüsselaustauschs nicht brechen.
  • Bewährte Sicherheit durch X25519: Falls sich in ML-KEM eine bisher unbekannte Schwachstelle finden sollte, bietet X25519 weiterhin klassische Sicherheit.
  • Kein Entweder-Oder: Der hybride Ansatz stellt sicher, dass die Verbindung mindestens so sicher ist wie die stärkere der beiden Komponenten.

Konfiguration auf dem Server

Ab OpenSSH 10.0 ist mlkem768x25519-sha256 bereits der Standard-Schlüsselaustauschalgorithmus. Für ältere Server oder wenn Sie die Konfiguration explizit festlegen möchten:

# /etc/ssh/sshd_config.d/pq-kex.conf

# Post-Quanten-Schlüsselaustausch priorisieren
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]

# Starke Host-Key-Algorithmen
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Starke MACs
MACs [email protected],[email protected]

# Starke Ciphers
Ciphers [email protected],[email protected],[email protected]

Konfiguration auf dem Client

# ~/.ssh/config oder /etc/ssh/ssh_config.d/pq-kex.conf

Host *
    # Post-Quanten-Schlüsselaustausch bevorzugen
    KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256

    # Starke Ciphers
    Ciphers [email protected],[email protected]

    # Starke MACs
    MACs [email protected],[email protected]

    # Warnung bei schwacher Kryptografie aktivieren (OpenSSH 10.1+)
    # WarnWeakCrypto yes

Quantensicherheit einer Verbindung überprüfen

OpenSSH 10.1 warnt standardmäßig, wenn eine Verbindung keinen quantenresistenten Schlüsselaustausch verwendet. Sie können den tatsächlich verwendeten Algorithmus aber auch manuell prüfen:

# Verbose-Modus zeigt den ausgehandelten Schlüsselaustauschalgorithmus
ssh -vvv user@server 2>&1 | grep "kex:"

# Erwartete Ausgabe bei PQ-Schlüsselaustausch:
# debug1: kex: algorithm: mlkem768x25519-sha256

# Alle unterstützten Algorithmen des Servers abfragen
ssh -Q kex

# Testverbindung mit erzwungenem PQ-Algorithmus
ssh -oKexAlgorithms=mlkem768x25519-sha256 user@server

Grundhärtung der SSH-Konfiguration

Die wichtigsten sshd_config-Einstellungen

Bevor wir uns den fortgeschrittenen Themen widmen, hier die fundamentale Härtung, die auf jedem System konfiguriert sein sollte. Das ist quasi das Pflichtprogramm:

# /etc/ssh/sshd_config.d/hardening.conf

# Root-Login komplett deaktivieren
PermitRootLogin no

# Passwort-Authentifizierung deaktivieren (nur Schlüssel oder Zertifikate)
PasswordAuthentication no
KbdInteractiveAuthentication no

# Leere Passwörter verbieten
PermitEmptyPasswords no

# Maximale Authentifizierungsversuche begrenzen
MaxAuthTries 3

# Login-Zeitfenster verkürzen (Standard: 120 Sekunden)
LoginGraceTime 30

# Maximale gleichzeitige unauthentifizierte Verbindungen
MaxStartups 10:30:60

# X11-Forwarding deaktivieren (wenn nicht benötigt)
X11Forwarding no

# Agent-Forwarding deaktivieren (wenn nicht benötigt)
AllowAgentForwarding no

# TCP-Forwarding einschränken
AllowTcpForwarding no

# Nur bestimmte Benutzer oder Gruppen zulassen
AllowGroups ssh-users admins

# Strikte Berechtigungsprüfung
StrictModes yes

# Idle-Timeout konfigurieren (prüft alle 300 Sekunden, maximal 3 Fehlversuche)
ClientAliveInterval 300
ClientAliveCountMax 3

# Logging auf VERBOSE setzen für bessere Auditierbarkeit
LogLevel VERBOSE

# Banner anzeigen (rechtlicher Hinweis)
Banner /etc/ssh/banner.txt

SSH-Port und Zugriffskontrolle

Das Ändern des SSH-Ports ist kein echtes Sicherheitsmerkmal — das muss man klar sagen. Es reduziert aber das Grundrauschen durch automatisierte Scans erheblich, und weniger Rauschen bedeutet bessere Lesbarkeit der Logs:

# Port ändern (optional, reduziert automatisierte Angriffe)
Port 2222

# Nur bestimmte Netzwerk-Interfaces abhören
ListenAddress 10.0.1.5
ListenAddress fd00::5

Deutlich wirksamer ist die Kombination mit einer Firewall:

# nftables-Regel: SSH nur von bestimmten IP-Bereichen zulassen
nft add rule inet filter input tcp dport 22 ip saddr { 10.0.0.0/8, 192.168.1.0/24 } accept
nft add rule inet filter input tcp dport 22 drop

# Rate-Limiting mit nftables
nft add rule inet filter input tcp dport 22 ct state new limit rate 5/minute accept
nft add rule inet filter input tcp dport 22 ct state new drop

Konfiguration validieren und neu laden

# Konfiguration auf Syntax-Fehler prüfen — IMMER vor dem Neustart tun!
sshd -t

# Erweiterte Prüfung mit Ausgabe der aktiven Konfiguration
sshd -T

# sshd neu laden (bestehende Verbindungen bleiben erhalten)
systemctl reload sshd

# WICHTIG: Bevor Sie PasswordAuthentication deaktivieren,
# stellen Sie sicher, dass der Key-basierte Login funktioniert!
# Testen Sie in einer separaten Session:
ssh -o PreferredAuthentications=publickey user@server

FIDO2-Hardware-Schlüssel für SSH einrichten

Warum FIDO2 der Gold-Standard ist

Klassische SSH-Schlüssel haben eine grundlegende Schwachstelle, die gerne übersehen wird: Wenn ein Angreifer Zugriff auf Ihre ~/.ssh/id_ed25519-Datei erlangt — sei es durch Malware, eine Backup-Kompromittierung oder einen kompromittierten Arbeitsplatz —, kann er sich als Sie authentifizieren. Eine Passphrase hilft zwar, kann aber durch Keylogger oder Memory-Dumps umgangen werden.

FIDO2-Hardware-Schlüssel wie YubiKey, SoloKeys oder Token2 lösen dieses Problem grundlegend: Der private Schlüssel verlässt niemals die Hardware. Jede Authentifizierung erfordert physischen Kontakt mit dem Schlüssel und optional eine PIN-Eingabe. Selbst wenn ein Angreifer Ihr gesamtes Dateisystem kopiert, ist der SSH-Schlüssel ohne den physischen Hardware-Schlüssel wertlos.

Der Unterschied lässt sich ganz einfach zusammenfassen: Bei einem konventionellen Ed25519-Schlüssel liegt der gesamte private Schlüssel als Datei auf der Festplatte — verschlüsselt mit einer Passphrase, aber dennoch kopierbar und offline angreifbar. Bei einem FIDO2-Schlüssel existiert auf der Festplatte lediglich ein „Key Handle", also ein Verweis, der ohne den physischen Hardware-Schlüssel nutzlos ist. Die eigentliche kryptografische Operation findet ausschließlich innerhalb des Secure Elements des FIDO2-Geräts statt.

FIDO2-Schlüssel generieren

# Ed25519-SK-Schlüssel erzeugen (FIDO2-Hardware-Key erforderlich)
# -O resident: Schlüssel wird auf dem Hardware-Key gespeichert
# -O verify-required: PIN muss bei jeder Nutzung eingegeben werden
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin@workstation - YubiKey 5"

# Der Befehl fordert zum Berühren des Hardware-Schlüssels auf:
# "Confirm user presence for key generation"
# -> Physisch den YubiKey berühren

# Alternativ: ECDSA-SK-Schlüssel (breitere Kompatibilität)
ssh-keygen -t ecdsa-sk -O resident -O verify-required -C "admin@workstation - Backup-Key"

# Vorhandene Resident-Keys vom Hardware-Key laden
ssh-keygen -K

# Dies erzeugt:
# id_ed25519_sk_rk     (privater Key-Handle)
# id_ed25519_sk_rk.pub (öffentlicher Schlüssel)

Server für FIDO2 konfigurieren

# /etc/ssh/sshd_config.d/fido2.conf

# FIDO2-Schlüsseltypen akzeptieren
PubkeyAcceptedKeyTypes [email protected],[email protected],ssh-ed25519,rsa-sha2-512

# PIN-Verifizierung vom Server erzwingen
PubkeyAuthOptions verify-required

# Passwort-Authentifizierung deaktivieren — nur FIDO2 und Zertifikate
PasswordAuthentication no
KbdInteractiveAuthentication no

Backup-Strategie für Hardware-Schlüssel

Was passiert, wenn Sie Ihren YubiKey verlieren? Diese Frage sollte vor dem Ausrollen von FIDO2 geklärt sein — nicht danach, wenn die Panik einsetzt:

  • Zwei Hardware-Schlüssel registrieren: Tragen Sie die öffentlichen Schlüssel beider Keys in die authorized_keys auf allen Zielsystemen ein. Bewahren Sie den Backup-Key sicher auf (Tresor oder gleichwertiger Schutz).
  • Break-Glass-Verfahren: Halten Sie für den Notfall einen konventionellen Ed25519-Schlüssel in einem verschlüsselten Offline-Medium bereit. Dieser sollte nur über einen separaten, besonders geschützten Zugang funktionieren.
  • SSH-Zertifikate als Alternative: In Kombination mit einer SSH-CA können verloren gegangene Schlüssel zentral widerrufen werden, ohne dass auf jedem einzelnen Server die authorized_keys geändert werden müssen.
# Beide Hardware-Schlüssel in authorized_keys eintragen
cat id_ed25519_sk_rk.pub >> ~/.ssh/authorized_keys    # Primärer YubiKey
cat id_ed25519_sk_backup.pub >> ~/.ssh/authorized_keys  # Backup YubiKey

# Break-Glass-Schlüssel erzeugen und sicher verwahren
ssh-keygen -t ed25519 -f /mnt/encrypted-usb/break-glass-key -C "BREAK GLASS - emergency only"

# Break-Glass-Schlüssel mit eingeschränktem Zugang konfigurieren
echo 'from="10.0.0.5",command="/usr/local/bin/emergency-shell" ssh-ed25519 AAAA...' >> ~/.ssh/authorized_keys

Zertifikatsbasierte SSH-Authentifizierung

Vorteile gegenüber klassischen SSH-Schlüsseln

Bei klassischer Public-Key-Authentifizierung muss der öffentliche Schlüssel jedes Benutzers auf jedem Server eingetragen werden. Bei zehn Servern und zwanzig Mitarbeitern sind das 200 Einträge — die alle gepflegt, rotiert und bei Bedarf widerrufen werden müssen.

Das skaliert nicht. Punkt.

SSH-Zertifikate lösen dieses Problem elegant:

  • Zentrale Ausstellung: Eine SSH Certificate Authority (CA) signiert die öffentlichen Schlüssel der Benutzer. Die Server vertrauen dem CA-Zertifikat, nicht den einzelnen Benutzerschlüsseln.
  • Automatischer Ablauf: Zertifikate haben eine eingebaute Gültigkeitsdauer. Abgelaufene Zertifikate werden automatisch ungültig — kein manuelles Aufräumen nötig.
  • Einschränkungen: Zertifikate können auf bestimmte Benutzernamen, Source-IPs, Befehle und Weiterleitungsrechte eingeschränkt werden.
  • Einfacher Widerruf: Kompromittierte Schlüssel können zentral über eine KRL (Key Revocation List) widerrufen werden.

SSH Certificate Authority einrichten

# 1. CA-Schlüssel generieren (gut geschützt aufbewahren!)
mkdir -p /etc/ssh/ca
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "SSH User CA - $(hostname)"
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "SSH Host CA - $(hostname)"

# 2. Berechtigungen setzen
chmod 600 /etc/ssh/ca/user_ca /etc/ssh/ca/host_ca
chmod 644 /etc/ssh/ca/user_ca.pub /etc/ssh/ca/host_ca.pub

# 3. Server konfigurieren, damit er der Benutzer-CA vertraut
# /etc/ssh/sshd_config.d/ca.conf
echo 'TrustedUserCAKeys /etc/ssh/ca/user_ca.pub' >> /etc/ssh/sshd_config.d/ca.conf

# 4. Host-Zertifikat erstellen und signieren
ssh-keygen -s /etc/ssh/ca/host_ca \
    -I "server01.example.com" \
    -h \
    -n "server01.example.com,server01,10.0.1.10" \
    -V "+52w" \
    /etc/ssh/ssh_host_ed25519_key.pub

# 5. Host-Zertifikat in sshd_config eintragen
echo 'HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub' >> /etc/ssh/sshd_config.d/ca.conf

Benutzer-Zertifikate ausstellen

# Zertifikat für einen Benutzer signieren
# -I: Identifikator (für Audit-Logs)
# -n: Erlaubte Benutzernamen auf dem Zielserver
# -V: Gültigkeitsdauer (hier: 8 Stunden)
# -O: Einschränkungen
ssh-keygen -s /etc/ssh/ca/user_ca \
    -I "mmueller-2026-02-09" \
    -n "mmueller,deploy" \
    -V "+8h" \
    -O "source-address=10.0.0.0/8" \
    -O "no-agent-forwarding" \
    -O "no-port-forwarding" \
    /home/mmueller/.ssh/id_ed25519.pub

# Das erzeugt: /home/mmueller/.ssh/id_ed25519-cert.pub

# Zertifikat-Inhalt prüfen
ssh-keygen -L -f /home/mmueller/.ssh/id_ed25519-cert.pub

# Beispiel-Ausgabe:
# Type: [email protected] user certificate
# Public key: ED25519-CERT SHA256:...
# Signing CA: ED25519 SHA256:...
# Key ID: "mmueller-2026-02-09"
# Valid: from 2026-02-09T10:00:00 to 2026-02-09T18:00:00
# Principals:
#     mmueller
#     deploy
# Critical Options:
#     source-address 10.0.0.0/8
# Extensions:
#     permit-pty

Kurzlebige Zertifikate automatisieren

Die wahre Stärke von SSH-Zertifikaten zeigt sich bei kurzen Gültigkeitsdauern. Ein Zertifikat, das nur 8 Stunden gültig ist, muss im Kompromittierungsfall nicht einmal widerrufen werden — es läuft einfach ab. Das ist elegant und spart eine Menge Verwaltungsaufwand. Hier ein Beispiel für ein automatisiertes Ausstellungsskript:

#!/bin/bash
# /usr/local/bin/ssh-cert-issue.sh
# Kurzlebiges SSH-Zertifikat ausstellen

set -euo pipefail

USER_PUBKEY="$1"
PRINCIPAL="$2"
VALIDITY="${3:-+8h}"
CA_KEY="/etc/ssh/ca/user_ca"

# Eindeutige Zertifikat-ID generieren
CERT_ID="${PRINCIPAL}-$(date -u +%Y%m%d-%H%M%S)-$(openssl rand -hex 4)"

# Zertifikat signieren
ssh-keygen -s "${CA_KEY}" \
    -I "${CERT_ID}" \
    -n "${PRINCIPAL}" \
    -V "${VALIDITY}" \
    -O "no-agent-forwarding" \
    -O "no-port-forwarding" \
    -O "no-x11-forwarding" \
    "${USER_PUBKEY}"

echo "Zertifikat ausgestellt: ${CERT_ID}"
echo "Gültigkeit: ${VALIDITY}"
echo "Zertifikat: ${USER_PUBKEY%.pub}-cert.pub"

Key Revocation List (KRL) verwalten

# Leere KRL erstellen
ssh-keygen -k -f /etc/ssh/revoked_keys

# Kompromittierten Schlüssel widerrufen
ssh-keygen -k -f /etc/ssh/revoked_keys -u compromised_key.pub

# Zertifikat anhand seiner ID widerrufen
ssh-keygen -k -f /etc/ssh/revoked_keys -u -s /etc/ssh/ca/user_ca.pub compromised-cert.pub

# KRL in sshd aktivieren
echo 'RevokedKeys /etc/ssh/revoked_keys' >> /etc/ssh/sshd_config.d/ca.conf

# sshd neu laden
systemctl reload sshd

Client-Konfiguration für Zertifikate und Host-Verifizierung

# ~/.ssh/config — Host-CA vertrauen (kein manuelles Fingerprint-Prüfen mehr)
@cert-authority *.example.com ssh-ed25519 AAAA... (Inhalt von host_ca.pub)

# Zertifikat explizit angeben
Host server01
    Hostname server01.example.com
    User mmueller
    CertificateFile ~/.ssh/id_ed25519-cert.pub
    IdentityFile ~/.ssh/id_ed25519

Agent-Forwarding: Risiken verstehen und sicher umgehen

Warum SSH-Agent-Forwarding gefährlich ist

SSH-Agent-Forwarding (ssh -A) ist bequem: Sie verbinden sich mit einem Jump-Host, und von dort aus können Sie sich zu weiteren Servern verbinden, ohne Ihren Schlüssel auf dem Jump-Host ablegen zu müssen. Klingt sicher — ist es aber nicht.

Das Problem ist simpel: Wenn der Jump-Host kompromittiert ist, kann ein Angreifer mit Root-Rechten den weitergeleiteten Agent-Socket nutzen, um sich in Ihrem Namen bei anderen Servern zu authentifizieren. Solange Ihre SSH-Session aktiv ist, hat der Angreifer Zugriff auf alle Server, für die Ihr Schlüssel autorisiert ist. Und 2025 kam noch eine unangenehme Überraschung dazu: Die Schwachstelle CVE-2025-32728 zeigte, dass die DisableForwarding-Option in sshd_config X11- und Agent-Forwarding nicht zuverlässig blockierte — ein Konfigurationsfehler, der vielen Administratoren ein falsches Sicherheitsgefühl gab.

Sichere Alternativen: ProxyJump und ProxyCommand

Statt Agent-Forwarding sollten Sie ProxyJump (verfügbar seit OpenSSH 7.3) verwenden. Hierbei baut der SSH-Client eine direkte, verschlüsselte Verbindung zum Zielserver auf und tunnelt diese durch den Jump-Host. Der private Schlüssel verlässt dabei nie Ihren lokalen Rechner:

# ProxyJump per Kommandozeile
ssh -J jumphost.example.com [email protected]

# ProxyJump in der SSH-Konfiguration
# ~/.ssh/config
Host jump
    Hostname jumphost.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519
    # Kein Agent-Forwarding!
    ForwardAgent no

Host internal-*
    ProxyJump jump
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Host internal-web
    Hostname 10.0.1.20

Host internal-db
    Hostname 10.0.1.30

# Verkettete Jumps über mehrere Bastion-Hosts
Host deep-internal
    Hostname 172.16.0.50
    ProxyJump jump,internal-web
    User admin

Bastion-Host härten

Der Bastion-Host (oder Jump-Host) ist ein besonders exponierter Server und verdient entsprechend besondere Aufmerksamkeit bei der Härtung:

# /etc/ssh/sshd_config.d/bastion.conf

# Nur ProxyJump/Forwarding erlauben, keine interaktive Shell
Match Group jump-users
    # TCP-Forwarding für ProxyJump erlauben
    AllowTcpForwarding yes

    # Alles andere deaktivieren
    X11Forwarding no
    AllowAgentForwarding no
    PermitTunnel no

    # Keine interaktive Shell
    ForceCommand /usr/sbin/nologin

    # Kurze Timeouts
    ClientAliveInterval 60
    ClientAliveCountMax 3

# Allgemeine Bastion-Einstellungen
MaxSessions 5
MaxStartups 10:30:30

Brute-Force-Schutz und Intrusion Detection

Fail2Ban konfigurieren

Fail2Ban ist so etwas wie der treue Wachhund für Ihren SSH-Zugang. Es überwacht die SSH-Logs und sperrt IP-Adressen nach einer definierten Anzahl fehlgeschlagener Anmeldeversuche automatisch:

# Fail2Ban installieren
# Debian/Ubuntu:
apt install fail2ban

# RHEL/Fedora:
dnf install fail2ban

# SSH-Jail konfigurieren
# /etc/fail2ban/jail.d/sshd.conf
[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
maxretry = 3
findtime = 600
bantime = 3600
banaction = nftables-multiport

# Aggressive Variante für wiederholte Angreifer
[sshd-aggressive]
enabled = true
port = ssh
filter = sshd[mode=aggressive]
backend = systemd
maxretry = 1
findtime = 86400
bantime = 604800
banaction = nftables-multiport

# Fail2Ban starten und aktivieren
systemctl enable --now fail2ban

# Status prüfen
fail2ban-client status sshd

SSH-Logs mit Auditd überwachen

Für tiefgreifende Überwachung und Compliance-Anforderungen sollten Sie Auditd einsetzen. Damit protokollieren Sie alle SSH-relevanten Ereignisse lückenlos:

# /etc/audit/rules.d/ssh.rules

# SSH-Konfigurationsänderungen überwachen
-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /etc/ssh/sshd_config.d/ -p wa -k ssh_config

# Autorisierte Schlüssel überwachen
-w /home/ -p wa -k authorized_keys_change

# SSH-Schlüsseldateien überwachen
-w /etc/ssh/ -p wa -k ssh_host_keys

# SSH-Prozesse überwachen
-a always,exit -F arch=b64 -S execve -F path=/usr/sbin/sshd -k sshd_exec
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ssh -k ssh_exec

# Audit-Regeln neu laden
augenrules --load

# SSH-bezogene Audit-Ereignisse abfragen
ausearch -k ssh_config --start today
ausearch -k authorized_keys_change --start today

SSH-Sicherheitsaudit: Checkliste und automatisierte Prüfung

Manuelle Prüfpunkte

Regelmäßige SSH-Sicherheitsaudits sollten fester Bestandteil Ihrer Routine sein. Hier die wichtigsten Prüfpunkte, die ich bei jedem Audit durchgehe:

# 1. Aktive Konfiguration des sshd anzeigen
sshd -T | grep -iE "passwordauthentication|permitrootlogin|pubkeyauthentication|maxauthtries|kexalgorithms|ciphers|macs"

# 2. Schwache Schlüssel finden
find /etc/ssh /home -name "*.pub" -exec sh -c '
    key_type=$(ssh-keygen -l -f "$1" 2>/dev/null | awk "{print \$NF}" | tr -d "()")
    key_bits=$(ssh-keygen -l -f "$1" 2>/dev/null | awk "{print \$1}")
    if [ "$key_type" = "DSA" ] || { [ "$key_type" = "RSA" ] && [ "$key_bits" -lt 3072 ]; }; then
        echo "SCHWACH: $1 ($key_bits bit $key_type)"
    fi
' _ {} \;

# 3. Authorized-Keys ohne Einschränkungen prüfen
for f in $(find /home -name "authorized_keys" 2>/dev/null); do
    echo "=== $f ==="
    grep -v "^#" "$f" | grep -v "^$" | while read -r line; do
        if ! echo "$line" | grep -qE "^(from=|command=|restrict)"; then
            key_comment=$(echo "$line" | awk '{print $NF}')
            echo "  WARNUNG: Uneingeschränkter Schlüssel - $key_comment"
        fi
    done
done

# 4. SSH-Dienst-Ports überprüfen
ss -tlnp | grep sshd

# 5. Aktive SSH-Verbindungen anzeigen
who | grep pts
ss -tnp | grep ":22"

Automatisierter Audit mit ssh-audit

Das Tool ssh-audit ist Gold wert, wenn Sie die Sicherheitskonfiguration eines SSH-Servers schnell und systematisch prüfen möchten:

# ssh-audit installieren
pip3 install ssh-audit

# Lokalen Server auditen
ssh-audit localhost

# Remote-Server auditen
ssh-audit server01.example.com

# Nur die Probleme anzeigen (Warnungen und Fehler)
ssh-audit --level warn server01.example.com

# Als JSON für automatisierte Verarbeitung
ssh-audit -j server01.example.com | python3 -m json.tool

# Policy-basierter Audit (Prüfung gegen eine Baseline)
ssh-audit --policy /etc/ssh-audit/hardened-policy.json server01.example.com

Fortgeschrittene Szenarien: SSH in der Praxis

SSH mit Zwei-Faktor-Authentifizierung (PAM + FIDO2)

Für höchste Sicherheitsanforderungen können Sie FIDO2 mit PAM-basierter Zwei-Faktor-Authentifizierung kombinieren. Der Benutzer muss dann sowohl einen gültigen SSH-Schlüssel als auch einen zweiten Faktor vorweisen (z.B. TOTP oder erneut eine physische Bestätigung). Ja, das ist etwas aufwändiger im Alltag — aber bei privilegierten Zugängen lohnt sich der Mehraufwand absolut:

# /etc/ssh/sshd_config.d/2fa.conf

# Mehrere Authentifizierungsmethoden erfordern
AuthenticationMethods publickey,keyboard-interactive

# PAM aktivieren
UsePAM yes
KbdInteractiveAuthentication yes

# In Kombination mit FIDO2-Schlüsseln:
# Der Benutzer muss:
# 1. Einen gültigen FIDO2-Schlüssel vorweisen (publickey)
# 2. Einen TOTP-Code eingeben (keyboard-interactive via PAM)
PubkeyAcceptedKeyTypes [email protected],[email protected]

SSH-Tunnel für Datenbankzugriff

Statt Datenbankports direkt ins Netzwerk zu exponieren (bitte nicht!), können Sie sichere SSH-Tunnel verwenden. Dieses Muster ist besonders nützlich für Datenbanken, interne Web-UIs oder andere Dienste, die nur lokal erreichbar sein sollen:

# Lokalen Port 5432 auf den PostgreSQL-Port des DB-Servers tunneln
ssh -L 5432:localhost:5432 -N -f [email protected]

# Mit ProxyJump über Bastion-Host
ssh -J bastion.example.com -L 5432:localhost:5432 -N -f [email protected]

# In der SSH-Konfiguration dauerhaft einrichten
# ~/.ssh/config
Host db-tunnel
    Hostname db.internal.example.com
    User dbadmin
    ProxyJump jump
    LocalForward 5432 localhost:5432
    # Keine Shell-Session öffnen
    RequestTTY no
    # Verbindung im Hintergrund halten
    ExitOnForwardFailure yes

Automatische Schlüsselrotation mit einem Ansible-Playbook

In Enterprise-Umgebungen mit vielen Servern sollte die Schlüsselrotation automatisiert werden. Manuell ist das ab einer gewissen Größenordnung einfach nicht mehr handhabbar:

# ssh-key-rotation.yml
---
- name: SSH-Host-Schlüssel rotieren und Zertifikate erneuern
  hosts: all
  become: yes
  vars:
    ca_host: "ca.example.com"
    cert_validity: "+365d"

  tasks:
    - name: Neue Host-Schlüssel generieren
      community.crypto.openssh_keypair:
        path: /etc/ssh/ssh_host_ed25519_key
        type: ed25519
        force: yes
      notify: restart sshd

    - name: Öffentlichen Schlüssel zur CA kopieren
      fetch:
        src: /etc/ssh/ssh_host_ed25519_key.pub
        dest: "/tmp/host-keys/{{ inventory_hostname }}.pub"
        flat: yes

    - name: Host-Zertifikat von der CA signieren lassen
      delegate_to: "{{ ca_host }}"
      command: >
        ssh-keygen -s /etc/ssh/ca/host_ca
        -I "{{ inventory_hostname }}"
        -h
        -n "{{ inventory_hostname }},{{ ansible_host }}"
        -V "{{ cert_validity }}"
        /tmp/host-keys/{{ inventory_hostname }}.pub

    - name: Signiertes Zertifikat zurückkopieren
      copy:
        src: "/tmp/host-keys/{{ inventory_hostname }}-cert.pub"
        dest: /etc/ssh/ssh_host_ed25519_key-cert.pub
        mode: '0644'
      notify: restart sshd

  handlers:
    - name: restart sshd
      systemd:
        name: sshd
        state: restarted

Häufige SSH-Fehlkonfigurationen und wie man sie erkennt

Selbst erfahrene Administratoren tappen bei der SSH-Konfiguration immer wieder in die gleichen Fallen. Hier die häufigsten Probleme — und wie Sie sie vermeiden.

Fehler 1: authorized_keys ohne Einschränkungen

Ein Eintrag in authorized_keys ohne Optionen gibt dem Inhaber des Schlüssels uneingeschränkten Zugang — interaktive Shell, Port-Forwarding, Agent-Forwarding, alles. Für Service-Accounts oder automatisierte Prozesse ist das viel zu viel:

# SCHLECHT: Uneingeschränkter Zugang
ssh-ed25519 AAAA... deploy-key

# BESSER: Einschränkungen für einen Deployment-Key
restrict,command="/usr/local/bin/deploy.sh",from="10.0.0.0/8" ssh-ed25519 AAAA... deploy-key

# Das Keyword 'restrict' deaktiviert alles (Agent-Forwarding,
# Port-Forwarding, PTY, X11) und lässt sich selektiv wieder aktivieren:
restrict,pty,from="192.168.1.0/24" ssh-ed25519 AAAA... admin-key

Fehler 2: Konfigurationsdateien ohne Priorität

OpenSSH verwendet die erste passende Direktive und ignoriert spätere. Das ist ein Detail, das viele übersehen. Wenn Ihre Härtungskonfiguration in /etc/ssh/sshd_config.d/99-hardening.conf liegt, aber die Standard-Datei /etc/ssh/sshd_config bereits PasswordAuthentication yes enthält, wird Ihre Härtung komplett ignoriert:

# Reihenfolge der Konfigurationsauswertung prüfen
sshd -T | grep passwordauthentication

# Sicherstellen, dass Include vor allen anderen Direktiven steht
head -5 /etc/ssh/sshd_config
# Erwartete Ausgabe:
# Include /etc/ssh/sshd_config.d/*.conf
# (danach erst die anderen Direktiven)

# Härtungs-Konfiguration mit hoher Priorität benennen
# Dateien werden alphabetisch geladen — 00 wird zuerst verarbeitet
mv /etc/ssh/sshd_config.d/hardening.conf /etc/ssh/sshd_config.d/00-hardening.conf

Fehler 3: Fehlende Monitoring-Alarmierung

Viele Administratoren aktivieren VERBOSE-Logging, richten aber keine Alarmierung ein. Erfolgreiche Logins von unbekannten IP-Adressen, fehlgeschlagene Authentifizierungsversuche mit unbekannten Schlüsseln oder ungewöhnliche Login-Zeiten — all das sollte aktiv überwacht werden, nicht nur in Logdateien versauern:

# Einfache Alarmierung für erfolgreiche SSH-Logins von neuen IPs
# /usr/local/bin/ssh-login-alert.sh
#!/bin/bash
KNOWN_IPS="/etc/ssh/known_login_ips.txt"
CURRENT_IP="${SSH_CONNECTION%% *}"

if ! grep -qF "${CURRENT_IP}" "${KNOWN_IPS}" 2>/dev/null; then
    echo "SSH-Login von neuer IP: ${CURRENT_IP} als $(whoami) auf $(hostname)" | \
        mail -s "[SSH-ALERT] Neuer Login auf $(hostname)" [email protected]
fi

# In /etc/ssh/sshd_config.d/alerting.conf aktivieren:
# ForceCommand /usr/local/bin/ssh-login-alert.sh; ${SHELL}

Zusammenfassung und Handlungsempfehlungen

Die SSH-Sicherheitslandschaft hat sich 2025 und 2026 fundamental verändert. Hier sind die wichtigsten Maßnahmen, priorisiert nach Wirksamkeit und Aufwand.

Sofort umsetzen (Grundschutz)

  1. OpenSSH auf Version 10.x aktualisieren — Sie erhalten damit automatisch Post-Quanten-Schlüsselaustausch, die neue Binär-Aufteilung und die DSA-Entfernung.
  2. Passwort-Authentifizierung deaktivieren — PasswordAuthentication no eliminiert Brute-Force-Angriffe sofort.
  3. Root-Login verbieten — PermitRootLogin no ist der wirksamste einzelne Konfigurationsparameter.
  4. Fail2Ban oder vergleichbaren Schutz aktivieren — Reduziert automatisierte Angriffe und schont Ressourcen.
  5. Kryptografie-Einstellungen überprüfen — Nur noch starke Algorithmen zulassen (Ed25519, ChaCha20-Poly1305, AEAD-Ciphers).

Mittelfristig umsetzen (erhöhter Schutz)

  1. FIDO2-Hardware-Schlüssel einführen — Die sicherste Form der SSH-Authentifizierung, besonders für Administratoren und privilegierte Zugänge.
  2. Agent-Forwarding durch ProxyJump ersetzen — Eliminiert eine der häufigsten SSH-Angriffsvektoren bei Lateral Movement.
  3. SSH-Audit-Tools einsetzen — Regelmäßige Prüfungen mit ssh-audit und Auditd-Regeln etablieren.
  4. Logging und Monitoring ausbauen — VERBOSE-Logging aktivieren und SSH-Events in ein zentrales SIEM einspeisen.

Langfristig umsetzen (Enterprise-Level)

  1. SSH Certificate Authority aufbauen — Zentralisierte Schlüsselverwaltung mit kurzlebigen Zertifikaten und automatisierter Ausstellung.
  2. Bastion-Host-Architektur implementieren — Gehärtete Jump-Hosts mit erzwungenem ProxyJump und vollständiger Audit-Protokollierung.
  3. Automatisierte Schlüsselrotation — Ansible, Puppet oder vergleichbare Tools für die regelmäßige Rotation von Host- und Benutzerschlüsseln.
  4. Zero-Trust-Integration — SSH-Zugang an Identity Provider koppeln und kontextbasierte Zugriffskontrollen implementieren.

SSH ist kein „einmal einrichten und vergessen"-Thema. Die Bedrohungslage entwickelt sich ständig weiter — mit Quantencomputern am Horizont, neuen Malware-Kampagnen wie P2PInfect und immer ausgefeilteren Angriffstechniken. Aber mit den hier vorgestellten Maßnahmen sind Sie bestens aufgestellt, um Ihre Linux-Infrastruktur auch in Zukunft sicher zu verwalten.

Planen Sie regelmäßige SSH-Audits ein, halten Sie OpenSSH aktuell, rotieren Sie Schlüssel und Zertifikate nach einem festen Zeitplan, und dokumentieren Sie Ihre SSH-Sicherheitsrichtlinien für Ihr Team. Die Investition in eine solide SSH-Infrastruktur zahlt sich bei jedem verhinderten Einbruchsversuch aus — und davon gibt es, wie die Statistiken zeigen, mehr als genug.

Über den Autor Editorial Team

Our team of expert writers and editors.