SSH-Handshake und Host-Key-Authentifizierung

SSH beginnt mit einer TCP-Verbindung zu Port 22. Sobald diese hergestellt ist, tauschen Client und Server Versionszeichenfolgen wie SSH-2.0-OpenSSH_9.3 aus, die die Protokollversion und die Implementierung angeben. Durch diesen Versionsaustausch können beide Seiten die Kompatibilität bestätigen, bevor sie fortfahren.

Nach dem Versionsaustausch senden beide Parteien SSH_MSG_KEXINIT-Pakete, in denen sie ihre unterstützten Algorithmen auflisten. Diese Listen umfassen Schlüsselaustauschverfahren, Hostschlüsseltypen, symmetrische Verschlüsselungsverfahren, MAC-Algorithmen und Komprimierung. Der Schnittpunkt beider Listen bestimmt die für die Sitzung ausgewählten Algorithmen.

Der Sitzungsschlüssel wird mithilfe eines Schlüsselaustauschalgorithmus wie Diffie-Hellman oder ECDH festgelegt. Client und Server erzeugen jeweils ein kurzlebiges Schlüsselpaar, tauschen öffentliche Werte aus und berechnen unabhängig voneinander dasselbe gemeinsame Geheimnis. Dieses gemeinsame Geheimnis dient als Grundlage für die Ableitung des Sitzungsschlüssels, ohne jemals direkt übertragen zu werden.

Der Server weist seine Identität nach, indem er den Hash des Schlüsselaustauschs mit seinem privaten Hostschlüssel signiert. Der Hostschlüssel kann im RSA-, ECDSA- oder modernen Ed25519-Format vorliegen. Der Client verwendet den zugehörigen öffentlichen Schlüssel, um diese Signatur zu überprüfen. So wird bestätigt, dass er mit dem echten Server und nicht mit einem Angreifer kommuniziert.

Bei der ersten Verbindung zu einem neuen Server kennt der Client den öffentlichen Hostschlüssel noch nicht. SSH zeigt den Fingerabdruck des Schlüssels an und fordert Sie auf, ihn zu akzeptieren. Dieses Modell des Vertrauens bei erstmaliger Verwendung speichert den Schlüssel in known_hosts und erkennt Änderungen bei späteren Verbindungen, wobei vor möglichen Man-in-the-Middle-Angriffen gewarnt wird.

Am sichersten überprüfen Sie einen neuen Server-Hostschlüssel über einen unabhängigen Kommunikationskanal. Ein Administrator kann den Fingerabdruck des Servers persönlich oder über einen verifizierten sicheren Kanal mitteilen. Anschließend vergleichen Sie ihn mit dem vom SSH-Client angezeigten Fingerabdruck. Dadurch wird verhindert, dass bei der ersten Verbindung unbemerkt ein gefälschter Schlüssel akzeptiert wird.

Die Datei known_hosts speichert Zeilen im Format: hostname algorithm base64-key. Jeder Eintrag steht für eine vertrauenswürdige Serveridentität. Wenn Sie eine bereits in known_hosts enthaltene Hostadresse verbinden, überprüft SSH, ob der präsentierte Schlüssel mit dem gespeicherten übereinstimmt. Bei einer Abweichung wird die Verbindung abgelehnt.

Nach dem Schlüsselaustausch leiten beide Seiten unabhängig voneinander Sitzungsschlüssel aus dem gemeinsamen Geheimnis, dem Hash des Schlüsselaustauschs und der Sitzungskennung ab. Für jede Kommunikationsrichtung sowie getrennt für Verschlüsselungs- und MAC-Operationen werden eigene Schlüssel abgeleitet. Daher unterscheiden sich die für den Datenverkehr vom Client zum Server verwendeten Schlüssel von den Schlüsseln für die Gegenrichtung.

Sobald die Sitzungsschlüssel festgelegt sind, wird die gesamte weitere SSH-Kommunikation verschlüsselt und authentifiziert. Das ausgehandelte Verschlüsselungsverfahren, beispielsweise AES-256-GCM oder ChaCha20-Poly1305, schützt die Vertraulichkeit, während der MAC die Integrität sicherstellt. Selbst der Benutzername und die Authentifizierungsdaten werden innerhalb dieses verschlüsselten Tunnels übertragen.

RSA-Hostschlüssel mit 2048 oder 4096 Bit werden weithin unterstützt, sind jedoch langsamer. Auf NIST-Kurven basierende ECDSA-Schlüssel sind schneller, doch manche Fachleute misstrauen den Parametern der NIST-Kurven. Ed25519-Schlüssel auf Basis von Curve25519 gelten als moderne Empfehlung: Sie sind klein, schnell und bieten hohe Sicherheit, ohne von NIST-Kurvenparametern abhängig zu sein. Die meisten modernen SSH-Server bieten Ed25519 standardmäßig an.

Der SSH-Handshake umfasst: TCP-Verbindung, Versionsaustausch, Algorithmusaushandlung, Schlüsselaustausch zur Festlegung der Sitzungsschlüssel, Überprüfung des Server-Hostschlüssels und Benutzerauthentifizierung. Alle Schritte nach dem Versionsaustausch finden innerhalb eines verschlüsselten und gegen Manipulation geschützten Kanals statt, der durch die Schlüsselaustauschphase eingerichtet wurde.

Wie überprüft ein Client den Hostschlüssel des SSH-Servers bei späteren Verbindungen nach der ersten Verbindung?

In dieser Lektion: TCP stellt eine Verbindung über Port 22 her, Versionszeichenfolgen werden ausgetauscht, die Algorithmusaushandlung wählt Verschlüsselungsverfahren und Schlüsselaustauschmethoden aus, ECDH oder DH legt ein gemeinsames Geheimnis fest, Sitzungsschlüssel werden für jede Richtung getrennt abgeleitet, der Server authentifiziert sich mit seiner Hostschlüssel-Signatur, und der Client überprüft den Schlüssel anhand von known_hosts, wobei bei der ersten Verbindung TOFU verwendet wird.