Zum Hauptinhalt springen

5. Compatibility With Old SSH Versions (Kompatibilität mit alten SSH-Versionen)

5. Compatibility With Old SSH Versions (Kompatibilität mit alten SSH-Versionen)

Wie zuvor angegeben, ist die für dieses Protokoll angegebene 'protoversion' "2.0". Frühere Versionen dieses Protokolls wurden nicht formal dokumentiert, es ist jedoch allgemein bekannt, dass sie 'protoversion' "1.x" verwenden (z. B. "1.5" oder "1.3"). Zum Zeitpunkt der Abfassung nutzen viele SSH-Implementierungen Protokollversion 2.0, es sind jedoch noch Geräte bekannt, die die früheren Versionen verwenden. In der Übergangsphase ist es wichtig, so zu arbeiten, dass Kompatibilität mit installierten SSH-Clients und -Servern besteht, die die ältere Protokollversion verwenden. Die Informationen in diesem Abschnitt sind nur für Implementierungen relevant, die Kompatibilität mit SSH-Versionen 1.x unterstützen. Für Interessierte: Die einzige bekannte Dokumentation des 1.x-Protokolls befindet sich in README-Dateien, die mit dem Quellcode ausgeliefert werden [ssh-1.2.30].

5.1. Old Client, New Server (Alter Client, neuer Server)

Server-Implementierungen KÖNNEN ein konfigurierbares Kompatibilitätsflag unterstützen, das Kompatibilität mit alten Versionen ermöglicht. Wenn dieses Flag gesetzt ist, SOLLTE der Server seine 'protoversion' als "1.99" ausweisen. Clients, die Protokoll 2.0 verwenden, MÜSSEN in der Lage sein, dies als identisch mit "2.0" zu erkennen. In diesem Modus SOLLTE der Server nach der Identifikationszeichenfolge KEIN Wagenrücklaufzeichen (ASCII 13) senden.

Im Kompatibilitätsmodus SOLLTE der Server nach dem Senden seiner Identifikationszeichenfolge KEINE weiteren Daten senden, bis er eine Identifikationszeichenfolge vom Client erhalten hat. Der Server kann dann feststellen, ob der Client ein altes Protokoll verwendet, und bei Bedarf zum alten Protokoll zurückkehren. Im Kompatibilitätsmodus DARF der Server KEINE zusätzlichen Daten vor der Identifikationszeichenfolge senden.

Wenn Kompatibilität mit alten Clients nicht erforderlich ist, KANN der Server unmittelbar nach der Identifikationszeichenfolge seine anfänglichen Schlüsselaustauschdaten senden.

5.2. New Client, Old Server (Neuer Client, alter Server)

Da der neue Client unmittelbar nach seiner Identifikationszeichenfolge zusätzliche Daten senden KANN (bevor er die Identifikationszeichenfolge des Servers empfängt), kann das alte Protokoll bereits beschädigt sein, wenn der Client erfährt, dass der Server alt ist. Wenn dies geschieht, SOLLTE der Client die Verbindung zum Server schließen und sich mit dem alten Protokoll neu verbinden.

5.3. Packet Size and Overhead (Paketgröße und Overhead)

Einige Leser werden sich Sorgen über die Zunahme der Paketgröße durch neue Header, Padding und den Message Authentication Code (MAC, Nachrichtenauthentifizierungscode) machen. Die Mindestpaketgröße liegt in der Größenordnung von 28 Bytes (abhängig von ausgehandelten Algorithmen). Die Zunahme ist bei großen Paketen vernachlässigbar, bei Ein-Byte-Paketen (Telnet-artige Sitzungen) jedoch sehr signifikant. Es gibt jedoch mehrere Faktoren, die dies in fast allen Fällen irrelevant machen:

  • Die Mindestgröße eines TCP/IP-Headers beträgt 32 Bytes. Die Zunahme beträgt damit tatsächlich von 33 auf 51 Bytes (grob).

  • Die Mindestgröße des Datenfelds eines Ethernet-Pakets beträgt 46 Bytes [RFC0894]. Die Zunahme beträgt daher höchstens 5 Bytes. Werden Ethernet-Header berücksichtigt, ist die Zunahme weniger als 10 Prozent.

  • Der Gesamtanteil telnet-artiger Daten im Internet ist vernachlässigbar, selbst bei größeren Paketen.

Die einzige Umgebung, in der die Paketgrößenzunahme wahrscheinlich spürbar wirkt, ist PPP [RFC1661] über langsame Modemleitungen (PPP komprimiert die TCP/IP-Header und verstärkt so die Paketgrößenzunahme). Mit modernen Modems liegt die Übertragungszeit jedoch in der Größenordnung von 2 Millisekunden, was deutlich schneller ist, als Menschen tippen können.

Es gibt auch Fragen zur maximalen Paketgröße. Um Verzögerungen bei Bildschirmaktualisierungen zu minimieren, möchte man bei interaktiven Sitzungen keine übermäßig großen Pakete. Die maximale Paketgröße wird für jeden Kanal (channel) separat ausgehandelt.