Zusammenfassung

  • Der erste Schlüsselaustausch erzeugt das gemeinsame Geheimnis K und den Austausch-Hash H. Dieser erste H wird zur Kennung der Verbindung und ergibt sich aus dem tatsächlichen Aushandlungsverlauf.
  • Ein Rekey darf Algorithmen, Verkehrsschlüssel, Initialisierungsvektoren, Kontexte und sogar den Hostschlüssel ändern. Die ursprüngliche Sitzungskennung bleibt bestehen.
  • Bei der Public-Key-Anmeldung umfasst die Signatur Sitzungskennung, Nutzer, Dienst, Methode, Algorithmus und Schlüssel. Das verhindert Wiederholung in einer anderen Verbindung, erteilt aber keine pauschale Betriebsberechtigung.

Eine Verbindung hatte zwei Erneuerungszyklen

Eine entfernte Shell kann stundenlang laufen. Dateiübertragungen und Tunnel tragen Zustand, der nicht bei jeder kryptografischen Wartung verschwinden soll. Die Schlüssel, die ihre Pakete schützen, müssen hingegen nicht so lange unverändert bleiben.

Wäre jeder Schlüsselwechsel eine neue Sitzung, müssten höhere Protokolle alle Kanäle neu anlegen. Würde jeder neue Schlüssel eine unabhängige Identität schaffen, ließe sich die vorherige Nutzeranmeldung nicht sauber mit dem anschließend geschützten Verkehr verbinden.

RFC 4251 teilte SSH 2 deshalb in Transport, Nutzerauthentifizierung und Verbindungsprotokoll. Der Transport authentifiziert den Server und schützt den Strom. Darüber authentifiziert sich die Nutzerseite. Das Verbindungsprotokoll multiplexiert schließlich Shells, Subsysteme und Weiterleitungen. Ein Rekey erneuert die unterste Schutzschicht, ohne automatisch den Zustand der oberen umzubenennen.

Die Kennung entstand aus Ausführung

Beide Seiten senden SSH_MSG_KEXINIT. Darin stehen ein zufälliges Cookie und geordnete Listen für Schlüsselaustausch, Server-Hostschlüssel, Verschlüsselung, Integrität und Kompression. Gewählt wird nach den Verfahrensregeln die erste vom Client bevorzugte Möglichkeit, die auch der Server unterstützt.

Das Verfahren berechnet ein gemeinsames Geheimnis K und einen Austausch-Hash H. Beim ursprünglichen Diffie-Hellman-Verfahren von SSH 2 fließen in H beide Versionskennungen, beide unveränderten KEXINIT-Nutzlasten, der Server-Hostschlüssel, die ephemeren Austauschwerte und das gemeinsame Geheimnis ein.

Ändert sich ein Versionsstring, Angebot, Hostschlüssel oder ephemerer Wert, beschreibt der Hash einen anderen Verlauf. Er ist keine Sitzungsnummer aus einer Datenbank und kein Etikett, das eine Seite vorgeben kann. Beide Peers liefern Material für seine Berechnung.

Die Zufallscookies verhindern, dass eine Seite Schlüssel und Kennung vollständig vorbestimmt. Die Sitzungskennung ist trotzdem kein Geheimnis. Ihre Veröffentlichung verrät K nicht und verleiht keine Fähigkeit, gültige Verschlüsselung oder Integrität zu erzeugen.

Der Server signiert den Austausch-Hash mit dem ausgehandelten privaten Hostschlüssel. Eine gültige Signatur beweist, dass der Inhaber dieses Schlüssels genau diesen Austausch signierte. Ob der öffentliche Schlüssel zum beabsichtigten Hostnamen gehört, bleibt eine Vertrauensentscheidung des Clients: gespeicherte Zuordnung, Zertifikat, extern geprüfter Fingerabdruck oder eine andere Richtlinie. Korrekte Kryptografie mit dem falschen Schlüssel führt weiterhin zum falschen Rechner.

Nur der erste Hash bezeichnete die Sitzung

RFC 4253 nutzt K und H zur Ableitung von Schlüsseln und Vektoren. Beim ersten Austausch erhält H zusätzlich die Rolle session_id. Diese Kennung ändert sich während der Verbindung nicht mehr.

Der übrige Rekey darf tief eingreifen. Jede Seite kann ihn anstoßen. Algorithmen und Hostschlüssel können wechseln. Alle Schlüssel und Initialisierungsvektoren werden neu berechnet; Verschlüsselungs- und Kompressionskontexte beginnen nach SSH_MSG_NEWKEYS neu. Der neue Austausch hat sein eigenes K und H, aber höhere Protokolle behalten den ersten Hash als Kontext.

Das macht Veränderungen nicht harmlos. Ein unerwarteter Hostschlüssel braucht eine neue Vertrauensprüfung, ein schwaches Verfahren kann unzulässig sein, ein fehlgeschlagener Rekey die Verbindung beenden. Die Aussage ist enger: Eine erfolgreiche Erneuerung des Transports ist keine neue Nutzeranmeldung und keine neue logische Verbindung.

