c:\autoexec.batに
- set TERATERM_EXTENSIONS=1
「コントロールパネル」→「システム」→ 「環境」 の 「ユーザのユーザ環境変数（U）」に
- 変数（V）：TERATERM_EXTENSIONS
値（L）：１
図 19 WindowsNT4.0 での環境変数の設定例
Windows用およびMacintosh用には SSHクライアントが, UNIX系用には SSHサーバおよびクライアントがある. ここでは Windows 系および UNIX系のインストールについて説明する. Macintosh用クライアントについては, Webページ[n2]を参照のこと.
フリーのクライアントの場合には, TeraTerm(Pro)に SSH 用のモジュールTTSSHを付加して利用するのが一般的である. この方法を説明する.
SSHの認証に公開鍵暗号方式を利用する場合には, 更にコマンドラインツールをインストールする.
SSH2クライアントを入手してインストールする場合には, 添付のドキュメントを参照してインストールする. なお, SSH2クライアントの場合には SSH2サーバとしか通信できない.
Tera Term Pro本体と, そのSSHモジュールの2つのソフトウエアを入手する.
Tera Term Proのアーカイブ（ttermp23.zip）を任意のフォルダに展開し, Setupを実行してTera Term Proのインストールを行なう.
次にTTSSHのアーカイブ(ttssh14.zip)を, Tera Termをインストールしたフォルダ（デフォルトのままであればc:\Program files\ttermpro）に展開する. それぞれのアーカイブはzip形式で圧縮してあるので, winzipやlhasa等を使用して展開する.
展開した後に, Tera Termの起動時にTTSSHの機能が有効になるように, TERATERM_EXTENSIONS変数を‘１’に設定する.
c:\autoexec.batに
「コントロールパネル」→「システム」→ 「環境」 の 「ユーザのユーザ環境変数（U）」に
図 19 WindowsNT4.0 での環境変数の設定例
TTSSH で公開鍵認証を使用する場合には, コマンドラインモードのSSH クライアントの中にあるツールを使って鍵を作成する.
ftp://ftp.cs.hut.fi/pub/ssh/contrib/ (注 : この URL に接続不可, 2003/10/31) からssh-1.2.14-win32bin.zipを入手し, これを任意のフォルダに展開する. ssh-keygen.exeとgmp.dllが存在するのを確認する.
DOS コマンドプロンプトのウィンドウを開き, そこで作業する.
環境変数の HOME を設定する. 設定した値の場所に鍵が作成される. 例えば \users\myhome とすると
set HOME \users\myhome
鍵を作成する. オプションにホスト名(luneとする)を指定する*27.
ssh-keygen -C lune
Enter file in which to save the key ($HOME/.ssh/identity): と, 鍵を作成する場所を聞いてくるので, そのままで良いので Enter キーを押す.
Enter passphrase: と入力を要求してくる. これは鍵に付けるパスワードである. スペース文字を使えるので, 自分で覚えやすく, 他人に推測されにくい文章となるような文字列を選んで入力する*28. 例えばthis is my passphrase とする.
確認のためにもう1度, Enter the same passphrase again: と入力の要求があるので, 同じ文字列を入力する.
最後に以下の表示で作成できたことが示される.
作成された, 1組の鍵のうち公開鍵(identity.pub)をリモートホストに送り, エディタなどで $HOME/.ssh/authorized_keys に登録する *29 *30.
UNIX系マシンへのインストレーションでは, フリーの1.2.xxの系統のバージョンを入手してインストールする場合と, SSH2をインストールする場合の２つの選択がある.
フリーの最新バージョン 1.2.27, および商用版2.0.13で試した結果をのべる.
インストールする場所, アクセス制限の方法, 有効にする認証方式や暗号化方式などが設定できる. 多くのオプションは標準値のままで良いが, 双方向クラスのホストにインストールする場合には, SSHを悪用されないように, アクセス制限を設定する必要がある.
SSH に関するアクセス制限には, SSHでのアクセスを許すホストの制限, X11 フォワーディングの可否, ポートフォワーディングの可否が設定できる. 制限する方法は, make 時に機能を無効にする方法, TCP wrappers [n3] のアクセス制限を利用する方法, SSH のコンフィギュレーションファイルに記述して行なう方法がある. 制限する方法とそれによる制限内容を 表 5 に示す. ポートフォワーディング機能を利用可能にするのであれば, ホスト単位に制限が行なえる TCP wrappers を利用する方法を選択して, 自ホスト内でのポートフォワーディングを許すよう設定にする.
表 5 アクセス制限方法と可能な制限
| TCP wrappers | コンフィギュレーションファイル | make 時 | |
| SSHアクセスの制限 | ホスト単位 | ホスト単位 | (なし) |
| X11 フォワーディングの可否 | ホスト単位 | 可否のみ | 可否のみ |
| ポートフォワーディング可否 | ホスト単位 | (なし) | 可否のみ |
ソースを入手して, “tar.gz” を展開する. ファイル INSTALLにインストールの方法が記述してあるので, その記述にしたがって操作する. サーバおよびクライアントがインストールできる.
TCP wrappers の library がインストールされている場合には, サーバにおいて TCP wrappers のアクセス制限が利用できる. 利用する場合には,以下のファイルを作成してあることを確認する. 未作成の場合には複写する*31.
configure を以下のように指定する.
続いて “make”, “make install” を行なう.
最後に, TCP wrappers の hosts.allow に SSH の記述を追加する.
商品に添付されているREADMEなどの文書を参照してインストールする. サーバおよびクライアントがインストールできる.
TCP wrappers の library がインストールされている場合には, サーバにおいて TCP wrappers のアクセスコントロールが利用できる. 利用する場合には, 以下のファイルのあることを確認する. 未作成の場合には複写する.
configure を以下のように指定する. ここではデバッグのためのオプションも合わせて指定しておくことにする.
続いて “make”, “make install” を行なう.
SSH2 では SSH1 との互換モードが設定できる. まず, SSH1 をインストールしてから, SSH2 をインストールする.
インストール後に, 以下の設定を行なう.
/etc/ssh2/sshd2_config に以下のパラメータを追加する
/etc/ssh2/ssh2_config に以下のパラメータを追加する
最後に, TCP wrappers の hosts.allow に SSH の記述を追加する.
SSHの環境は, 設定ファイル /etc/ssh*_config (SSH1) あるいは /etc/ssh2/ssh*2_config (SSH2) に設定する. 認証方式, 暗号方式などを設定できる. 通常は初期値で問題ないが, 一応確認すること.
なお, バージョンアップ時には, 古い環境設定ファイルがそのままになっている. 新しい環境設定ファイル*32を確認して, 必要なら入れ替える.
セキュリティを向上させるためには, サーバに対するアクセス制御を行なった方が良い. TCP wrappers library をリンクした場合には, TCP wrappers の設定ファイルにアクセス制御を記述する.
以下に設定例を示す. 3行目がsshdについてのアクセス制限で, 4行目がX11のフォワーディングを行なうための記述である*33. 5行目が自ホストでフォワーディングを許すポートの番号である. Hostnameは自ホスト名である. この例では12345番ポートの使用だけを許している. 詳細は ”man sshd” を参照のこと.
SSH1 では, /etc/sshd_config の中に AllowHosts および DenyHosts を記述することもできる. 書き方は ”man sshd” を参照のこと.
SSH のログには, 接続を要求したクライアントの IP アドレス, 日時, ユーザ認証の方法が記録される. ポートフォワーディングのホスト名と日時も記録される.
SSHによるアクセスの監視を容易にするためには, ログの出力先を固有のファイルにすると良い. この方法を説明する.
以上の準備の終了後, sshd と syslogd のプロセスを再起動させると, 新しいファイルにログが出力されるようになる.
SSHはインストレーションが簡単であり, 使い方も簡単である. telnet, rlogin, rsh, rcpを利用しているユーザが容易に移行でき, セキュリティを格段に高めることができる. SSHを利用するためには, クライアントとサーバの双方に SSH が導入されている必要があるので, 広く普及することが今後の課題である. セキュリティ対策の重要性がますます認識されている中で今後の普及が期待できる.
一方でSSHを利用しながら, 従来の telnet, ftp, xdm などをそのまま使い続けていたのでは, 依然としてパスワードがネットワークに流れることになる. ユーザとしては, 従来の telnetなどを使用しないようにすること, ホストの管理者としては従来の機能の運用を停止あるいは最小に限定することが必要である.
| ||||||
| ||||||
|
図 20 SSHと telnet を混在させた利用
何段にもリモートログインを重ねる場合には, SSH を使えるログインと, 使えないために telnet を使わざるをえない部分ができることもある. SSH とtelnet を組み合わせて使用する場合 (図 20) には, telnet の部分では通信が暗号化されないので, SSHの通信部分で暗号化されるデータがtelnet の通信部分で非暗号化データとして通信される.
やむを得ずに組み合わせて使う場合には, 通信経路とその安全度を評価した上で使わないと, SSH を使用する努力が無意味なものとなる. 例えば大学から KEK へのログインを telnet で行ない, KEK内ではSSHでログインするのは, より信頼性の低いネットワークの部分で telnet を使うことになり, その結果 SSH で使うパスワードが盗聴されることにもなりかねないので, 行なうべきでない. このような場合には, 自分の端末 (PCなど) に SSH を入れる努力をすべきである.
KEK内で自分の端末から他のホストに telnet でログインして, そのホストから SSH で他大学や外国にログインするような例は, telnet で通信を行なう部分のネットワークが信頼できるものであれば, 好ましいことではないが, 許容範囲である. X 端末を使っている場合には, この方法をとることになる.
UNIXでは, 通常は Xウインドウシステムを使って作業をするが, Xサーバにリモートホストのクライアントを表示するために xhost でアクセスの許可を行なうことが多い.
このホストの全ユーザにXサーバへのアクセスを許す設定を, より安全にするためにxauth を使うように各ユーザがXの設定を変更することが望ましい.
更に, すべてのリモートアクセスにSSHを使うようにすれば, 5.1.2節で説明したように認証のためのデータを暗号化して送るので非常に安全になる.
SSH の検討に関して本機構のセキュリティワーキンググループの方々に感謝致します. 特に原稿をチェックして貴重なコメントをくださった馬渡博司助教授, 柴田章博助手, 湯浅富久子助手に感謝致します. SSH の導入に協力をしてくださった中村貞次技官に感謝致します.
