SSH バージョン1と2の互換性について

SSH のバージョン1と2では、使っているプロトコルに互換性がない。 そのため、バージョン1のクライアントとバージョン2のサーバ、 あるいはバージョン2のクライアントとバージョン1のサーバの 組合わせでは使えない。

しかし、 SSH バージョン2の実装は、 相手がバージョン1だとわかったとき、 そのホストにバージョン1がインストールされているときは 自動的に切り替えるということをしてくれる。

その仕組みとそれがうまく行く条件について説明する。 具体的な設定方法は、参考文献SSH2 Quick Start を参照されたい。

SSH プロトコルの概要

SSH プロトコルでは、接続確立後、まず最初に、バージョン識別子の交換をする。 バージョン識別子は、 SSH-<protocol version>-<software version> の形をしている。 例えば、 ssh-1.2.26 だと、SSH-1.5-1.2.26 となる。 バージョン識別子は、まずサーバからクライアントへ送られ、その後、 クライアントからサーバへ送られる。

交換されたバージョン識別子を使って、通信を続けるかどうかの決定がなされる。

バージョン識別子交換後の通信は、バイナリパケットプロトコルによって行われ、 すべての情報はパケットと呼ばれる塊で送られる。

バージョン2のクライアントでバージョン1のサーバに接続する

バージョン2のクライアントでバージョン1のサーバに接続したとき、 サーバは、クライアントの新しいバージョンには対応できないという エラーを出して、接続を中断する。

クライアント側は、バージョン1のクライアントを起動して、 再度接続を試みる。

バージョン1のクライアントでバージョン2のサーバに接続する

バージョン1のクライアントでバージョン2のサーバに接続したとき、 バージョン識別子の交換後、サーバは、バージョン1のサーバを起動し、 交信の続きを行わせる。このとき、起動されるバージョン1のサーバは、 バージョン識別子の交換をもう一度行ってはならない。 これを飛ばすためのオプションが、 ssh-1.2.26 にはあり、 このオプションをつけて起動される。 このオプションは ssh-1.2.25 以前にはない。 故に、バージョン2のサーバにバージョン1のクライアントで 接続できるようにするためには、サーバ側に ssh-1.2.26 を 入れておく必要がある。

バージョン1のサーバが ssh-1.2.25 以前の場合、 バージョン1のクライアントで接続すると、次のエラーが出る。

Local: Bad packet length 1397966893.

これは、起動されたバージョン1のサーバが バージョン識別子の交換を行おうとして、 SSH-1.5-1.2.25 のようなものを送ったのを、クライアント側は、バージョン識別子交換は 終わったつもりでいるので、その後の通信で使われる バイナリパケットプロトコルのパケットだと解釈し、 先頭4バイトをパケットの長さだと解釈するために起こる。 実際、 "SSH-" の4文字を ASCII コードで表した 0x53 0x53 0x48 0x2d を、ネットワーク順 (MSB が先) の unsigned int と解釈すると、 1397966893 になる。

参考文献

T. Ylonen. The SSH (Secure Shell) Remote Login Protocol. Internet-Draft, 1995.
ssh 1.2.x の配布に含まれる "RFC" というファイル。 SSH プロトコルバージョン 1.5 を規定。
Hirotaka Yamamoto. SSH2 Quick Start. 1998
SSH2 を SSH1 と互換的に使えるように設定する方法の解説。 ssh-1.2.{24,25} についてはっきりしたことを書いていない。
SSH FAQ Section 9.4: Running SSH2 With SSH1 Compatibility
hostbase の認証ができるようにする方法が詳しく書かれている。


西村 大介 <nishi@graco.c.u-tokyo.ac.jp>
2000年11月11日(土) 19時54分20秒 最終更新