Zum Hauptinhalt springen

4. Connection Setup (Verbindungsaufbau)

4. Connection Setup (Verbindungsaufbau)

SSH arbeitet über jeden 8-bit-cleanen, binärtransparenten Transport (8-bit clean, binary-transparent transport). Der zugrunde liegende Transport SOLLTE vor Übertragungsfehlern schützen, da solche Fehler zum Abbruch der SSH-Verbindung führen.

Der Client (client) initiiert die Verbindung.

4.1. Use over TCP/IP (Verwendung über TCP/IP)

Bei Verwendung über TCP/IP wartet der Server normalerweise auf Port 22 auf Verbindungen. Diese Portnummer wurde bei der IANA registriert und offiziell für SSH zugewiesen.

4.2. Protocol Version Exchange (Protokollversionsaustausch)

Wenn die Verbindung hergestellt wurde, MÜSSEN beide Seiten eine Identifikationszeichenfolge (identification string) senden. Diese Identifikationszeichenfolge MUSS sein

SSH-protoversion-softwareversion SP comments CR LF

Da das in diesem Dokumentensatz definierte Protokoll Version 2.0 ist, MUSS 'protoversion' "2.0" sein. Die 'comments'-Zeichenfolge ist OPTIONAL. Wenn die 'comments'-Zeichenfolge enthalten ist, MUSS ein Leerzeichen (oben als SP bezeichnet, ASCII 32) die 'softwareversion'- und 'comments'-Zeichenfolgen trennen. Die Identifikation MUSS mit einem einzelnen Wagenrücklauf (Carriage Return, CR) und einem einzelnen Zeilenvorschub (Line Feed, LF) (ASCII 13 bzw. 10) enden. Implementierer, die die Kompatibilität mit älteren, undokumentierten Versionen dieses Protokolls aufrechterhalten möchten, möchten möglicherweise die Identifikationszeichenfolge verarbeiten, ohne das Vorhandensein des Wagenrücklaufzeichens zu erwarten, aus Gründen, die in Abschnitt 5 dieses Dokuments beschrieben werden. Das Nullzeichen DARF NICHT gesendet werden. Die maximale Länge der Zeichenfolge beträgt 255 Zeichen, einschließlich Wagenrücklauf und Zeilenvorschub.

Der Teil der Identifikationszeichenfolge vor dem Wagenrücklauf und Zeilenvorschub wird beim Diffie-Hellman-Schlüsselaustausch (Diffie-Hellman key exchange) verwendet (siehe Abschnitt 8).

Der Server KANN andere Datenzeilen senden, bevor er die Versionszeichenfolge sendet. Jede Zeile SOLLTE mit einem Wagenrücklauf und Zeilenvorschub enden. Solche Zeilen DÜRFEN NICHT mit "SSH-" beginnen und SOLLTEN in ISO-10646 UTF-8 [RFC3629] codiert sein (die Sprache ist nicht angegeben). Clients MÜSSEN in der Lage sein, solche Zeilen zu verarbeiten. Solche Zeilen KÖNNEN stillschweigend ignoriert werden oder KÖNNEN dem Client-Benutzer angezeigt werden. Wenn sie angezeigt werden, SOLLTE die in [SSH-ARCH] beschriebene Filterung von Steuerzeichen (control character filtering) verwendet werden. Der Hauptzweck dieser Funktion besteht darin, TCP-Wrappern (TCP-wrappers) zu ermöglichen, eine Fehlermeldung anzuzeigen, bevor die Verbindung getrennt wird.

Sowohl die 'protoversion'- als auch die 'softwareversion'-Zeichenfolgen MÜSSEN aus druckbaren US-ASCII-Zeichen bestehen, mit Ausnahme von Leerzeichen (whitespace) und dem Minuszeichen (-). Die 'softwareversion'-Zeichenfolge wird hauptsächlich verwendet, um Kompatibilitätserweiterungen (compatibility extensions) auszulösen und die Fähigkeiten einer Implementierung anzuzeigen. Die 'comments'-Zeichenfolge SOLLTE zusätzliche Informationen enthalten, die bei der Lösung von Benutzerproblemen hilfreich sein könnten. Ein Beispiel für eine gültige Identifikationszeichenfolge ist daher

SSH-2.0-billsSSH_3.6.3q3<CR><LF>

Diese Identifikationszeichenfolge enthält nicht die optionale 'comments'-Zeichenfolge und endet daher unmittelbar nach der 'softwareversion'-Zeichenfolge mit CR und LF.

Der Schlüsselaustausch (key exchange) beginnt unmittelbar nach dem Senden dieses Identifikators. Alle Pakete nach der Identifikationszeichenfolge SOLLEN das binäre Paketprotokoll (binary packet protocol) verwenden, das in Abschnitt 6 beschrieben wird.