Authentifizierung mit öffentlichen Schlüsseln und Agent-Weiterleitung

Die Authentifizierung mit öffentlichen SSH-Schlüsseln basiert auf der Datei authorized_keys, die sich auf dem Server normalerweise unter ~/.ssh/authorized_keys befindet. Jede Zeile enthält einen öffentlichen Schlüssel im Format: algorithm base64-key comment. Der Server überprüft, ob der Client den Besitz des zugehörigen privaten Schlüssels durch das Signieren einer Challenge nachweisen kann.

Der Befehl ssh-keygen erstellt Schlüsselpaare zur Authentifizierung. Wenn Sie ssh-keygen -t ed25519 ausführen, wird ein modernes Ed25519-Schlüsselpaar erzeugt. Mit -C können Sie einen Kommentar zur Identifizierung angeben, beispielsweise Ihre E-Mail-Adresse. Das Tool speichert den privaten Schlüssel (id_ed25519) und den öffentlichen Schlüssel (id_ed25519.pub) standardmäßig unter ~/.ssh.

RSA-Schlüssel mit 4096 Bit sind mit älteren Systemen sehr kompatibel, signieren jedoch langsamer. ECDSA mit NIST P-256 ist schneller und erzeugt kleinere Signaturen, doch manche Kryptografen stellen die Auswahl der NIST-Kurvenparameter infrage. Ed25519 auf Basis von Curve25519 gilt derzeit als Best Practice: schnelle, kleine Schlüssel und Signaturen, keine bekannten Schwachstellen und Verfügbarkeit in allen modernen SSH-Implementierungen.

Die Datei mit dem privaten Schlüssel sollte durch eine Passphrase geschützt werden. ssh-keygen verschlüsselt den privaten Schlüssel mit einem aus der Passphrase abgeleiteten Schlüssel (bei modernen Schlüsseln mit bcrypt), sodass ein Angreifer, der die Datei stiehlt, sie ohne die Passphrase nicht verwenden kann. Ohne Passphrase kann jeder mit Zugriff auf die Datei sich bei jedem Server authentifizieren, der den zugehörigen öffentlichen Schlüssel besitzt.

Der ssh-agent-Daemon hält entschlüsselte private Schlüssel während einer Anmeldesitzung im Arbeitsspeicher. Sie laden einen Schlüssel mit ssh-add ~/.ssh/id_ed25519. Dabei werden Sie einmalig nach der Passphrase gefragt. Bei nachfolgenden SSH-Verbindungen bittet der Client den Agenten, Challenges zu signieren, ohne dass Sie die Passphrase erneut eingeben müssen. So werden Sicherheit und Komfort miteinander verbunden.

Wenn ein SSH-Server eine Authentifizierungs-Challenge sendet, delegiert der SSH-Client die Signatur über einen Unix-Socket an ssh-agent. Der Agent führt die kryptografische Signatur mit dem im Arbeitsspeicher gespeicherten privaten Schlüssel aus und gibt nur die Signatur zurück. Die Bytes des privaten Schlüssels verlassen den Agent-Prozess niemals, nicht einmal in Richtung des SSH-Clients.

Die Agent-Weiterleitung (ForwardAgent yes oder ssh -A) ermöglicht es einer entfernten SSH-Sitzung, Ihren lokalen Agenten für die weitere Authentifizierung zu verwenden. Das ist nützlich, wenn Sie über Bastion-Hosts springen möchten, ohne private Schlüssel auf die Bastion zu kopieren. Wird die Bastion jedoch kompromittiert, kann ein Root-Benutzer dort auf Ihren Agent-Socket zugreifen und sich bei jedem Server als Sie authentifizieren.

ProxyJump (ssh -J bastion target) ist die sicherere Alternative zu ForwardAgent für den Zugriff über Bastion-Hosts. Dabei wird ein TCP-Tunnel durch die Bastion eingerichtet, ohne dort Ihren Agent-Socket offenzulegen. Der Zielserver erhält eine direkte Verbindung von Ihrem lokalen Client, während die Bastion nur verschlüsselte TCP-Daten weiterleitet und Ihre Zugangsdaten nicht verwenden kann.

SSH unterstützt die zertifikatsbasierte Authentifizierung, bei der eine Certificate Authority (CA) öffentliche Host- und Benutzerschlüssel signiert. Statt einzelne öffentliche Schlüssel auf jedem Server zu verteilen, konfigurieren Sie die Server so, dass sie Ihrer CA vertrauen. Ein signiertes Benutzerzertifikat gewährt Zugriff auf alle Server, die dieser CA vertrauen. Ablaufzeit und Einschränkungen für Principals können optional im Zertifikat hinterlegt werden.

Das Tool ssh-keyscan verbindet sich mit einem oder mehreren Hosts und ruft deren öffentliche Hostschlüssel ohne Authentifizierung ab. Das ist nützlich, um die Dateien known_hosts in Deployment-Skripten automatisiert zu befüllen. Die Ausgabe kann direkt in eine known_hosts-Datei weitergeleitet werden: ssh-keyscan -H example.com >> ~/.ssh/known_hosts.

Authentifizierung mit öffentlichen Schlüsseln: Der Client sendet den öffentlichen Schlüssel, der Server überprüft authorized_keys, der Server sendet eine mit der Sitzungskennung signierte Challenge, der Client signiert sie (über den Agenten) mit dem privaten Schlüssel, und der Server überprüft die Signatur mithilfe des gespeicherten öffentlichen Schlüssels. Ist sie gültig, gelingt die Authentifizierung, ohne dass ein geheimes Zugangsmittel übertragen wird.

Welcher SSH-Schlüsseltyp gilt aufgrund seiner Geschwindigkeit, seiner geringen Schlüssellänge und seiner starken Sicherheitseigenschaften derzeit als Best Practice für neue Deployments?

Die wichtigsten Punkte: Speichern Sie öffentliche Schlüssel in authorized_keys, schützen Sie private Schlüssel mit Passphrasen, verwenden Sie ssh-agent, um entschlüsselte Schlüssel im Arbeitsspeicher zu halten, bevorzugen Sie den Schlüsseltyp Ed25519, verwenden Sie für den Zugriff über Bastion-Hosts ProxyJump statt ForwardAgent, um den Agent-Socket nicht offenzulegen, und ziehen Sie SSH-Zertifikate für eine skalierbare Zugriffsverwaltung in Betracht.