Secure Shell

Secure Shell (SSH) ist ein kryptographisches Netzwerkprotokoll, das eine verschlüsselte und authentifizierte Verbindung zwischen zwei Systemen über ein unsicheres Netzwerk ermöglicht. SSH wurde Mitte der 1990er Jahre als Ablösung für Telnet, rlogin und rsh entwickelt — Protokolle, die Anmeldedaten und Sitzungsinhalte im Klartext übertrugen — und ist seit der Standardisierung als SSH-2 (RFC 4251–4254) der etablierte Mechanismus für Remote-Administration, Skript-gesteuerte Automatisierung und sicheren Dateitransfer via SFTP oder SCP.

Praktisch jeder Linux-Server, jeder Netzwerk-Switch mit Management-Interface und jede CI/CD-Pipeline kommuniziert über SSH. Genau diese Allgegenwart macht das Protokoll zu einem hochwertigen Ziel: Wer einen SSH-Schlüssel mit Zugriff auf produktive Systeme erbeutet, bewegt sich oft mit denselben Rechten wie ein erfahrener Administrator durch die Umgebung.

Architektur und Authentifizierungsmethoden

SSH baut auf einem Handshake mit Diffie-Hellman-Schlüsselaustausch, einer ausgehandelten Sitzungsverschlüsselung (z. B. AES-GCM oder ChaCha20-Poly1305) und einer beidseitigen Authentifizierung auf. Der Server identifiziert sich gegenüber dem Client über seinen Host-Schlüssel, der Client gegenüber dem Server über eine wählbare Authentifizierungsmethode.

In der Praxis kommen vier Methoden vor: Passwort-Authentifizierung, Public-Key-Authentifizierung mit einem lokal gespeicherten Schlüsselpaar, Zertifikats-basierte Authentifizierung mit kurzlebigen, von einer SSH-CA signierten Zertifikaten und GSSAPI/Kerberos in Active-Directory- oder MIT-Kerberos-Umgebungen. Public-Key-Authentifizierung mit ssh-ed25519 ist heute der Standard für moderne Deployments — Ed25519-Schlüssel sind kurz, schnell und gelten als kryptographisch robust.

Host-Keys, known_hosts und Trust-on-First-Use

Beim ersten Verbindungsaufbau präsentiert der Server seinen Host-Schlüssel. Der Client speichert dessen Fingerprint in der Datei known_hosts und prüft bei jeder weiteren Verbindung, ob der Schlüssel unverändert ist. Dieses Modell wird Trust-on-First-Use (TOFU) genannt und hat eine systembedingte Schwäche: Die Vertrauensentscheidung fällt genau in dem Moment, in dem ein Angreifer am leichtesten eine Man-in-the-Middle-Position einnehmen kann — beim ersten Kontakt.

In sensiblen Umgebungen lässt sich TOFU durch SSHFP-DNS-Records (mit DNSSEC signiert) oder durch eine SSH-Zertifikatsinfrastruktur ersetzen, bei der der Client lediglich der CA vertraut und Host-Zertifikate dynamisch validiert. Wir finden in Assessments regelmäßig known_hosts-Dateien, die seit Jahren ungepflegt sind und Hostnamen mit längst rotierten Schlüsseln enthalten — ein klares Indiz für fehlende Schlüsselverwaltung.

ssh-agent und die Risiken von Agent-Forwarding

Der ssh-agent hält entschlüsselte private Schlüssel im Speicher und stellt sie über einen Unix-Socket lokalen Prozessen zur Verfügung. Das ist komfortabel — die Passphrase muss pro Sitzung nur einmal eingegeben werden — und sicherheitstechnisch akzeptabel, solange der Agent ausschließlich auf der eigenen Workstation läuft.

Problematisch wird Agent-Forwarding (ForwardAgent yes oder ssh -A). Dabei wird der Agent-Socket auf einen entfernten Host weitergeleitet, sodass von dort aus weitere SSH-Verbindungen mit den eigenen Schlüsseln aufgebaut werden können. Wer Root-Rechte auf einem Zwischenhost erlangt, kann den weitergeleiteten Socket missbrauchen und Verbindungen im Namen des Nutzers initiieren — ohne jemals den Schlüssel selbst zu sehen. Auf Jump-Hosts ist Agent-Forwarding daher pauschal zu vermeiden. Modernere Alternativen sind ProxyJump (ssh -J), das die Verbindung über den Jump-Host tunnelt, ohne den Agent zu exponieren, sowie die Confirmation-Funktion (ssh-add -c), die für jede Schlüsselnutzung eine Bestätigung erzwingt.

Härtung produktiver SSH-Server

