OpenSSH セキュリティ管理ガイド / 補遺

サポートページに戻る

項目一覧

1. 設定ファイルのパスに関する注意
2. 「秘密鍵ファイル」の呼称に関する注意
3. 商用 SSH2 の鍵の変換について
4. CompressionLevel 項目は SSH 1 プロトコルでのみ有効
5. inetd、tcpserver から sshd を起動する
6. 圧縮および圧縮レベルの設定の目安
7. sshd によって自動的に設定される環境変数
8. OpenSSH 3.0(2.9.9) における変更点

1. 設定ファイルのパスに関する注意

本書の冒頭にも書かれていますが、 本書では設定ファイルのパス名を表示する際に [/usr/local]/etc のように表示しています。しかし、システムやパッケージに よってはこれ以外のパス名に ssh や sshd の 設定ファイルが置かれることもありますので、お使いのシステムなどに 付属しているドキュメントを読み、適切なパス名を使用してください。

RPM、debでは、 OpenSSH のパッケージに 含まれる ssh および sshd の設定ファイルは /etc/ssh に置かれるようです。

NetBSD 1.5 では、sshd_config ファイルは /etc/sshd.conf になっています pkgsrc を使ってインストールした場合は /usr/pkg/etc に 置かれます。

FreeBSD 4.x では、標準のOpenSSHの場合は設定ファイルが/etc/ssh/以下に置かれます。ただし、portsでインストールしなおすと/usr/local/etc/に置かれます。portでインストールされるOpenSSHの実行形式は/usr/local/[s]bin/の下になります。(非常時研木本さんからの情報)

項目一覧へ

2. 「秘密鍵ファイル」の呼称に関する注意

本書ではユーザが公開鍵認証に使うためのファイル ~/.ssh/identity (SSH2 では ~/.ssh/id_dsa など) を 「秘密鍵ファイル」と呼んでいますが、実際には このファイルは公開鍵認証に使う秘密鍵と公開鍵両方の情報を 含んでいます。いっぽう公開鍵ファイル ~/.ssh/identity.pub (SSH2 では ~/.ssh/id_dsal.pub など) は 公開鍵の情報だけを含んでいます。

そのため、万が一 公開鍵ファイルを紛失してしまった場合でも、 ssh-keygen コマンドを使って、

% ssh-keygen -y -f 秘密鍵ファイル

のようにすれば、標準出力から公開鍵ファイルを得ることができます。

秘密鍵ファイルを他人に渡してはいけないことに変わりはありません。

項目一覧へ

3. 商用 SSH2 の鍵の変換について

商用 SSH2 と OpenSSH との相互運用についての説明 (171 ページ) に不十分な箇所がありました。商用 SSH2 の ssh-keygen を使って空のパスフレーズを指定する 必要があるのは、商用 SSH2 の「秘密鍵」を OpenSSH 用の秘密鍵に 変換するときだけです。この操作はそれまで商用 SSH2 クライアントで 使っていた秘密鍵を、OpenSSH クライアントでも使いたいときにおこないます。 商用 SSH2 クライアントから OpenSSH サーバにログインするさいには 商用 SSH2 の「公開鍵」をサーバ上に置くだけでよく、秘密鍵の パスフレーズを変更する必要はありません。 また、商用 SSH2 のホスト鍵を OpenSSH のホスト鍵に変換することによって、 商用 SSH2 サーバから OpenSSH サーバへ移行することも可能です。

まとめると、以下のようになります。

注意: ssh-keygen -e でできるのは、 OpenSSH の公開鍵を商用 SSH2 の公開鍵に変換することだけです。 秘密鍵を変換することはできません。 また、ssh-keygen -e に与える鍵ファイルは、OpenSSH の 公開鍵あるいは秘密鍵のどちらでも指定できますが、ssh-keygen は まず公開鍵ファイル (指定された鍵のファイル名そのもの、あるいは それに .pub をつけたファイル名) を探し、その内容を変換します。 公開鍵ファイルが見つからない場合は秘密鍵ファイルから公開鍵の部分を とり出して変換しますが、その場合はパスフレーズの入力が必要です。

項目一覧へ

4. CompressionLevel 項目は SSH 1 プロトコルでのみ有効

ssh クライアントの設定ファイルで、圧縮レベルを指定する CompressionLevel 項目は SSH 1 プロトコルでのみ有効です。 本では明記していませんでしたのでご注意ください。

項目一覧へ

5. inetd、tcpserver から sshd を起動する

sshd の起動方法に関して、4.4.3項 「inetd、tcpserver から起動する」(203 ページ) に inetd 経由で sshd を起動する方法が書かれていませんでした。 また tcpserver からの起動に関しても、一部誤った記述がありました。

inetd からの起動

