manページ  — NTP.CONF

ファイルのフォーマットは、他の Unix 設定ファイルと似ています。 コメントは、文字 ‘#’ からはじまり、行末まで続きます。 また、空行は無視されます。 設定コマンドは、先頭のキーワードと、 その後に続く引数のリストからなります。 引数にはオプションのものもあります。 各引数は空白で区切られています。 コマンドは、複数の行にまたがることはできません。 引数として、ホスト名、 ドットで 4 つの部分に区切られた形式の数値で書かれたホストアドレス、 整数、浮動小数点で表現された数値 (秒で時間を指定した場合)、 テキスト文字列があります。

このマニュアルページの残りでは、設定と制御オプションについて述べます。 "NTP の設定と NTP サブネットの設定に関する注意" のページ ( /usr/share/doc/ntp にある HTML 文書の一部として入手可能です) では、これらオプションについて更に進んだ議論があります。 一般的な 設定オプション の議論に加えて、 サポートされている機能と、その機能を制御するためのオプションについて 述べた、次のようなセクションがあります:

• 認証機能のサポート
• モニタ機能のサポート
• アクセス制御機能のサポート
• 参照クロック機能のサポート

これらのセクションの後に その他のオプション について述べたセクションもあります。 利用可能なオプションは豊富にありますが、 必要なオプションは、 server, peer, broadcast, manycastclient コマンドだけです。

auth フラグは、新しいアソシエーションまたはリモート設定コマンドが 暗号化認証を必要とするかどうかを制御します。 このフラグの有効/無効の設定は、 enable および disable 設定コマンドを使用して行なうことができます。 また、他のマシンで ntpdc(8) プログラムを動かして、リモートから設定コマンドを送り行なうことも できます。 このフラグが有効に設定されていれば (デフォルトは有効に設定されています)、 新規のブロードキャストクライアントアソシエーション、 新規の対称パッシブアソシエーション、 リモート設定コマンドは 対称鍵方式または、公開鍵方式のいずれかを用いて 暗号的に認証されなければなりません。 このフラグが無効に設定されていれば、暗号的に認証されていなくても これらの操作は有効です。 後者のモードで操作を行うと、悪者ハッカー (訳注: クラッカー) がクライアントの時刻管理処理に 重大な混乱をもたらすことが可能であるという、重大な脆弱性を招く ことは理解しておいてください。

ファイアウォールと多数のブロードキャストクライアントが存在する ネットワークでは、認証機能を無効にしておくことも許容できるかも しれません。 というのは、無効にすることで鍵の配布を行なわずにすみますし、 ネットワークの管理が単純になるからです。 しかし、設定ファイルがホスト名を含む場合、または、 サーバかクライアントがリモートから設定される場合、 DNS と、それとは別の名前解決プロセスを用いて ホスト名を解決します。 偽物のネームサーバメッセージから守るために、 内部で生成された鍵を使用して名前解決メッセージを認証しています。 この鍵は、通常、ユーザからは見えません。 しかし、暗号化機能のサポートが無効にされている場合、 この名前解決プロセスが失敗してしまいます。 この問題の解決策は、ホスト名の代わりに IP アドレスを指定する (こちらはあまりお勧めしません) か、または、 auth フラグを有効にして名前解決プロセスを行ない、 名前解決プロセスが完了してから auth フラグを無効にするかのどちらかです。

マルチキャストサポートが利用可能な場所での代替案として魅力的なもの は、メニーキャストモードです。 このモードでは、クライアントは定期的にサーバを流し釣りします。 このモードでの暗号化認証は、公開鍵方式を 以下に説明するように使用します。 このメニーキャストモードの主な利点は、クライアントはサーバを 通常の動作の間に発見するので、サーバになり得るマシンに 事前に設定する必要がないことと、クライアント全てで同じ 設定ファイルを利用できることです。

NTP 配布ソフトウェアの構築前に rsaref20 ソフトウェアをインストールしておいた場合、 デフォルトの対称鍵暗号化サポートに加えて、公開鍵暗号化のサポートも 利用可能です。 公開鍵暗号化は、正確性と安定性を犠牲にせずに、安全なサーバ認証を 提供します。 対称鍵暗号化、公開鍵暗号化両方に対するセキュリティモデルと プロトコル方式は、以下に説明します。

ntpd(8) が初めて起動すると、 ntpd は、 keys コマンドで指定した鍵ファイルを読み込み、鍵キャッシュに鍵を 設置します。 一方、鍵は使用する前に trusted コマンドでアクティブにしておくことが必要です。 これにより、例えば、いくつかの鍵の束をインストールし、 ntpdc(8) を使用して鍵の束をリモートからアクティブにしたり、非アクティブに したりできます。 また、これにより、鍵の安全性が損なわれてしまった場合に使用できる 鍵の取消機能も提供されます。 requestkey コマンドは、 ntpdc(8) ユーティリティ用にパスワードとして使用される鍵を選択します。 それに対して、 controlkey コマンドは、 ntpq(8) ユーティリティ用にパスワードとして使用される鍵を選択します。