Eine solide Server-seitige Konfiguration in /etc/ssh/sshd_config reduziert die Angriffsfläche deutlich. Wesentlich sind PasswordAuthentication no, sobald Schlüssel ausgerollt sind, sowie PermitRootLogin no oder prohibit-password, sodass Administration ausschließlich über unprivilegierte Konten mit sudo erfolgt. Über PubkeyAcceptedAlgorithms und HostKeyAlgorithms werden veraltete Algorithmen entfernt und nur Ed25519 sowie RSA-mit-SHA-2 zugelassen. AllowGroups oder AllowUsers begrenzen den SSH-Zugang explizit auf die tatsächlich benötigten Konten (Least Privilege), während MaxAuthTries, LoginGraceTime und ergänzend Fail2Ban oder CrowdSec Brute-Force-Versuche eindämmen.

Eine zusätzliche Multi-Faktor-Authentifizierung lässt sich über PAM einbinden — etwa via TOTP, Push-Bestätigung oder hardwarebasierte Authenticator. Besonders elegant ist die Kombination aus Public-Key plus FIDO2-Hardware-Token (ssh-ed25519-sk), bei dem der private Schlüssel den Sicherheits-Token niemals verlässt und jede Anmeldung eine physische Berührung erfordert.

Zertifikats-basierte Authentifizierung bei Scale

Sobald eine Organisation mehr als eine Handvoll Server und mehrere Administratoren hat, wird die Pflege von authorized_keys-Dateien unübersichtlich. Aus- und eintretende Mitarbeitende, rotierende Schlüssel und temporäre Externe lassen sich kaum sauber abbilden.

SSH-Zertifikate (signiert von einer internen SSH-CA) lösen das Problem strukturell: Server vertrauen einer CA, Nutzer erhalten kurzlebige, an Identität und Rolle gebundene Zertifikate. Open-Source-Werkzeuge wie step-ca, kommerzielle Plattformen wie Teleport oder HashiCorp Boundary integrieren das mit zentralem Identity-Provider, Just-in-Time-Zugriff und Sitzungs-Auditing. Der praktische Effekt: Ein gekündigter Mitarbeiter verliert ohne manuelle Schritte auf jedem einzelnen Server seine Berechtigung, weil sein Zertifikat schlicht ausläuft.

Port-Forwarding und Tunneling kontrollieren

SSH kann beliebige TCP-Verbindungen tunneln (LocalForward, RemoteForward, DynamicForward). In den falschen Händen wird das zum Daten-Exfiltrationskanal und zum Bypass von Firewall-Regeln. Auf produktiven Hosts gehört in die sshd_config daher AllowTcpForwarding no oder eine restriktive Variante wie AllowTcpForwarding local, ergänzt um PermitOpen mit einer Allowlist. GatewayPorts no verhindert, dass Forwards auf externen Interfaces lauschen.

Typische Risiken in der Praxis

In Assessments tauchen immer wieder dieselben Muster auf. Private Schlüssel ohne Passphrase auf Entwickler-Workstations sind besonders verbreitet — wer eine solche Maschine kompromittiert, erhält direkten Zugriff auf alle Systeme, mit denen der Schlüssel je verwendet wurde. Aus genau diesem Grund ist die Eindämmung von Lateral Movement in SSH-Umgebungen kein Nebenschauplatz: Aus einer einzigen kompromittierten Entwickler-Maschine lässt sich häufig die gesamte Produktionsumgebung erreichen, sobald dort Build-Server, Bastion-Hosts und Container-Registries dieselben Schlüssel akzeptieren.

Weitere Klassiker sind alte Schlüssel in authorized_keys ehemaliger Mitarbeitender, fehlende Inventarisierung aller SSH-Schlüssel im Unternehmen sowie Service-Accounts mit weitreichenden Rechten, deren Schlüssel in Repositories oder Konfigurationsmanagement-Snapshots auftauchen. CI/CD-Systeme mit SSH-Deploy-Keys ohne Beschränkung auf einzelne Repositories sind ein weiterer beliebter Einfallsweg.

Relevanz für KMUs

In mittelständischen Umgebungen wächst der SSH-Bestand meist organisch: Ein Admin legt einen Schlüssel auf seinem Laptop an, ein Auftragnehmer bekommt Zugriff für ein Projekt, ein Skript erhält einen Deploy-Key — und nach fünf Jahren weiß niemand mehr, welche Schlüssel auf welchen Systemen liegen. Genau diese Intransparenz ist das eigentliche Risiko, nicht eine theoretische Schwäche im Protokoll.

Ein realistisches Vorgehen für KMUs beginnt mit einer Bestandsaufnahme aller authorized_keys-Dateien auf produktiven Hosts, der Deaktivierung der Passwort-Authentifizierung und dem konsequenten Verbot von Root-Login. In einem zweiten Schritt sollten alle privaten Schlüssel mit einer Passphrase versehen sein und idealerweise auf einem FIDO2-Token landen. Wer regelmäßig Externe einbindet oder mehr als 20–30 Server administriert, sollte den Schritt zu einer zertifikats-basierten Lösung einplanen — der Pflegeaufwand für statische authorized_keys wächst sonst schneller als die Disziplin, sie sauber zu halten.