inetd (あるいは inetd + tcp_wrappers) を経由して sshd を起動する場合、sshd に -i オプションをつける必要があります。そのため、 /etc/inetd.conf に次の行を追加します:

ssh     stream  tcp     nowait  root    /usr/local/sbin/sshd  sshd -i

sshd が /usr/sbin/sshdなどにインストールされている 場合は、「/usr/local/sbin/sshd」の部分を適宜置き換えてください。

また、tcp_wrappers 経由で sshd を起動する場合は /etc/inetd.conf を以下のようにします:

ssh     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/local/sbin/sshd -i

OS の種類によっては、 /etc/services などに ssh プロトコルのエントリが書かれていない場合もあります。このような場合は、 /etc/services に次の一行を追加してください:

ssh     22/tcp

この後 inetd を再起動するか、SIGHUP シグナルを 送れば設定が反映されます。

注意 : inetd から sshd を起動する場合、 sshd は毎回の接続ごとに新規に起動されることになります。 そのため、[/usr/local]/etc/sshd_config ファイルの 設定は接続ごとに毎回読み込まれますので、sshd_config ファイルの 変更はすぐにその次の接続から反映されます。 また sshd は起動時にサーバ鍵を生成するので、 接続があるたびに毎回サーバ鍵が生成され、この結果ログインまでに 多少の時間がかかるようになります。

inetd は特定のサービスへの接続が集中すると 一定時間そのサービスへのアクセスを止める場合があります。また sshd単体で起動したときとは異なり、inetd では 負荷の制御ができないため、ssh への接続が多い環境では inetd の利用はおすすめしません。

tcpserver からの起動

tcpserver を経由して sshd を起動する場合の 記述に一部誤りがありました。

daemontools と tcpserver を 併用する場合、まず sshd のログを記録する専用の ユーザを作成してください。つぎに /service/sshd/run ファイルと /service/sshd/log/run ファイルを作成します (204 ページでは、以下の 2つのファイルの内容が ひとつの囲みの中に表されています)。

/service/sshd/run の例 :

#!/bin/sh
exec 2>&1
exec env - PATH=$PATH tcpserver -v 0 ssh /usr/local/sbin/sshd -i -e

/service/sshd/log/run の例 : (ユーザ sshdlog を使用する場合)

#!/bin/sh

exec setuidgid sshdlog multilog t ./main

(204 ページの囲みでは、setuidgid の後に ユーザ名を表す引数が抜け落ちています)

sshd が /usr/sbin/sshd などにインストールされている 場合は、「/usr/local/sbin/sshd」の部分を適宜置き換えてください。

すでに svscan が走っている場合は、 以下のような手順で作業すると sshd のサービスを安全に開始できます (daemontools の使い方に関しては、daemontools FAQ をお読みください)。

1. # cd /service
2. # mkdir .sshd
   (まず「.」で始まるファイルを作る。 svscan は . で始まるファイルを無視するので、 supervise は起動しない)
3. # mkdir .sshd/log
   (ログ用のディレクトリ log を作る)
4. # chown sshdlog .sshd/log
   (ディレクトリ log の所有者を、ユーザ sshdlog に変更する。これによって sshdlog 権限で動く multilog がこのディレクトリ中に ログファイルを作成できるようになる)
5. # chmod +t .sshd
   (ディレクトリ .sshd の sticky bit を立てることにより、 svscan がログ用ディレクトリの存在を検出できるように する)
6. # cd .sshd
7. # vi run
   (/service/sshd/run ファイルを作る)
8. # chmod 755 run
9. # ./run
SSH-1.99-OpenSSH_2.9p1
^C
   (/service/sshd/run ファイルが 正しく sshd を起動できるかどうか試験し、 Control-C で止める)
10. # cd log
11. # vi run
    (/service/sshd/log/run ファイルを作る)
12. # chmod 755 run
13. # ./run
^D
    (/service/sshd/log/run ファイルが 正しく multilog を起動できるかどうか試験し、 Control-D で終了させる)
14. # ls
main run
    (main というディレクトリができていることを確認する)
15. # cd /service
16. # mv .sshd sshd
    (名前を変更して svscan にディレクトリの存在を気づかせる)
17. # svstat /service/sshd /service/sshd/log
/service/sshd: up (pid 1203) 3 seconds
/service/sshd/log: up (pid 1205) 3 seconds
    (svstat を実行して秒数が増えていることを確認)

項目一覧へ

6. 圧縮および圧縮レベルの設定の目安

OpenSSH では、遅いネットワーク環境でのデータ転送速度を上げるために データを圧縮しながら転送することができます。本書 156ページには 「圧縮を行うかどうかの目安は 4-?. 節を参照してください」と 書かれていますが、実際には本書に目安は書かれていませんでした。

