実践で学ぶ、一歩進んだサーバ構築・運用術

第 9 回 ssh (前編)

ssh（セキュア・シェル）

ssh とは， 「Secure SHell（セキュア・シェル）」の略で， rsh（リモート・シェル）のセキュア版です。 rsh と同様， リモート・ホスト上で任意のコマンドを実行することができます。 rsh の関連コマンドに， リモート・ホストへログインするための rlogin（リモート・ログイン）コマンド， ホスト間でファイルをコピーする rcp（リモート・コピー）コマンドがありますが， ssh にもそれぞれ対応するコマンドとして， slogin（セキュア・ログイン）コマンド， scp（セキュア・コピー）コマンドがあります。

rsh/rlogin/rcp コマンドには， 本連載の 7 回目「ファイアウォール（前編）」で解説したように， 送信元アドレスだけの認証なので， IP アドレス・スプーフィングによって比較的容易に侵入される恐れがあります。

ssh/slogin/scp コマンドは， RSA 暗号に基づいた認証方法を用いているので， 通常の運用においては， 秘密かぎが奪われない限り安全と見なすことができます＊6。 また， 送受信するデータはすべて暗号化されるので盗聴される危険もありません。

ssh/slogin/scp コマンドは， rsh/rlogin/rcp コマンドと互換であり， 完全に置き換えてしまうことができます。 つまり ssh を /usr/bin/rsh としてインストールできます。 サーバー側の置き換えも簡単で， まず /etc/inetd.conf において， 図 1 の行をコメントアウトします。 次に inetd ＊7 に HUP シグナルを送って inetd.conf の再読み込みを行わせて， in.rshd と in.rlogind が動かないようにした後， ssh サーバーである sshd を実行するだけです。 /etc/rc.d/rc.local などに， 図 2 のように書いておいて， 起動時に sshd が自動的に立ち上がるようにしておくと良いでしょう。

shell   stream   tcp   nowait   root   /usr/sbin/tcpd   in.rshd
login   stream   tcp   nowait   root   /usr/sbin/tcpd   in.rlogind
図 1 rsh の代わりに ssh を使用する場合は /etc/inetd.conf のこの行をコメントアウトする

# ssh
if [ -x /usr/sbin/sshd ]
then   /usr/sbin/sshd
fi
図 2 /etc/rc.d/rc.local にこのように記述すると 起動時に sshd が立ち上がる

ssh の実装には， OpenBSD プロジェクトによる OpenSSH ＊8 や， SSH Communications Security ＊9 による SSH Secure Shell などがあります。 Windows や Macintosh， さらには Palm，BeOS，Java 上の実装もあるようです。 ここでは OpenSSH を中心に解説しますが， 他の実装でも基本は同じです。 もちろんプロトコル・レベルでは， どの実装も互換ですから， 異なる実装間での通信は問題なく， 可能です。

ssh は rsh に比べれば暗号化/復号化処理が必要な分遅いのですが， 最近のマシンは十分すぎるほど速いので， LAN 上で高速転送を何度も行う＊10 必要があるのでも無い限り， 遅さが全く気にならないと言っても過言ではないでしょう。

盗聴の多くが LAN 上で行われる＊11 ことを考えれば， LAN 内に閉じた通信であっても， rsh, rlogin や telnet よりは ssh を使うべきだと思います。

幸い， Windows 上にも使いやすい ssh クライアントがあります。 私が愛用しているのはターミナル・エミュレータ， TeraTerm Pro ＊12 に ssh のための拡張モジュール TTSSH を追加したバージョンです。

実行すると写真 1 のようにログイン先ホストやログイン方法 （ssh のほか，telnet することもできる）を選べます。 「OK」ボタンを押すと， 写真 2 の画面になり， ここで「Passphrase:」の部分にパスフレーズを入力するとログインできます。

ログイン先ホストやログイン方法を選択できる
写真 1 ログイン先ホストやログイン方法を選択できる

「Passphrase:」の部分にパスフレーズを入力するとログインできる
写真 2 「Passphrase:」の部分にパスフレーズを入力するとログインできる

つまり普通の telnet クライアントと同程度の手間でログインできるわけです。 盗聴される危険がある telnet クライアントをわざわざ使う必要性は全くありません。

＊6
もちろん ssh サーバーにセキュリティ・ホールが発見された場合は， その限りではありません。 ssh のバージョンアップ情報には常に目を通す必要があります。
＊7
inetd が面倒を見るサービスのほとんどは今となっては使われないものばかりで， なぜ多くのディストリビューションがいまだに inetd をデフォルトで走らせているのか理解に苦しみます。 inetd は前世紀の遺物ですからさっさと捨てるべきです。
＊8
http://www.openssh.com/ を参照。
＊9
http://www.ssh.fi/ を参照。
＊10
私は 2 台のマシン間でディスクを丸ごとコピーする （G バイト単位の転送になります）ときでさえ， ssh を使っています。 盗聴を防ぐためというよりは， セキュアでない通信方法を一掃してしまったので， 今さら暗号化しないコピーを行うのが面倒なためです。
＊11
サイト間通信の場合， 大抵は一次プロバイダ（つまりそれなりに信頼できる企業） の設備のみを経由して通信が行われますから， 盗聴の危険はインターネット上でなく， むしろ両サイトの LAN 上の方が高いと言えます。 この意味で， インターネット区間のみを暗号化する VPN 方式はナンセンスです。
＊12
http://hp.vector.co.jp/authors/VA002416/ を参照。

(秘密かぎと公開かぎ)

本稿は日経Linux 2000 年 12 月号に掲載された、 実践で学ぶ、一歩進んだサーバ構築・運用術, 第 9 回「ssh (前編)」を日経BP 社の許可を得て転載したものです。

Copyright(C)2000 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます

| home | up |

sengoku@gcd.org