[Enterprise のみ]
目次 表示
Secure Shell は、リモートホストへの暗号化したターミナルアクセスを提供し、ユーザにリモートホスト上でのコマンド実行を可能にし、その結果暗号化セッションを使えるようにします。要約すると、このことはあるホスト上のユーザは SSH を使って、コマンドと応答データがセキュアな通信チャネルで交換される付加的利点をもちつつ、あたかもローカルで実行するのと同じ基本方式で他のホスト上でコマンドを実行することができます。
さらに、Nagios はデータ収集に軽量なコマンドと応答インタフェースを使うため、Nagios は同様に簡単に同様の利点で、リモートコマンドと応答データを処理するのに SSH 技術を使うことができます。
具体的には、Nagios はさまざまなサービスプロファイルを構築するのに使用できる、GroundWork Monitor 内の SSH プラグイン・インタフェースを提供します。この設定では管理者は、リモートホスト上で実行する必要があるコマンドを記述したひとつ以上のプロファイルと、リモートログインのためのグローバルな SSH ユーザ名も定義します。ここから、Nagios は必要なパラメータを付けて SSH プ ラグインを呼び出すことができ、プラグインによって指定されたホストとのセキュアな接続を確立して、そのプログラムの出力を Nagios 処理のために返します。この方法と通常のコマンド処理の間の実施上のわずかな違いは、サービスプロファイルがいくらかの追加パラメータを要求し、そのタスクを直接取り扱わないで、Nagios がリモートコマンド処理を行うために、SSH プラグインを呼び出すという事実です。
このモデルは、ネットワーク監視インタフェースを提供しないサービスにとって特に重要です。例えば多くの最近のアプリケーションサーバは、一日あたりに処理されたリスクエスト数などの重要な属性の統計を保持しますが、ローカルの管理ユーティリティを通してはわずかな情報しか利用できません。それら状況下では、GroundWork Monitor にデータを受け入れる最も簡単でセキュアな方法は、Nagios の SSH プラグインによる必要な管理コマンドのリモート実行処理を自動化することです。
簡単に監視できない特定のサービスを除き、多くの管理者は、システムレベルのリソースを監視するのに、Nagios の "ローカル" コマンドのまとまり全体をリモートホストに単にコピーしてSSH プラグインを使用し、その後リモートシステムにログインしてそれらのコマンドを実行するためにその SSH プラグインを使います。技術的に要求されてはいません(同しデータのほとんどを得るのに他の方法があります)が、それらのシステム上の他のタスクのために管理者が SSH プラグインを使用しなければならないなら、この方法はデータ収集を単純化します。
これらの理由から、GroundWork Monitor の商用版は、多くの共通アプリケーションとシステムレベルのリソースを監視することのできるいくつかの定義済の SSH サービスプロファイルを含んでおり、また、必要なら簡単に新たにプロファイルを作ることができます。
リモートホスト上でコマンドを実行するために、SSH プラグインを使用することは、最初に一度だけ作業を行う必要がありますが、実際にはまったく簡単です。特に、ネットワーク管理者は Nagios がリモートログインを行うためにユーザアカウントを定義する必要があり、そのアカウントのためのプライベートとパブリックの鍵を設定しなければなりません。また、この作業を行ったら、しかるべきサービス定義を GroundWork Monitor サーバ上に作成する必要があります。
GroundWork Monitor 内のすべてのSSHベースのコマンド定義は、リモートログインをするのに、Nagios マクロ定義の "user17" に保存されるユーザ名を使います。このマクロのデフォルト値は、"nagios" と割り当てられていますが、どのようなユーザ名でも使うことができます。
ユーザ名を変えるには、以下のステップに従ってください:
Configuration(コンフィグレーション)アプリケーションを開きます。
ヘッダー・バー内の Control(コントロール)メニューを選びます。
左枠内の Nagios resource macros(Nagiosリソースマクロ)メニューを選びます。
メインウィンドウ内の Nagios Resource Macros 内の一覧の user17 エントリの隣のチェックボックスを選びます。するとメインウィンドウがリロードされ、 最上部に user17 マクロの編集フィールドが表示されます。
好ましいユーザ名に user17 マクロの値を変え、Update(更新)ボタンを押します。
Nagios の構成設定が保存されて、コミットされたら、新しいユーザ名がその後、user17マクロを参照するすべての SSH サービス定義で使用されます。
図: Nagios リソースマクロ
モニタリングに使用するため、各マシン上に SSH ユーザ名に対応するユーザアカウントが必要です。ユーザアカウントがまだ存在しない場合、そのシステムが Nagios SSH プラグインによってアクセスされる前に、作成する必要があります。
ユーザアカウント管理業務はプラットフォーム固有ですので、新しいユーザの作成方法の情報については、そのシステムのドキュメントを参照してください。そのアカウントに付けるユーザ名は、Nagiosマクロの user17 で指定したユーザ名(デフォルトは "nagios" です)と一致し、また、SSH の構成ディレクトリを公開鍵を保存するホームディレクトリを持つ必要があります。
最新の Linux システムでは、一般的に下記の順序のコマンドを使います:
root などの管理アカウントでターゲットのシステムのログインします。
Nagios のユーザアカウントを作成し、そのユーザのホームディレクトリも作成します。デフォルトのユーザ名 nagios であれば、コマンドは、useradd -m nagios となるでしょう。
ユーザのホームディレクトリが新しいユーザアカウントの所有であり、そのユーザが読み、書き、実行できるかを確認します。例えば、ユーザのホームディレクトリが /home/nagios である場合、ls -lad /home/nagios コマンドで、オーナが Nagios で、オーナのパーミッションが rwx と表示される必要があり
$ ls -lad /home/nagios
drwxr-x--- 9 nagios Users 512 Apr 26 2007 /home/nagios
そのアカウントのプライマリグループのためのあるレベルのアクセスはしばしば認められており、これは一般的にはローカルの管理ポリシーの問題です。しかし、いくつかの SSH サーバが不十分なセキュリティのホームディレクトリを持つアカウントへのログインを禁止することが知られています(詳しくは sshd のドキュメントを参照してください)。
パスワードは SSH 公開鍵認証方式機構では使用されませんが、好ましくないアクセスを防止するため、そのユーザアカウントにパスワードをアサインするべきです。デフォルトのユーザ名 nagios にパスワードを付けるコマンドは、passwd nagios で、コマンドを投入すると、new user password とプロンプトが表示されます。
ユーザアカウントが作成され有効になったら、そのユーザが指定したパスワードでシステムにログインできるかと、そのユーザがホームディレクトリにファイルを作成し編集できることを確認します。
SSHは、伝統的なパスワード認証を含む、いくつかの異なるユーザのログイン認証のための機構をサポートします。しかしパスワードのプロンプトがリモートコマンドの実行を妨害するので、Nagios の SSH プラグインはパスワード認証を使うことができません。
Nagios で SSH プラグインを使うために、関連するユーザアカウントを公開鍵認証のために構成設定する必要があります。
公開鍵認証は、ユーザアカウントの認証に二つのデータを使用します。まず、SSH クライアントが認証を受ける時に SSH サーバに渡す、ユーザアカウントのプライベート鍵を含むファイルを管理します。一方、SSH サーバは指定されたユーザホームディレクトリの下の SSH サブディレクトリ内のパブリック鍵を探し、プライベート鍵をそのパブリック鍵の内容を復号するために使います。
復号処理が成功したら、所有していたプライベート鍵が認証されたたとして、ユーザは指定したアカウントでログインが認められます。このモデルでは、ユーザがパスワードをキー入力して転送しなくてもログインできます。この点は、パスワードで認証は SSH プラグインが読み取ることのできるパスワードが必要になり、そのパスワードがどこかに明白なテキストのデータとして保存される必要があるため、重要なことです。パブリック鍵を使うことで、そのアカウントの実際パスワードをさらすことなく、暗号化されたプライベートキーをディスク上に保存して必要に応じて使うことができます。
これを正しく処理するには、以下に詳述するいくつかのステップが必要です:
root などの管理アカウントでリモートシステムにログインし、SSH サーバの公開鍵認証が有効になっているかを確認します。SSH サーバの構成のメカニズムはシステム固有であり、詳細は、あなたのシステムのドキュメントを参照してください。ほとんどの Linux システムは、通常 sshd_config という構成ファイルを使用するオープンソースの OpenSSH パッケージを使用しています。ただし、構成ファイルの位置はディストリビューションによって異なります。OpenSSH を持つ、ほとんどの Linux ディストリビューションは、デフォルトで公開鍵認証を有効にしていますが、明確に有効化する必要がある場合は構成設定ディレクティブ PubkeyAuthentication の値を yes に変更するか、追加するかすることで行えます。このディレクティブを変更した場合、SSH サーバを再起動する必要があります。
ここで、Nagios SSH プラグインが使用するパブリック鍵とプライベート鍵のペアを作成する必要があります。GroundWork Monitor サーバにrootなどのシステム管理者アカウントでログインし、su nagios コマンドを使って、ローカルの nagios アカウントに資格変更します。
cd ~コマンドを使って、nagios アカウントのホームディレクトリに移動します。
ssh-keygen -t dsa -b 2048 コマンドを実行します。これにより、2048 ビットの DSA キーペアが nagios アカウントのホームディレクトリの .ssh サブディレクトリの中に作成されます。これらのファイル名は、id_dsa (プライベート鍵)と id_dsa.pub (パブリック鍵)です。
プライベート鍵ファイルは、リクエストとそれ以降のSSH接続要求すべての中のユーザ認証の証明に使用しますので、注意深くセキュアにする必要があります。このファイルは通常、そのファイルのオーナーのみが読み書き可能という非常に厳格なパーミッションで作成され、SSHクライアントのいくつかはあまりパーミッションが緩いとプライベートキーの使用を拒否することもあります。このファイルは認証のリクエストのみで必要なだけで、アクセス許可には使用しないので、このファイルを現在の位置から動かすことやパーミッション変更は不要です。しかしながら、その逆に、パブリック鍵は認証リクエストを許可するのに使用しますので、パブリック鍵ファイルの内容は、Nagios SSH プラグインが使用される各リモートシステムに追加する必要があります。
OpenSSH サーババージョン3を使用しているUNIXシステム上では、ユーザのパブリック鍵はホームディレクトリ下の .ssh サブディレクトリ内にある authorized_keys というファイルに保存されています(他のサーバとバージョンは、別のリポジトリ機構を持つでしょう)。Ngios の SSH プラグインが各リモートサーバで上手く認証されるよう、上記のステップで作成された id_dsa.pub ファイルの内容が、各ターゲットシステム上の Nagios ユーザの authorized_keys ファイルに追加される必要があります。
注:パブリック鍵データは、authorized_keys ファイルに中にどのような方法を使ってでもコピーすることができますが、改行や復帰文字など、余計な文字を加えてしまうことが無いように用心してください。
authorized_keys ファイルが更新されたら、ls -la ~/.ssh/authorized_keys コマンドを使って、ユーザアカウントがまだそのファイルのオーナであることと、そのファイルのパーミッションが正しいことを確認します。
$ ls -la ~/.ssh/authorized_keys
-rw-r--r-- 1 nagios Users 604 Apr 26 2007 /home/nagios/.ssh/authorized_keys
注:プライベート鍵としての、このファイルのグループとワールドに対するファイルパーミッションは、それ自体では害のないパブリック鍵だけを含むので重要ではありません。ユーザは他のシステムへのアクセスを得るのにこのファイルを使うことができませんし、ユーザアカウントに関する何の機密も知りえません。実際に、いくつかのSSHサーバでは、そのサーバが内容をアクセスできるよう、そのファイルのワールド-読み込み権限を要求しています。
GroundWork Monitor サーバに戻り、su nagios コマンドで nagios ユーザアカウントに変わります。そのユーザが、SSH を使ってリモートホスト上の正しいアカウントにログインできること、この処理の間にパスワードの交換がないことを確認してください。
上記ステップが正しく終了すると、 Nagios の SSH プラグインは、正しいユーザ名とパブリック鍵を持つ、どのようなターゲットホストへでも、途切れなくログインすることができるでしょう。ここから以降、あなたはキーファイル自体を保守することに注意すればよく、個々のシステム上のパスワードはプラグインでは使用しないので、あなたが望むランダムな文字列に変更してもかまいません。追加のより高いレベルのセキュリティが必要か望ましい場合、SSHプラグインへのアクセスをより厳しくするための追加施策は、http://www.linuxjournal.com/article/8759 をご覧ください。
Nagios はリモートサーバ上でコマンド発行したとき、プライマリのユーザアカウントのホームディレクトリ下の特定のサブディレクトリの中を探すことで、正しいコマンドが呼び出されたことを確認しようとします。SSH サービス定義のデフォルトセットが期待通りに働くのを保証するため、それらのコマンドがリモートホスト上のしかるべきサブディレクトリにコピーされていることを確認する必要があります。デフォルトでは、このサブディレクトリは Nagios の user22 マクロ定義の中で "libexec" の値で指定されています。
ターゲットホストのプラットホームが、ほぼ同じバージョンの Linux で稼動し、 GroundWork Monitor サーバを動かしているプラットホームと同じプロセッサ・アーキテクチャを持っている場合、下記のコマンドを使って、ローカルコマンドの内容とディレクトリをしかるべきターゲットシステムに単にコピーすることができます:
GroundWork Monitor サーバにログインし、su nagios コマンドを使って nagios ユーザアカウントの切り替えます。
scp -pr /usr/local/groundwork/nagios/libexec destination:~, コマンド(destination はターゲットシステムの IP アドレスかホスト名です)使って、ターゲットのホストに /usr/local/groundwork/nagios/libexec サブディレクトリ全体をコピーします。チルド文字は、入力のディレクトリをユーザのホームディレクトリの中にコピーすることを指示し、その結果、ユーザのホームディレクトリの下に libexec サブディレクトリが生成されます。
ターゲットホストのオペレーティングシステムやプロセッサのアーキテクチャが、GroundWork Monitor サーバのプラットホームと異なる場合、Nagios Exchange http://www.nagiosexchange.org/から適合する Nagios のコマンドをダウンロードして、それらをターゲットのホストシステム上にインストールする必要があります。それらをSSH ユーザアカウントのホームディレクトリ下の libexec サブディレクトリの中に確実に入れ、そのアカウントがそのプログラムを実行するのに十分なパーミッションを持っていることを確認してください。
すべてのファイルがターゲットホスト上の正しいディレクトリに入れられたら、GroundWork サーバに Nagios の SSH アカウントでログインして、ssh コマンドにリモートコマンドのひとつをパラメータとして与えることで、それらが期待通り働くかを確認できます。これは、SSH クライアントがリモートホストに、現在のユーザ資格でログインして指定されたコマンドを実行し、それが返したどんな出力をも表示し、そして SSH セッションをクローズすることを引き起こします。例えば、下記のコマンドは、目的ホスト上で空きの使用スワップ領域の量を参照し、もし空き領域が100バイト以下であればワーニングを発生させ、空き領域が50バイト以下であればクリティカルエラーを発生させるでしょう:
nagios$ ssh destination libexec/check_swap -w 100 -c 50
SWAP OK - 100% free (1349 MB out of 1349 MB) |swap=1349MB;0;0;0;1349
このコマンドが正常に終了したら、Nagios の SSH プラグインコマンドもまた、期待通りに機能するでしょう。
注意:libexec ディレクトリの中の Perl スクリプトは、 /usr/local/groundwork/bin の中にある Perl インタプリタを使うように構成されていますが、デフォルトではリモートマシン上にはそのディレクトリは存在しないでしょう。異なるインタプリタを使うには、Perlスクリプトを更新するか、既存の Perl インタプリタからそのディレクトリへのシンボリックリンクを作成して、それが存在するようにするか必要があるかもしれません