以下は著者の環境において、さまざまな回線速度および圧縮レベルで scp を利用したときのデータ転送速度を測定したものです (scp はデータの転送に ssh を使っているため、 結果的には ssh の速度を測定していることになります)。 「無圧縮」と書かれているのは圧縮を使用しなかった場合の転送速度で、 「レベル1」「レベル6」「レベル9」と書かれているのは、ssh コマンドの CompressionLevel 設定項目の値として それぞれ 1、6 (デフォルト)、9 を与えた場合の見かけの転送速度です (ここでいう「見かけの転送速度」とは、TCP の転送にかかる時間に加えて SSH の暗号化や復号化、および圧縮と展開にかかる時間も含めた 転送速度をさします。なお SSH のセッション開始にかかる時間は除いて あります) :

一般に CompressionLevel を上げると転送するデータ量は 少なくなりますが、 そのぶんデータ圧縮にかかる計算も多くなるのでデータ転送全体の 速度はかえって低下する場合もあります。 上に示した結果から、遅い回線を 使った場合ほど CompressionLevel の効果が大きいことがわかります。 また 100Base-T 相当の高速回線を使った場合でも、圧縮レベル 1 程度の 圧縮ならばファイルによっては転送速度を稼げるようです (暗号化アルゴリズムに 3DES を使った場合)。 ただしモデムを介した接続の場合はモデム自身が圧縮をおこなうため、 SSH による圧縮はかえって転送速度を下げる場合があります。

今回はファイルを 2種類 (圧縮率の高いファイルと 低いファイル) に分けて測定をおこなっています。 回線速度が低い場合、圧縮率があまり高くないファイルでは、 圧縮レベルを上げることは逆効果になる場合もあります (上の表で、暗号化アルゴリズムに Blowfish を使った場合など)。 またデータ圧縮はある程度の計算コストを必要としますので、 SSH の利用が多いサーバで複数の接続が圧縮を利用していると 計算機の負荷が高くなり、かえって時間がかってしまうこともあります。 したがって最適な圧縮レベルを決定するには回線速度だけでなく、 転送するデータの種類、計算機の能力、サーバの利用状況なども 考慮する必要があります。

(データ転送速度の測定について)

データ転送速度の測定は、 以下の表に示すファイルを scp でコピーすることによって おこないました。ネットワークの流量が少ない時間帯に同じ測定を 5回くり返し、その平均時間から転送速度を求めました。 SSH のセッションを開始するまでにかかった時間は 空のファイルをコピーするのに要する時間であると仮定しています。 なお、実際の測定はすべて 100Base-T Ethernet 上のホスト間 (それぞれ Pentium III, 500MHz および Alpha, 600MHz を使用) で 行っており、TCP転送速度の変更はソフトウエア的にトラフィックを 制限することにより実現しています。

項目一覧へ

7. sshd によって自動的に設定される環境変数

ユーザがリモートホストにログインした場合、 sshd は以下の優先順位でそのプロセスの 環境変数を設定します:

1. ~/.ssh/authorized_keys (あるいは authorized_keys2) ファイル中の environment 項目で指定されている環境変数
2. 標準的な UNIX 環境のために sshd が自動的に設定する環境変数
3. ~/.ssh/environment ファイルに書かれている環境変数

ここで、2. の「標準的な UNIX 環境のために sshd が自動的に設定する環境変数」の内容は 以下のようになっています:

項目一覧へ

8. OpenSSH 3.0(2.9.9) における変更点

OpenSSH 3.0(2.9.9) では以下のような変更がなされました。

• ~/.ssh/authorized_keys2 ファイルが ~/.ssh/authorized_keys ファイルに統合されました。 従来の OpenSSH では使用するプロトコルのバージョンによって、 公開鍵を ~/.ssh/authorized_keys と ~/.ssh/authorized_keys2 とに分けて格納する必要がありましたが、 OpenSSH 3.0(2.9.9) からはプロトコル バージョン 2 を使う際にも authorized_keys に公開鍵を追加すればよいことになります。 ただし互換性を保つため、~/.ssh/authorized_keys2 ファイルも 検査されるようになっています。
• 同様に、~/.ssh/known_hosts2 ファイルも ~/.ssh/known_hosts ファイルに統合されました。 ただし互換性を保つため、~/.ssh/known_hosts2 ファイルも 検査されるようになっています。
• スマートカードがサポートされました。 スマートカードには秘密鍵および公開鍵を格納することができ、 認証のさいに使用することができます。ただし README.smartcard によるとこの機能はまだ開発段階にあり、 今のところサポートしているカードは Cyberflex のものだけです。 また、鍵ファイルの形式などは今後変わる可能性があるとのことです。

項目一覧へ

サポートページに戻る

$Id: addendum.html,v 1.8 2002/04/23 15:17:49 euske Exp $