Eine Wiederverbindung liegt außerhalb dieser Regel. Ihr erster Austausch erzeugt eine neue Kennung. Eine Anwendung kann Arbeit fortsetzen, muss aber zwei kryptografische Sitzungen als Vorgänger und Nachfolger behandeln.

Die Nutzersignatur band Anfrage und Verbindung zusammen

RFC 4252 lässt das Public-Key-Verfahren nicht nur den Nutzernamen signieren. Die signierten Daten beginnen mit der Sitzungskennung und enthalten anschließend SSH_MSG_USERAUTH_REQUEST, Nutzernamen, Dienst, Methodennamen, Wahrheitswert, Public-Key-Algorithmus und Schlüssel.

Eine aus Verbindung A kopierte Signatur scheitert in B, weil deren erster Austausch-Hash anders ist. Auch Konto, Dienst oder Algorithmus lassen sich nicht unbemerkt ändern. Der Nachweis besagt: Der private Schlüssel hat diese konkrete Anfrage in diesem Verbindungskontext bestätigt.

Der Server entscheidet dennoch getrennt. Ist die Signatur korrekt? Darf der Schlüssel für das behauptete Konto verwendet werden? Fehlt ein weiterer Faktor? Eine mathematisch gültige Signatur kann deshalb mit einer unvollständigen oder abgelehnten Authentifizierung zusammenfallen.

Hostbasierte Authentifizierung verwendet dieselbe Bindung und ergänzt Client-Hostname sowie lokalen Nutzer. Der Besitz eines Rechnerschlüssels ersetzt weder Namensprüfung noch Login-Berechtigung.

Authentifizierung war keine Blankovollmacht

Nach SSH_MSG_USERAUTH_SUCCESS startet der angeforderte Dienst. Erst danach werden häufig konkrete Shell-, Subsystem-, Portweiterleitungs- oder Agent-Anfragen gestellt. Diese Entscheidungen gehören zur lokalen Richtlinie des Servers.

Die Sitzungskennung liefert Zusammenhang, nicht Anspruch. Eine höhere Schicht kann damit sagen, dass ein Nachweis zu dieser geschützten Unterhaltung gehört. Sie kann daraus nicht ableiten, dass jede spätere Wirkung genehmigt sei.

Auch im Audit ist die Grenze wichtig. Sitzungskennung plus erfolgreiche Public-Key-Methode verbinden einen Login mit dem Transport. Ohne Kanal- und Richtlinienentscheidungen belegen sie keinen ausgeführten Befehl, keine zugelassene Weiterleitung und keinen Dateninhalt.

Die Algorithmen alterten, die Zuständigkeiten nicht

Nicht alle Verfahren von 2006 blieben geeignet. RFC 8332 ergänzte RSA-Signaturen mit SHA-256 und SHA-512 für Server- und Clientauthentifizierung. Vorhandenes RSA-Schlüsselmaterial konnte sein ssh-rsa-Format behalten, während ein neuer Name das stärkere Signaturverfahren wählte. Schlüssel, Algorithmus und signierte Aussage blieben getrennte Größen.

RFC 9142 überarbeitete später die Empfehlungen für SSH-Schlüsselaustauschverfahren und drängte SHA-1-basierte Varianten zurück. Das Verfahren für den ersten Austausch konnte sich weiterentwickeln, ohne den Vertrag der Schichten zu ändern: Dessen erster Hash blieb der Bezugspunkt.

Eine feste Kennung heilt keinen schlechten Anfang. Wurde der falsche Hostschlüssel vertraut oder ein ungeeignetes Verfahren akzeptiert, bindet sie spätere Nachweise präzise an diesen Fehler. Kontinuität ist nicht Güte.

Fünf Belege waren keine einzige Identität

Der Hostname bezeichnet das beabsichtigte Ziel. Der Hostschlüssel ist ein kryptografischer Prinzipal, der damit verknüpft werden muss. Der Austausch-Hash beschreibt eine Aushandlung. Sein erstes Exemplar bezeichnet die Verbindung. Der Nutzerschlüssel beweist Besitz für eine Anfrage. Die lokale Richtlinie erlaubt Handlungen.

Wer alles als „SSH-Identität“ speichert, löscht die Zuständigkeitsgrenzen. Die RFCs belegen Semantik und Algorithmusgeschichte, aber weder heutige Hostschlüsselprüfung noch Rekey-Häufigkeit, SHA-1-Nutzung oder einen bestimmten ausgeführten Befehl.

SSH bewahrte somit ein begrenztes, nützliches Stück Geschichte. Schlüssel durften wechseln; spätere Nachweise konnten den Beginn der Unterhaltung weiterhin eindeutig nennen. Der Hash wurde zum Kontext, nicht zur Autorität.