whitepaper

SSHが選ばれた理由
SSHが、選択された理由はいくつかあり、すべて簡単なものです。たとえば、SSHによりリモートからコマンドの実行やファイル コピーができること、安全な認証メカニズムを備えていること、従来のUNIXRの「r」サービスとは異なり、ネットワーク経由で送信されるすべてのデータを暗号化することなどが挙げられますが、最も重要な点は、SSHが普及しているプロトコルであり、専用プロトコルではないということです。SSHを選択する際に最も考慮された点は、各管理対象ノードにJavaTMベースの専用マネジメント エージェント（例えばHP Servicecontrol Managerのmxagent）をインストールしなくてもいいようにするということでした。
SSHは、IETF（Internet Engineering Task Force）ドラフトに基づく標準規格です。SSHは、UNIXの「r」サービス（remsh、rlogin、およびrcp）の代わりに作成されました。「r」サービスを使用すると、リモートからシェルを起動し、コマンドを実行し、ファイルをコピーできます。ただし、残念なことに、「r」サービスを使用して通信するシステム間では、すべてのデータが暗号化されず平文でやり取りされます。また、認証メカニズムが脆弱なため、攻撃に対して無防備です。rhost認証は、Man-In-The-Middleアタックに弱く、パスワードもネットワーク上では平文でやり取りされます。SSHは、キー ベースのホスト認証を使用してリモート システムが本当のシステムであるかどうか（成りすましが行われていないかどうか）を確認するメカニズムを提供し、クライアント/サーバ間のすべての通信をネットワークの全体にわたって暗号化することによりパスワードの盗聴を防止します。また、パブリック キー認証により、ユーザ認証の強力な方式を提供します。

SSHの認証メカニズム
接続を確立するには、まず、SSHクライアントがリモート システムにアクセスします。セッション キーが交換され、これらのキーがクライアント/サーバ間における以降のすべての通信を暗号化するために使用されます。リモートのSSHサーバは、ホスト キーと呼ばれるサーバの身分証明をSSHクライアントに送信して、確認を求めます。
システム間の最初の接続が行われる間だけは、接続はMan-In-The-Middleアタックに対して脆弱な状態になります。リモート システムの身分証明が未知の状態であるため、比較の対象になるものがありません。通常、SSHクライアントは、リモート ホストが未知の状態であることをユーザに通知し、ホスト キーのフィンガープリントを表示して、受け入れるかどうかをユーザに問い合わせます。ユーザがこれを受け入れると、リモート システムのホスト キーは、保存された以降の接続で比較のために使用されます。
リモート システムが本物であることが確認されると、SSHクライアントは、ログインを要求しているユーザのユーザ名およびそのユーザの証明書をリモートのSSHサーバに送信します。ユーザ認証にはホストベースの認証、パスワード認証、およびパブリック キー認証の3つの方法があり、ユーザはそのいずれかを使用して認証されます。ホストベースで認証を行う場合は、SSHクライアントがそのホスト キーをリモートのSSHサーバに送信します。リモート サーバは、保存している信頼済みホストのリストを調べて、そのSSHクライアントがリストに記述されているかどうかを確認します。SSHクライアントが記述されている場合、リモート サーバは、SSHクライアントを信頼して、クライアントがそのユーザをすでに正しく認証していると判断し、ログインを許可します。
パスワードが送信されると、リモートのSSHサーバは、ユーザ名とパスワードの情報を使用して、ユーザを認証しようとします。このプロセスでのSSHの方法と「r」サービスの方法の違いは、1つしかありません。つまり、SSHでは、ネットワーク上でやりとりされるパスワードは、SSH接続を介して送信される他のすべてのデータと同様に暗号化されます。
パスワード認証とは異なり、パブリック キー認証のメカニズムは、SSH独自のものであり、ログインのための最も安全な方法です。パブリック キーを推測することは、パスワードを推測するよりも困難です。また、このメカニズムでは、SSHサーバがSSHクライアントを信頼してユーザが正しく認証されたと判断する必要はありません。パブリック キー認証では、SSHクライアントが、ユーザのパブリック キーをユーザ名と一緒に送信します。SSHサーバは、そのユーザについて、認証済みキーのリストを調べて、一致を確認すると、そのパブリック キーを使用して暗号化したメッセージをクライアントに戻します。クライアントは、そのユーザのプライベート キーを使用してメッセージを復号化し、サーバに応答メッセージを送信し、対応するプライベート キーを所有していることを証明します。サーバがこの確認を受け取ると、認証が完了します。
ここまでで暗号化セッションが開始され、ユーザが認証されたので、このセッションを使用して、ファイルをコピーしたりコマンドを実行したりすることができるようになります。

SSHの各ファイル

