SSH · Verbindungsaufbau
Phase 1 läuft bei beiden Login-Methoden identisch ab. Erst in Phase 2 trennen sich die Wege.
Läuft bei Password- und Pubkey-Login identisch ab, bevor überhaupt ein Login-Versuch stattfindet.
Client und Server berechnen unabhängig voneinander denselben Session Key.
Geheimfarben werden nie übertragen, nur die Mischungen.
Server verschlüsselt Daten, die beide Seiten sowieso schon kennen (die Verbindungsdaten), mit seinem privaten Host Key — das nennt man signieren.
Client kennt die Verbindungsdaten selbst schon, entschlüsselt die vom Server geschickte Signatur mit dessen öffentlichem Host Key und vergleicht beides. Sind sie gleich, ist der Server authentifiziert — das nennt man prüfen.
Der öffentliche Host Key des Servers liegt beim Client in der Datei ~/.ssh/known_hosts — er muss dort schon hinterlegt sein, damit die Prüfung funktioniert.
Aus den Verbindungsdaten entsteht ein Fingerabdruck: die Session-ID (KEX-Hash).
Dieser Fingerabdruck wird später bei der Pubkey-Auth mitsigniert.
Ab jetzt läuft alles — inklusive der gleich folgenden Anmeldung — verschlüsselt über den Session Key.
Gleicher Schlüssel für beide Richtungen.
Hier unterscheiden sich die zwei Methoden.
Der bereits stehende Tunnel aus Phase 1 wird einfach weiterbenutzt.
Das Passwort ist nur „Klartext", der durch den schon verschlüsselten Tunnel geschickt wird — kein neues Konzept nötig.
Client bildet aus den gemeinsam bekannten Verbindungsdaten denselben Fingerabdruck wie in Phase 1.
Client „verschlüsselt" diesen Fingerabdruck mit seinem privaten Key — das ist die Signatur.
Spiegelbildlich zur Verschlüsselung: dort verschlüsselt der Sender mit dem Public Key des Empfängers, hier signiert der Client mit seinem eigenen Private Key.
Server bildet denselben Fingerabdruck unabhängig nach, entschlüsselt die Signatur mit dem öffentlichen Client-Key und vergleicht beides.
Der öffentliche Client-Key muss dafür vorher in der Datei ~/.ssh/authorized_keys auf dem Server hinterlegt worden sein.