Autokey 方式で使用する暗号化の値は、 ntp-genkeys(8) プログラムで生成するファイルの中に組み込まれています。 それらは、対称秘密鍵、公開鍵/秘密鍵の組、合意パラメータです。 これらファイルの形式の説明は、 ntp.keys(5) マニュアルページを参照してください。 これらのファイルには、 rsaref20 パッケージのアルゴリズムにより生成された暗号化の値が 印字可能な ASCII 文字の形式で含まれています。 すべてのファイル名には NTP 秒のタイムスタンプと、その後ろに デフォルトの名前とが含まれます。 これらのデフォルトの名前は以下で与えます。 ファイルデータはシステムクロックを種とする乱数値に由来しており、 ファイル名にタイムスタンプが含まれているため、 これらのファイルを生成するごとに、 異なるファイル内容とファイル名で生成されます。

ntp.keys ファイルは DES/MD5 秘密鍵を含みます。 このファイルを同じセキュリティ区画に属する他のサーバやクライアントに 配布する際には、安全な手段で配布せねばなりません。 また、このファイルは root のみが見られるようにしなければなりません。 このファイルは Autokey 方式では使用しませんが、 ntpdc(8), ntpq(8) ユーティリティが使用する いくつかのリモート設定コマンドを認証する際に必要です。 ntpkey ファイルは RSA 秘密鍵を保持します。 このファイルを生成したマシンでのみ利用できます。 他のデーモンやアプリケーションプログラムと共用することは 決してありません。 ですから、root のみが見られるようにしなければなりません。

ntp_dh ファイルは、合意パラメータを保持します。 このパラメータは対称 (アクティブ、パッシブ) モードでのみ使用します。 対称モードアソシエーションを開始する通信相手同士で同じパラメータを 共有することが必要ですが、どちらの ntp_dh ファイルから得られたパラメータかは問題になりません。 通信相手の一方がパラメータを保持する場合、他方は Autokey プロトコルを用いてそのパラメータを取得します。 通信相手が双方ともパラメータを保持している場合、双方は 最も新しいコピーを使用します。 通信相手がパラメータを持っていない場合、 設定されたアソシエーションまたは未設定のアソシエーション のいずれかについて、 全てのアソシエーションがパラメータを要求します。 しかし、どちらかの通信相手がパラメータを受信するまでは、 アソシエーションの処理を進めることはできません。 一度ロードされると、パラメータは要求に応じて他のクライアントや サーバに提供することができます。 ntp_dh ファイルのデータは公開値なので、このファイルは 安全でない手段を用いて配布することもできます。

ntpkey_host ファイルは RSA 公開鍵を含みます。 ここで、 host はホストの名前です。 ホストはそれぞれ自分自身の ntpkey_host ファイルを持っています。 通常、このファイルは、Autokey プロトコルを用い他のホストに提供されます。 server アソシエーション、または、 peer アソシエーションは、特定のサーバまたは通信相手に関連した 公開鍵を要求します。 この公開鍵は、ローカルファイルから直接ロードされるか、 Autokey プロトコルを用いてサーバから間接的にロードされます。 これらのファイルのデータは公開値であるため、 これらのファイルは安全でない手段を用いて幅広く配布/保管することが できます。

ntpkey_certif_host ファイルはオプションで、そのホストに対する PKI 証明データを含みます。 これはホスト名と RSA 公開鍵の結び付きを提供します。 現在の実装では、この証明データが存在すれば、クライアントはそれを 取得しますが、その内容は無視されます。

インタフェースごとの名前付けが幅広く使用されているため、 設定され行使中のアソシエーションで使用されるホスト名は、 Unix の gethostname(3) ライブラリ関数を使って決定されます。 ntp-genkeys(8) プログラムと Autokey プロトコルは、ともにこのルーチンが返す名前を 用いて公開鍵ファイルの名前を派生させます。 どのサーバもクライアントも固有の公開鍵と秘密鍵をロードする必要が ありますが、それぞれのクライアントアソシエーションまたは通信相手 アソシエーションに対する公開鍵は、Autokey プロトコルを用いて サーバまたは通信相手から取得することができます。 しかし、現在の開発段階では、 サーバまたは通信相手の認証の確実性と サーバ名、アドレス、公開鍵の暗号との結合は、 認証局 (certificate authority) や 信用の輪 (web of trust) により確立されたところにまで達していません。

推奨するやり方は、 ファイルをインストールした時のタイムスタンプ拡張子を保持し、 (タイムスタンプ拡張子のない) デフォルト名から実ファイルへの リンクを作ることです。 これにより、新規ファイルの生成をリンクを張り変えることで有効に できます。 しかし、 ntpd(8) は、拡張値を取り出す瞬間にリンク名を解釈し、要求された時点で 公開鍵とホスト名とともにリンク名を送付します。 これにより、クライアントはファイルと生成時刻が常に現在であると 検証することができます。 しかし、各ファイルの実際の場所は crypto 設定コマンドにより上書きされる可能性があります。