ここまでで説明したメカニズムには、いくつかの重要なファイルが関係します。クライアント側には、既知のホストのリストやパブリック キー認証に使用されるパブリック キー/プライベート キー ペア、あるいはホストベースの認証を行う場合は、ホスト キーがあります。一方、サーバ側には、各ユーザを対象とする許可されたキーのファイルおよびサーバのホスト キーがあります。
HP Systems Insight ManagerはOpenSSHを使用するため、ここで説明するディレクトリおよびファイル名は、OpenSSHがインストールされたシステムに固有のものです。

SSHクライアント コンフィギュレーション ディレクトリ
標準のOpenSSHクライアントを実行する各ユーザは、クライアントがこれらのファイルを保存するために使用するコンフィギュレーション ディレクトリを所有します。HP-UXおよびLinuxでは、このディレクトリは、ユーザのホーム ディレクトリの下にある隠しディレクトリ「.ssh」です（例：/home/sshuser/.ssh）。Windowsでは、このディレクトリは、通常、ユーザの「Documents and Settings」ディレクトリにあります（例：C: \Documents and Settings\sshuser\.ssh）。
このディレクトリは、最初に必要になった時点で、SSHにより自動的に作成されます。システムからの接続が最初に行われると、このディレクトリが作成され、known_hostsファイルを作成できるようなります。また、HP Systems Insight Managerで、ユーザ認証をセットアップするために、管理対象システムに対してmxagentconfigが実行されると、このディレクトリが作成され、CMSから送信するキーをユーザの認証済みのキー ファイルに配置できるようになります。

既知のホスト
既知のホスト キーのリストは、known_hostsファイルにあります。このファイルには、ユーザが受け入れたホスト キーが記述されます。コマンド ライン クライアントからSSHサーバに最初に接続すると、必ず、ホストが認識されていないことがクライアントからユーザに通知され、追加できるかどうかの問い合わせが行われます。

このメッセージを受け入れると、known_hostsファイルにエントリが追加されます。たとえば、サーバの再インストールなど、SSHサーバのホスト キーが変更されるようなことがあったり、別のシステムがそのサーバに成りすまそうとしたりすると、当該のキーが既知のキーと一致しなくなり、クライアントの接続は切断されます。

$ ssh peanut
	
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
31:d7:ce:aa:24:c3:42:fe:77:cd:48:80:f6:0e:34:b6.
Please contact your system administrator.
Add correct host key in /home/sshuser/.ssh/known_hosts to get rid of this message.
Offending key in /home/sshuser/.ssh/known_hosts:1
RSA host key for peanut has changed and you have requested strict checking.
Host key verification failed.

パブリック キー/プライベート キー ペア
パブリック キー認証のために、キー ペアが作成され、ユーザの.sshディレクトリに保存されます。プライベート キーは、クライアント システムの外にもれることはありません。プライベート キーは、認証の過程で、対応するパブリック キーを使用してリモートのSSHサーバが暗号化したメッセージを復号化するために使用されます。
パブリック キーは、実際には、クライアントが使用することはありません。このキーは、リモート システムにコピーできるように、ユーザのSSHコンフィギュレーション ディレクトリに保存されます。実際、このファイルが消失するようなことがあっても、プライベート キーから再生できます。つまり、パブリック キーがこのディレクトリに保存される主な理由は、利便性を考慮したためです。
通常、キー ペアは、そのキーのタイプに適合する名前で保存されます。プライベート キーとパブリック キーには同じファイル名が付けられますが、プライベート キーには、拡張子がなく、パブリック キーには「.pub」という拡張子が付けられます。たとえば、あるOpenSSH DSAキー ペアは、id_dsaファイルとid_dsa.pubファイルに保存され、あるRSAキー ペアは、id_rsaファイルとid_rsa.pubファイルに保存されます。

認証済みのキー
ユーザのSSHコンフィギュレーション ディレクトリには、authorized_keys2という名前の、認証済みのキー ファイルもあります。最後に、このファイルについて説明します。このファイルは、パブリック キー認証を使用したリモート ログインが要求されたとき、チェックされるキーのリストです。リモート クライアントによって提示されているキーがファイルのリストにある場合、SSHサーバは、そのキーを使用してチャレンジを暗号化し、リモート クライアントに送信し、チャレンジに対するレスポンスが正しい場合は、ログインを許可します。そのパブリック キーがない場合は、認証はできなくなります。
このファイルは、通常、手動で維持管理されます。キー ペアを生成し、パスワード認証を使用して、ログインしたいすべてのシステムにパブリック キーをコピーし、これらの各システム上にあるauthorized_keys2ファイルの末尾に追加します。また、各システム上でホーム ディレクトリをNFSマウントすることもできます。この場合は、1つのファイルを更新するだけで済みます。
大量のシステムがある場合、この手順は、うんざりするような作業になる可能性があります。各システムにリモートからログインして、ネットワーク経由でキーをコピーし、キー ファイルの更新のための何らかのコマンドを発行しなければなりません。幸いなことに、HP Systems Insight Managerには、mxagentconfigというツールが用意されており、このツールを使用すると、一連のプロセスが簡単になります。次の項では、mxagentconfigについて説明します。