5. 古い SSH バージョンとの互換性

前述のとおり、このプロトコルで指定される 'protoversion' は "2.0" です。このプロトコルの以前のバージョンは正式には文書化されていませんが、'protoversion' として "1.x"（例: "1.5" または "1.3"）を使用することが広く知られています。本文書の執筆時点では、多くの SSH 実装がプロトコルバージョン 2.0 を使用していますが、以前のバージョンを使用するデバイスもまだ存在することが知られています。移行期間中は、古いバージョンのプロトコルを使用する既存の SSH クライアントおよびサーバーと互換性のある方法で動作できることが重要です。この節の情報は、SSH バージョン 1.x との互換性をサポートする実装にのみ関連します。関心のある読者のために言えば、1.x プロトコルについて知られている唯一の文書は、ソースコードとともに配布される README ファイル [ssh-1.2.30] にあります。

5.1. 古いクライアント、新しいサーバー

サーバー実装は、古いバージョンとの互換性を有効にする設定可能な互換性フラグをサポートしてもかまいません。このフラグが有効な場合、サーバーは自身の 'protoversion' を "1.99" として識別すべきです。プロトコル 2.0 を使用するクライアントは、これを "2.0" と同一として識別できなければなりません。このモードでは、サーバーは識別文字列の後に Carriage Return 文字（ASCII 13）を送信すべきではありません。

互換モードでは、サーバーはクライアントから識別文字列を受信するまで、自身の識別文字列を送信した後に追加データを送信すべきではありません。これにより、サーバーはクライアントが古いプロトコルを使用しているかを判定でき、必要であれば古いプロトコルに戻ることができます。互換モードでは、サーバーは識別文字列の前に追加データを送信してはなりません。

古いクライアントとの互換性が不要な場合、サーバーは識別文字列の直後に初期鍵交換データを送信してもかまいません。

5.2. 新しいクライアント、古いサーバー

新しいクライアントは自身の識別文字列の直後（サーバーの識別文字列を受信する前）に追加データを送信してもかまわないため、クライアントがサーバーが古いことを認識した時点で、古いプロトコルはすでに壊れている可能性があります。この場合、クライアントはサーバーへの接続を閉じ、古いプロトコルを使用して再接続すべきです。

5.3. パケットサイズとオーバーヘッド

新しいヘッダー、パディング、および Message Authentication Code (MAC) によるパケットサイズの増加を懸念する読者もいるでしょう。最小パケットサイズは約 28 バイトです（交渉されたアルゴリズムによって異なります）。大きなパケットでは増加は無視できますが、1 バイトのパケット（telnet 型セッション）では非常に大きくなります。ただし、ほとんどすべての場合で問題にならない理由がいくつかあります。

TCP/IP ヘッダーの最小サイズは 32 バイトです。したがって、増加は実際にはおよそ 33 バイトから 51 バイトです。
Ethernet パケットのデータフィールドの最小サイズは 46 バイトです [RFC0894]。したがって、増加は最大でも 5 バイトです。Ethernet ヘッダーを考慮すると、増加は 10 パーセント未満です。
インターネットにおける telnet 型データの総割合は、パケットサイズの増加を考慮しても無視できるほど小さいものです。

パケットサイズの増加が大きな影響を与える可能性がある唯一の環境は、低速モデム回線上の PPP [RFC1661] です（PPP は TCP/IP ヘッダーを圧縮するため、パケットサイズの増加が強調されます）。しかし、現代のモデムでは、転送に必要な時間は約 2 ミリ秒であり、人が入力できる速度よりはるかに速いものです。

最大パケットサイズにも関連する問題があります。画面更新の遅延を最小化するには、対話型セッションで過度に大きなパケットは望ましくありません。最大パケットサイズは、チャネルごとに個別に交渉されます。