暗号化鍵と関連パラメータ全ては、例えば、1ヶ月に1回ぐらいの頻度で 定期的かつ自動的に再生成する必要があります。 ntp-genkeys(8) プログラムは、一度に生成するファイル全てに対し 同じタイムスタンプ拡張子を使います。 ですから、ファイル生成のそれぞれは区別され、データ監視の際に ファイル生成を認識できます。 公開鍵/秘密鍵の組は全てのサーバとクライアントにより 生成されねばなりませんが、公開鍵と合意パラメータを、 同じセキュリティ区画内の全てのマシンに対しわざわざ コピーする必要はありません。 これらは、Autokey プロトコルを使い自動的に取得できるからです。 しかし、プライマリサーバの全ては同じ合意パラメータファイルを持つ 必要があります。 これを達成するために推奨する方法は、プライマリサーバの 1 つに そのファイルを生成させ、その後で、同じセキュリティ区画内の 他のプライマリサーバに対し Unix rdist(1) コマンドを用いてコピーすることです。 Autokey プロトコルの将来のバージョンでは、合意プロトコルが この処理を自動的に行なう機能の提供を含むことになります。

サーバとクライアントは新規のファイル世代の生成を 次のように行なうことができます。 全てのマシンは起動時に古いファイル世代をロードしており、 正常に動作しています。 指定した間隔で、各マシンは新規の公開鍵/秘密鍵の組を生成し、 デフォルトファイル名から新規ファイル名へのリンクを作成します。 その後で、 ntpd(8) は再起動され、新規の生成をロードします。 その結果、クライアントはもはや認証を正しく行なうことが できなくなります。 Autokey プロトコルがそう設計されているので、 数分後にクライアントはタイムアウトし、 プロトコルを最初から開始します。 その結果新規の世代をロードし、以前通り動作を続けることが できるようになっています。 同様の手続きが合意パラメータファイルに対しても使用できます。 しかし、この場合、このファイルを持つすべてのマシンが同じコピーを 持つように十分用心しておく必要があります。

アクセス制限機能は、オリジナルの NSFnet バックボーン タイムサーバに対するアクセスポリシと一致するように実装されました。 この機能は、望まないものや落ちてしまったリモートのタイムサーバが 自分のタイムサーバに影響を与えないようにするには有効かも しれませんが、この機能を、標準の NTP 認証機能の代用になると 考えるべきではありません。 送り元アドレスに基づいた制限というのは、やる気十分のクラッカー には簡単に回避されてしまいます。

設定の観点から見ると、 ntpd(8) は、参照クロックを、普通の NTP の交信相手にするのとできる限り同じような方法で扱います。 参照クロックは、通常の NTP 通信相手と区別するため、 文法的には正しいが、無効な IP アドレスを使って認識されます。 参照クロックのアドレスは、 127.127. t . uの形式です。 ここで、 t は時計の種類を示した整数で、 u はユニット番号 (範囲は 0-3) を示しています。 これは、過剰に見えるかもしれませんが、 実のところ、同種類の参照クロックを複数設定するのには時として 便利です。 この場合、ユニット番号は一意のものであることが必要です。

server コマンドを使用して参照クロックを設定します。 ここで、このコマンドの address 引数は参照クロックのアドレスです。 key, version, ttl オプションは、参照クロックのサポートでは使用しません。 参照クロックをサポートするために、 mode オプションが追加されています。 このオプションについては後で述べます。 prefer オプションは、サーバに、他の参照クロックや通信相手よりも いくらか熱心に、ある参照クロックを大切に扱わせるように促すのに 有効です。 このオプションに関してのさらなる情報については、 "緩和ルールと prefer キーワード" のページにあります。 minpoll と maxpoll オプションは、選択されたクロックドライバに 対してのみ意味があります。 さらなる情報については、別個のクロックドライバのドキュメントページを 参照してください。

fudge コマンドは、クロックドライバ固有の追加情報を提供するのに使用します。 通常は、 server コマンドの直後に使用されます。 address 引数はクロックのアドレスを指定します。 refid と stratum は、そのデバイスのデフォルト値を上書きするために使用することが できます。 2 個のオプションのデバイス依存の時刻オフセットと 4 個のフラグがあり、 それらも同様に fudge コマンドに含めることが可能です。

参照クロックの階層 (stratum) 番号は、デフォルトで 0 です。 ntpd(8) デーモンは各通信相手の階層に 1 を足すので、 プライマリサーバは、通常、外部階層 1 を示します。 バックアップを巧みに運用するため、 参照クロックの階層を 0 より大きい数に指定するのが有益な ことが多いです。 この目的のために、 stratum オプションを使用します。 参照クロックと、1 秒間隔パルス (PPS) 調整信号の両方を 含む場合、参照クロック識別子をデフォルト値以外の、ドライバに 依存したものに指定するのが有効です。 この目的のために、 refid オプションを使用します。 記述がない限り、これらのオプションは、すべての時計 ドライバに適用されます。

提供されているマニュアルページに加えて、理解しやすいドキュメントが world wide web 上で入手可能です。 http://www.ntp.org/ から入手できます。 このドキュメントのスナップショットが HTML フォーマットで /usr/share/doc/ntp ディレクトリ内にあります。

David L. Mills, RFC1305, Network Time Protocol (Version 3),