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

第 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/ を参照。

(秘密かぎと公開かぎ)


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

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

| home | up |

sengoku@gcd.org