Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tectia

公開鍵を使用したサーバの認証

サーバは、DSA または RSA 公開鍵アルゴリズムに基づいたデジタル署名を使用して認証されます。接続の最初の段階で、サーバは検証のためにその公開鍵をクライアントに送信します。

サーバの認証は、単一の公開鍵操作を通して Diffie-Hellman 鍵交換中に実行されます。サーバの認証に公開鍵認証が使用される場合は、最初の接続が非常に重要です。最初の接続中、図 5.2 示すようなメッセージがクライアントに表示されます。

Windows 上の SSH Tectia Client – リモート ホストへの最初の接続

図 5.2. Windows 上の SSH Tectia Client – リモート ホストへの最初の接続

[警告]警告

ホスト公開鍵の信頼性を検証せずに保存することは絶対に避けてください。

サーバ ホストの身元を検証できるように、このメッセージにはホストの公開鍵のフィンガープリントが表示されます。このフィンガープリントは SSH Babble 形式で表示されます。この形式は、ダッシュで区切られた小文字 5 文字からなる読み上げ可能な一連の単語で構成されています。

このフィンガープリントの有効性を検証します。たとえば、リモート ホスト コンピュータの管理者に、できれば電話で連絡して、この鍵のフィンガープリントが正しいことを確認するよう依頼します。このフィンガープリントが検証されていない場合は、接続先のサーバが目的のサーバではない可能性があります (これを中間者攻撃と呼びます)。

フィンガープリントを検証したら、接続を続行できます。次に、サーバ公開鍵に関する関連情報がクライアント側のマシンに保存されます。UNIX 上の SSH Tectia Client では、このファイルは $HOME/.ssh2/hostkeys ディレクトリに保存されます。Windows 上の SSH Tectia Client では、このファイルは %APPDATA%\SSH\HostKeys ディレクトリに保存されます。

保存されたホスト鍵に関する情報は、これらのリモート ホストへの以降の接続で使用されます。SSH Tectia Client は、特定のサーバ用に所有しているホスト鍵の種類 (RSA または DSA) を確認し、それに応じてクライアントとサーバの間の接続で使用する鍵の交換アルゴリズムを自動的に選択します。これにより、1 種類のホスト鍵だけが保存されているホストへの接続がより迅速になります。

strict-host-key-check が無効になっている場合 (デフォルトの状態)、SSH Tectia Client は、変更されたホスト公開鍵と新しいホスト公開鍵に関する情報を、そのフィンガープリントとともに syslog (UNIX の場合) またはイベント ビューア (Windows の場合) に記録します。

===AUTO_SCHEMA_MARKUP===