NFS サービスのしくみ

次のセクションでは、NFS の複雑な機能をいくつか紹介します。このセクションで紹介する機能のいくつかは、NFS Version 4 専用です。

• NFS におけるバージョンのネゴシエーション

• NFS Version 4 における機能

• UDP と TCP のネゴシエーション

• ファイル転送サイズのネゴシエーション

• NFS Version 3 でのファイルシステムのマウント方法

• マウント時の -public オプションと NFS URL の意味

• クライアント側フェイルオーバー

• NFS サーバーログ機能のしくみ

• WebNFS サービスのしくみ

• Web ブラウザの使用と比較した場合の WebNFS の制約

• Secure NFS システム

• Secure RPC

RDMA 経由の NFS

Oracle Solaris 11.1 リリース以降、NFS のデフォルトトランスポートは Remote Direct Memory Access (RDMA) プロトコルです。このプロトコルは、高速ネットワークを介したメモリー間データ転送を提供します。特に、RDMA により、CPU の介入なしでメモリーにリモートデータ転送を直接行えます。RDMA は直接データ配置も提供しており、これによってデータコピーがなくなり、さらに CPU 介入がなくなります。このように、RDMA はホストの CPU を解放するだけでなく、ホストメモリーと入出力バスの競合を少なくします。この機能を提供するために、RDMA は、InfiniBand のインターコネクト入出力テクノロジ (SPARC および x86 プラットフォームの両方で使用可能) と Oracle Solaris オペレーティングシステムを結合します。次の図は、UDP や TCP など、その他のプロトコルとの RDMA の関係を示します。

図 1  その他のプロトコルとの RDMA の関係

RDMA は NFS のデフォルトのトランスポートプロトコルなので、クライアントまたはサーバーで RDMA を使用するために特別な share オプションや mount オプションは必要ありません。既存のオートマウンタマップ、vfstab とファイルシステム共有は、RDMA トランスポートで機能します。クライアントとサーバーの間に InfiniBand 接続が存在するときは、RDMA トランスポート経由の NFS マウントが透過的に実行されます。InfiniBand 接続機能は SPARC と x86 の両方のプラットフォームで動作します。RDMA トランスポートをクライアントとサーバーで使用できない場合、TCP トランスポートが初期フォールバックになります。TCP が使用できない場合は UDP がフォールバックになります。ただし、–proto=rdma マウントオプションを使用する場合、NFS マウントは RDMA だけを使用するように強制されます。

TCP と UDP のみを使用するように指定するときは、–proto=tcp/udp mount オプションを使用できます。このオプションは、NFS クライアントの RDMA を無効にします。NFS マウントオプションの詳細は、mount_nfs(1M) および mount(1M) のマニュアルページを参照してください。

NFS におけるバージョンのネゴシエーション

NFS 起動プロセスには、サーバーとクライアントのためのプロトコルバージョンレベルのネゴシエーションが含まれています。バージョンのレベルを指定しない場合、デフォルトにより最適なレベルが選択されます。たとえば、クライアントとサーバーの両方が NFS Version 3 をサポートできる場合は、それが使用されます。クライアントまたはサーバーが NFS Version 2 のみをサポートできる場合、それが使用されます。

sharectl コマンドを使用することで、client_versmin、client_versmax、server_versmin、および server_versmax パラメータを設定できます。これらのパラメータのデフォルト値は、クライアントとサーバーに指定した最小値と最大値によって置き換えられます。クライアントとサーバーの両方で、デフォルトの最小値は 2、デフォルトの最大値は 4 です。サーバーによってサポートされるバージョンを見つけるために、NFS クライアントは client_versmax の値から始めて、client_versmin のバージョン値に到達するまで各バージョンの試行を続けます。サポートされるバージョンが検出されるとすぐに、この処理は終了します。たとえば、client_versmax=4 で client_versmin =2 の場合、クライアントは最初に NFS Version 4、次に NFS Version 3、最後に NFS Version 2 を試行します。client_versmax と client_versmax が同じ値に設定されている場合は、クライアントは常にこのバージョンを使用し、ほかのバージョンは試行しません。サーバーがこのバージョンをサポートしていない場合、マウントは失敗します。

NFS サービスの設定については、NFS サービスの設定を参照してください。

NFS Version 4 における機能

このセクションでは、NFS Version 4 で導入された機能について説明します。

• NFS Version 4 におけるファイルシステムの共有解除と再共有

• NFS Version 4 でのファイルシステム名前空間

• NFS Version 4 における揮発性ファイルハンドル

• NFS Version 4 におけるクライアント回復

• NFS Version 4 における OPEN 共有サポート

• NFS Version 4 における委託

• NFS Version 4 での ACL と nfsmapid

NFS サービスの設定については、NFS サービスの設定を参照してください。

NFS Version 4 におけるファイルシステムの共有解除と再共有

NFS Version 3 と Version 4 の両方で、クライアントが共有解除されたファイルシステムにアクセスしようとすると、サーバーはエラーコードを返します。ただし、NFS Version 3 では、サーバーはファイルシステムが共有解除される前にクライアントが取得したロックを保持します。したがって、ファイルシステムが再共有されると、NFS Version 3 クライアントは、そのファイルシステムが共有解除されなかったかのようにファイルシステムにアクセスできます。

NFS Version 4 では、ファイルシステムが共有解除されると、そのファイルシステム内のオープンファイルまたはファイルロックに関するすべての状態情報が破棄されます。クライアントは、これらのファイルにアクセスしようとしたりロックしようとしたりすると、エラーを受け取ります。このエラーは通常、アプリケーションに対する入出力エラーとして報告されます。ただし、オプションを変更するために現在共有されているファイルシステムを再共有しても、サーバーの状態情報は破棄されません。

NFS Version 4 のクライアント回復については、NFS Version 4 におけるクライアント回復を参照してください。unshare コマンドで使用可能なコマンドオプションについては、unshare_nfs(1M) のマニュアルページを参照してください。

NFS Version 4 でのファイルシステム名前空間

NFS Version 4 サーバーは、サーバー上のすべてのエクスポート済みファイルへのシームレスアクセスを NFS クライアントに提供する、擬似ファイルシステムを作成および保守します。NFS Version 4 以前は、擬似ファイルシステムは存在しませんでした。NFS クライアントは、アクセスする各共有サーバーのファイルシステムに強制的にマウントされます。

擬似ファイルシステムは、ディレクトリだけを含む構造で、サーバーによって作成されます。擬似ファイルシステムを介して、クライアントはエクスポート済みファイルシステムの階層を参照します。つまり、クライアントから見る擬似ファイルシステムは、エクスポート済みファイルシステムに関連付けられたパスに制限されます。

以前のバージョンの NFS では、クライアントは、サーバーのファイルシステムを検索するには、各ファイルシステムをマウントする必要がありました。ただし、NFS Version 4 ではサーバー名前空間が次のことを行います。

• クライアントから見えるファイルシステムをサーバーエクスポートに関連付けられたディレクトリに制限します。

• サーバーエクスポートへのシームレスアクセスをクライアントに提供します (クライアントは配下の各ファイルシステムをマウントする必要がない)。ただし、オペレーティングシステムが異なるときは、クライアントが各サーバーファイルシステムをマウントしなければいけない場合があります。

図 2  NFS Version 4 でのサーバーファイルシステムおよびクライアントファイルシステムの見え方

図に示されている例では、クライアントは payroll ディレクトリと nfs4x ディレクトリを見ることができません (これらのディレクトリはエクスポート済みではなく、エクスポート済みディレクトリに関連付けられていないため)。ただし、local ディレクトリはエクスポート済みディレクトリであるため、local ディレクトリはクライアントが見ることができます。projects ディレクトリはエクスポート済みディレクトリ nfs4 に関連付けられているため、projects ディレクトリはクライアントが見ることができます。つまり、サーバー名前空間のうち明示的にエクスポート済みでない部分は、擬似ファイルシステムでブリッジされ、これ経由でエクスポート済みディレクトリおよびサーバーエクスポートに関連付けられたディレクトリだけを見ることになります。

NFS Version 4 における揮発性ファイルハンドル

ファイルハンドルは、NFS サーバー上で作成され、ファイルとディレクトリを一意に識別する情報を持ちます。NFS Version 2 と NFS Version 3 では、NFS サーバーが永続ファイルハンドルを返しました。したがって、NFS クライアントは、NFS サーバーが常に同じファイルを参照するファイルハンドルを生成することを保証できました。次に例を示します。

• ファイルが削除され同じ名前のファイルに置き換えられた場合、サーバーは必ず新しいファイルの新しいファイルハンドルを生成する。クライアントが古いファイルハンドルを使用していた場合、サーバーはファイルハンドルが無効であることを示すエラーを返す。

• ファイル名が変更されている場合、ファイルハンドルは変更されない。

• サーバーがリブートされた場合、ファイルハンドルは変更されない。

このように、サーバーがファイルハンドルを含むクライアントからの要求を受け取った場合、解決策は単純であり、ファイルハンドルは常に正しいファイルを参照します。

NFS 操作のために永続ファイルハンドルを使用してファイルとディレクトリを識別する方法は、ほとんどの UNIX ベースサーバーで機能しました。ただし、この方法は、ファイルのパス名などほかの識別方法を使用するサーバー上では実装できません。この問題を解決するために、サーバーは NFS Version 4 プロトコル経由でそのファイルハンドルが揮発性であることを宣言できます。ファイルハンドルが変更された場合、クライアントは新しいファイルハンドルを検出する必要があります。

NFS Versions 2 と NFS Version 3 サーバーと同様に、Oracle Solaris NFS Version 4 サーバーは常に永続ファイルハンドルを提供します。ただし、Oracle Solaris NFS Version 4 以外のサーバーにアクセスする Oracle Solaris NFS Version 4 クライアントは、サーバーが揮発性ファイルハンドルを使用する場合はそれらをサポートする必要があります。具体的には、サーバーがクライアントにファイルハンドルが揮発性であることを通知すると、クライアントはパス名とファイルハンドル間のマッピングをキャッシュする必要があります。クライアントは、期限切れになるまで、揮発性ファイルハンドルを使用します。期限が切れたとき、クライアントは次を実行します。

• そのファイルハンドルを参照するキャッシュされた情報をフラッシュする

• そのファイルの新しいファイルハンドルを検索する

• 操作を再試行する

揮発性ファイルハンドルはこれらの状況で期限切れになる可能性があります。

• ファイルを閉じたとき

• ファイルハンドルのファイルシステムが移行するとき

• クライアントがファイル名を変更するとき

• サーバーがリブートするとき

クライアントが新しいファイルハンドルを見つけられない場合、エラーメッセージログが syslog ファイルに記録されます。このファイルにさらにアクセスしようとすると、入出力エラーで失敗します。

NFS Version 4 におけるクライアント回復

NFS Version 4 プロトコルはステートフルプロトコルです。NFS クライアントと NFS サーバーの両方が、オープンファイルとファイルロックに関する現在の情報を保守します。

サーバーがクラッシュしてリブートしたとき、サーバーの状態は消失します。クライアントは、サーバーがリブートしたことを検出すると、障害の前に存在していたオープンおよびロック状態をサーバーが再確立するのを支援するプロセスを開始します。このプロセスは、クライアントがプロセスを指示するため、クライアント回復と呼ばれています。

クライアントは、サーバーがリブートしたことを検出すると、ただちに現在の動作を停止して、クライアント回復のプロセスを開始します。回復プロセスが開始されると、次のようなメッセージが、システムエラーログ /var/adm/messages に表示されます。

NOTICE: Starting recovery server server-name

回復プロセスの間、クライアントは、クライアントの以前の状態に関するサーバー情報を送信します。ただし、この間、クライアントはサーバーに新しい要求を送信しません。ファイルを開いたりファイルロックを設定したりするための新しい要求は、サーバーが回復プロセスを完了するのを待ってから続行する必要があります。

クライアント回復プロセスが完了すると、次のメッセージがシステムエラーログ /var/adm/messages に表示されます。

NOTICE: Recovery done for server server-name

この時点で、クライアントはサーバーに状態情報を送信するのを正常に完了しました。ただし、クライアントがこのプロセスを完了しても、ほかのクライアントがそうでない可能性があります。つまり、猶予期間と呼ばれる期間は、サーバーはすべてのクライアントがそれぞれの回復を完了できるように、いかなるオープンおよびロック要求も受け入れません。

猶予期間中に、クライアントが新しいファイルを開こうとしたり、新しいロックを確立しようとしたりすると、サーバーは GRACE エラーコードで要求を拒否します。このエラーを受け取ったクライアントは、猶予期間が終わるのを待ってから、要求をサーバーに再送信します。猶予期間中は、次のメッセージが表示されます。

NFS server recovering

猶予期間中も、ファイルを開いたりファイルロックを設定したりしないコマンドは処理できます。たとえば、コマンド ls と cd はファイルを開いたりファイルロックを設定したりせず、これらのコマンドは一時停止しません。ただし、ファイルを開く cat などのコマンドは、猶予期間が終わるまで中断されます。

猶予期間が終了すると、次のメッセージが表示されます。

NFS server recovery ok.

クライアントは、サーバーに新しいオープン要求またはロック要求を送信できるようになります。

クライアント回復は、さまざまな理由により失敗することがあります。たとえば、サーバーのリブート後にネットワークパーティションが存在する場合、クライアントは、猶予期間が終了する前にサーバーとの状態を再確立できない場合があります。猶予期間が終了すると、新しい状態操作により競合が発生する可能性があるため、サーバーはクライアントに状態の再確立を許可しません。たとえば、新しいファイルロックは、クライアントが回復しようとしている古いファイルロックと競合します。このような状況が発生すると、サーバーは NO_GRACE エラーコードをクライアントに返します。

ファイルに対するオープン操作の回復が失敗すると、クライアントはファイルを使用不可能としてマークし、次のメッセージが表示されます。

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status n):  file :  filename

回復に失敗している間にファイルロックを再確立すると、次のエラーメッセージが表示されます。

NOTICE: nfs4_send_siglost:  pid process-ID lost
lock on server server-name

この場合、SIGLOST シグナルがプロセスに送信されます。SIGLOST シグナルのデフォルトの動作は、プロセスを中断することです。

この状態から回復するには、障害発生時にファイルを開いていたアプリケーションを再起動する必要があります。ファイルを再度開くことができない一部のプロセスは入出力エラーを受け取る可能性があります。ファイルを再度開いたり、回復の失敗後にオープン操作を実行したりしたほかのプロセスは、問題なくファイルにアクセスできます。

このように、特定のファイルにアクセスできるプロセスとアクセスできないプロセスがあります。

NFS Version 4 における OPEN 共有サポート

NFS Version 4 プロトコルにはファイル共有モードがいくつか用意されていて、クライアントはほかのクライアントによるファイルアクセスを制御するために使用できます。クライアントは、次のように指定できます。

• DENY_NONE モードを指定すると、ほかのクライアントはファイルへの読み取りと書き込みアクセスを許可されます。

• DENY_READ モードを指定すると、ほかのクライアントはファイルへの読み取りアクセスを拒否されます。

• DENY_WRITE モードを指定すると、ほかのクライアントはファイルへの書き込みアクセスを拒否されます。

• DENY_BOTH モードを指定すると、ほかのクライアントはファイルへの読み取りと書き込みアクセスを拒否されます。

Oracle Solaris NFS Version 4 サーバーは、これらのファイル共有モードを完全に実装します。したがって、クライアントが現在の共有モードと矛盾する方法でファイルを開こうとすると、サーバーは操作を失敗させて、その試行を拒否します。このような試行がファイルのオープンまたは作成操作の開始で失敗すると、NFS Version 4 クライアントはプロトコルエラーを受け取ります。このエラーは、アプリケーションエラー EACCES にマップされます。

プロトコルはいくつかの共有モードを提供していますが、Oracle Solaris でのオープン操作は複数の共有モードを提供していません。ファイルを開くとき、Oracle Solaris NFS Version 4 クライアントは、DENY_NONE モードだけを使用できます。

NFS Version 4 における委託

NFS Version 4 は、委託のためにクライアントサポートとサーバーサポートを提供します。委託は、サーバーがファイルの管理を NFS クライアントに委託するためのテクニックです。たとえば、サーバーは、読み取り委託または書き込み委託のいずれかをクライアントに付与できます。読み取り委託は互いに競合しないため、複数のクライアントに同時に付与できます。書き込み委託はほかのクライアントによるファイルアクセスと競合するため、1 つのクライアントにだけ付与できます。書き込み委託を保持している間、クライアントは、ファイルへの排他的アクセスを保証されているために、さまざまな操作をサーバーに送信しません。同様に、読み取り委託を保持している間、クライアントはさまざまな操作をサーバーに送信しません。クライアントが書き込みモードでファイルを開けないことをサーバーが保証するためです。

委託により、委託されたファイルに対するサーバーとクライアントの相互作用を大幅に減少することができます。したがって、ネットワークトラフィックが減少し、クライアントとサーバーのパフォーマンスが向上します。ただし、パフォーマンス向上の度合いは、アプリケーションが使用するファイル相互作用の種類およびネットワークとサーバー輻輳の量によって異なります。

クライアントは、委託を要求しません。委託を付与するかどうかの決定は、ファイルのアクセスパターンに基づいてサーバーがすべて行います。ファイルが最近複数の異なるクライアントから書き込みモードでアクセスされた場合、このアクセスパターンが将来競合する可能性を示しているためサーバーは委託を付与しないことがあります。

競合は、ファイルに付与されている委託と一致しない方法でクライアントがそのファイルにアクセスするときに発生します。たとえば、あるクライアントがファイルの書き込み委託を保持しており、2 番目のクライアントが読み取りまたは書き込みアクセス用にそのファイルを開くとサーバーは最初のクライアントの書き込み委託を再呼び出しします。同様に、あるクライアントが読み取り委託を保持しており、別のクライアントが書き込み用に同じファイルを開くと、サーバーは読み取り委託を再呼び出しします。どちらの場合も、競合が現在存在しているため、2 番目のクライアントは委託を付与されません。

競合が発生すると、NFS サーバーはコールバックメカニズムを使用して、委託を保持しているクライアントと連絡をとります。このコールバックを受信すると、クライアントはファイルの更新された状態をサーバーに送信し、委託を返します。クライアントが再呼び出しに対する応答に失敗すると、サーバーは委託を取り消します。こうした場合、サーバーはこのファイルに対するクライアントの操作をすべて拒否し、クライアントは要求された操作を失敗として報告します。一般的に、これらの失敗は入出力エラーとしてアプリケーションに報告されます。これらのエラーから回復するには、ファイルを閉じてから再度開く必要があります。取り消された委託による失敗は、クライアントが委託を保持している間にクライアントとサーバー間にネットワークパーティションが存在しているときに発生します。

サーバーは、別のサーバーに格納されているファイルに対するアクセス競合を解決できません。つまり、NFS サーバーは、格納しているファイルに対する競合だけを解決します。さらに、さまざまなバージョンの NFS を実行しているクライアントによって発生する競合に対して、NFS サーバーは NFS Version 4 を実行しているクライアントにだけ再呼び出しを開始できます。以前のバージョンの NFS を実行しているクライアントに再呼び出しを開始できません。

競合を検出するプロセスはさまざまです。たとえば、NFS Version 4 とは異なり、NFS Version 2 と NFS Version 3 にはオープン手順がないため、クライアントがファイルの読み取り、書き込み、またはロックを試行したあとでのみ、競合が検出されます。これらの競合に対するサーバーの応答もさまざまです。次に例を示します。

• NFS Version 3 では、サーバーは JUKEBOX エラーを返し、クライアントはアクセス要求を停止してあとで再試行します。クライアントは、File unavailable というメッセージを表示します。

• NFS Version 2 では、JUKEBOX エラーと同等のエラーが存在しないためサーバーは応答せず、クライアントは待機してから再試行します。クライアントは、NFS server not responding というメッセージを表示します。

エラーメッセージは、委託の競合が解決されたときにクリアされます。

デフォルトでは、NFS サーバー委託は有効になっています。server_delegation パラメータを off に設定することで、委託を無効にできます。

# sharectl set -p server_delegation=off nfs

NFS クライアントの委託にキーワードは必要ありません。NFS Version 4 コールバックデーモン nfs4cbd により、クライアント上のコールバックサービスが提供されます。このデーモンは、NFS Version 4 のマウントが有効になると自動的に起動されます。デフォルトで、クライアントは、/etc/netconfig システムファイルに一覧表示されているすべてのインターネット転送に必要なコールバック情報を提供します。クライアントで IPv6 が有効であり、クライアントの名前の IPv6 アドレスを決定できる場合、コールバックデーモンは IPv6 接続を受け入れます。

コールバックデーモンは、一時的なプログラム番号と動的に割り当てられたポート番号を使用します。この情報は、サーバーに提供され、サーバーは委託を付与する前にコールバックパスをテストします。コールバックパスが正常にテストされない場合、サーバーは委託を付与しません。外部から見ることのできる動作だけになります。

コールバック情報は NFS Version 4 要求に埋め込まれているため、サーバーは、NAT (Network Address Translation) を使用するネットワークデバイスを通してクライアントに連絡できません。また、コールバックデーモンは、動的ポート番号も使用します。したがって、ファイアウォールがポート 2049 上で通常の NFS トラフィックを有効にしている場合でも、サーバーがファイアウォールを検索できない場合があります。この場合、サーバーは委託を付与しません。

NFS Version 4 での ACL と nfsmapid

アクセス制御リスト (ACL) は、ファイルの所有者が、ファイル所有者、グループ、ほかの固有のユーザーおよびグループに関するファイルアクセス権を定義できるようにすることで、ファイルのセキュリティーを提供します。ZFS ファイルシステムでは、chmod コマンドを使用することで、ACL を NFS サーバーおよび NFS クライアント上で設定できます。UFS ファイルシステムの場合は、setfacl コマンドを使用できます。詳細は、chmod(1) および setfacl(1) のマニュアルページを参照してください。NFS Version 4 では、ID マッパー nfsmapid を使用して、サーバー上の ACL エントリ内のユーザー ID またはグループ ID を、クライアント上の ACL エントリ内のユーザー ID またはグループ ID にマッピングします。逆も同じです。ACL エントリのユーザーおよびグループ ID は、クライアントとサーバーの両方に存在する必要があります。

ACL および nfsmapid の詳細は、次を参照してください。

• Oracle Solaris 11.3 での ZFS ファイルシステムの管理 の 第 9 章, ACL および属性を使用した Oracle Solaris ZFS ファイルの保護

• NFS デーモン

ID マッピングの問題

次の状態は、ID マッピングが失敗する原因になる可能性があります。

• サーバー上の ACL エントリ内に存在するユーザーまたはグループをクライアント上の有効なユーザーまたはグループにマッピングできない場合、ユーザーは ACL を読み取ることはできますが、ユーザーやグループの一部が unknown と表示されます。

  たとえば、この状況で ls –lv や ls –lV コマンドを発行した場合、一部の ACL エントリでグループやユーザーが unknown と表示されます。

• クライアント上で設定されている ACL エントリ内のユーザーまたはグループ ID をサーバー上の有効なユーザーまたはグループ ID にマッピングできない場合、setfacl や chmod コマンドが失敗し、 Permission denied エラーメッセージを返す可能性があります。

• クライアントとサーバーで nfsmapid_domain の値が一致しない場合、ID マッピングは失敗します。詳細は、NFS デーモン を参照してください。

ID マッピングの問題を回避するには、次を行います。

• nfsmapid_domain の値が正しく設定されていることを確認します。現在選択されている NFSv4 ドメインは、/var/run/nfs4_domain ファイル内で入手できます。

• ACL エントリ内のすべてのユーザー ID およびグループ ID が NFS Version 4 のクライアントとサーバーの両方に存在することを確認します。

マッピングされていないユーザー ID またはグループ ID を確認する

NFS サーバーまたはクライアント上でユーザーまたはグループをマッピングできないかどうかを判別するには、次のスクリプトを使用します。

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}

UDP と TCP のネゴシエーション

NFS Version 2 と Version 3 では、トランスポートプロトコルのネゴシエーションはマウント時に実行されます。開始時には、トランスポートプロトコルもネゴシエートされます。デフォルトでは、NFS クライアントと NFS サーバーの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合は、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使用されます。システムでサポートされているトランスポートプロトコルは、/etc/netconfig ファイルにリストされています。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 からサポートされています。UDP はコネクションレス型トランスポートプロトコルです。

NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使用する NFS Version 3 プロトコルの方が、TCP を使用する NFS Version 2 プロトコルよりも優先されます。mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます。mount コマンドの NFS 固有オプションについては、mount_nfs(1M) のマニュアルページを参照してください。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。

ファイル転送サイズのネゴシエーション

ファイル転送サイズは、NFS クライアントと NFS サーバーの間でデータを転送するときに使用されるバッファーのサイズを確立します。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS Version 3 プロトコルには転送サイズに上限はありません。クライアントはマウント時に小さい転送サイズを指定できますが、ほとんどの場合この指定は必要ありません。

転送サイズは、NFS Version 2 を使用しているシステムとはネゴシエートされません。ファイル転送サイズの上限は 8K バイトに設定されます。

mount コマンドに対して –rsize オプションと –wsize オプションを使用すると、転送サイズを手動で設定できます。システムクライアントの一部では転送サイズを小さくしなければいけない場合があります。また、NFS サーバーが大きなファイル転送サイズに構成されている場合は、転送サイズを大きくすることができます。

NFS Version 3 でのファイルシステムのマウント方法

このセクションの情報は NFS Version 3 マウントだけに適用されます。NFS Version 4 マウントプロセスは、ポートマップサービスおよび MOUNT プロトコルを取り込みません。

NFS クライアントが NFS サーバーからファイルシステムのマウントを試行するとき、クライアントはサーバーからファイルハンドルを取得する必要があります。ファイルハンドルは、そのファイルシステムに対応していなければなりません。そのためには、クライアントとサーバーの間でいくつかのトランザクションが発生します。この例では、NFS クライアントは NFS サーバーから /home/user をマウントしようとします。このトランザクションの snoop トレースは次のとおりです。

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33482
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/user
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

この追跡結果では、NFS クライアントがまずマウントポート番号を NFS サーバーの portmap サービスに要求します。クライアントが取得したマウントポート番号 (33492) は、サーバーでサービスが使用可能かどうかをテストするために使用されます。このポート番号でサービスが実行中であることが確認できると、クライアントはマウントを要求します。サーバーはこの要求に応答するときに、マウントするファイルシステムのファイルハンドル (9000) を取り込みます。これに対してクライアントは、NFS ポート番号を要求します。クライアントはサーバーからこの番号を受け取ると、NFS サービス (nfsd) が使用可能かどうかをテストします。また、そのファイルハンドルを使うファイルシステムに関する NFS 情報を要求します。

次のトレースでは、クライアントは –public オプション付きファイルシステムをマウントしています。

client -> server NFS C LOOKUP3 FH=0000 /export/home9/user
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

デフォルトの公開ファイルハンドル (0000) を使用しているために、すべてのトランザクションにポートマップサービスから情報が与えられ、NFS ポート番号を決定するためのトランザクションはありません。

マウント時の –public オプションと NFS URL の意味

–public オプションを使用すると、マウントが失敗することがあります。NFS URL を追加することも失敗の原因になる可能性があります。次のリストで、これらのオプションを使用した場合にファイルシステムがどのようにマウントされるかを説明します。

• public オプションと NFS URL – 公開ファイルハンドルを使用します。公開ファイルハンドルがサポートされていないと、マウントは失敗します。

• public オプションと通常のパス – 公開ファイルハンドルを使用します。公開ファイルハンドルがサポートされていないと、マウントは失敗します。

• NFS URL のみ – NFS サーバーでサポートされていれば、公開ファイルハンドルを使用します。public ファイルハンドルを使用したときにマウントが失敗する場合は、MOUNT プロトコルを使ってマウントしてみてください。

• 通常のパスのみ – 公開ファイルハンドルは使用しないでください。MOUNT プロトコルが使用されます。

クライアント側フェイルオーバー

フェイルオーバーは、複製されたファイルシステムをサポートしているサーバーのリストから、1 つのサーバーを選択するプロセスです。通常は、ソートされたリスト内の次のサーバーが使用されます (応答に失敗しないかぎり)。クライアント側フェイルオーバーを使用することで、NFS クライアントは複数のサーバーが同じデータを利用できるようにしているときを検出でき、現在のサーバーが使用不能になったときに代替サーバーに切り替えることができます。この切り替えは再マッピングと呼ばれます。正常使用のときは、クライアントはリモートファイルシステム上に各アクティブファイルのパス名を格納します。再マッピング時には、これらのパス名が評価されて新しいサーバー上のファイルが検出されます。

次のいずれかの状態が発生すると、ファイルシステムが使用不能になる可能性があります。

• ファイルシステムが、クラッシュしているサーバーに接続している

• サーバーの過負荷

• ネットワーク障害

これらの状況でのフェイルオーバーは通常、ユーザーに透過的です。クライアント上で実行中のプロセスを中断することなく、任意のときに実行される可能性があります。

フェイルオーバーを実行するには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないとフェイルオーバー機能は成功しません。ファイルシステムが同じであることについては、複製されたファイルシステムとは を参照してください。フェイルオーバー機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています。

同じ NFS マウント上では、CacheFS 機能とクライアント側のフェイルオーバー機能の両方は使用できません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報はフェイルオーバーの際に更新できないため、ファイルシステムをマウントするときにはこれら 2 つの機能の一方のみを使用できます。

各ファイルシステムで確立する必要がある複製の数は、さまざまな要素によって変わります。理想的には、2 つ以上のサーバーを持つことをお勧めします。それぞれのサーバーが複数のサブネットをサポートする必要があります。これは、各サブネットに一意のサーバーを設置するよりもよい方法です。このプロセスではリストされているすべてのサーバーを確認する必要があります。そのため、サーバーの台数を増やすと、それぞれのマウント処理が遅くなります。

複製されたファイルシステムとは

クライアント側フェイルオーバーが目的の場合は、元のファイルシステムとサイズが同じで、ファイルサイズまたはファイルタイプが同じときは、そのファイルシステムを「複製」と呼ぶことができます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズまたはファイルタイプが異なる場合は再マッピングは失敗し、古いサーバーが使用可能になるまでプロセスはハングアップします。NFS Version 4 では、この動作は異なります。クライアント側フェイルオーバーの詳細については、NFS Version 4 におけるクライアント側フェイルオーバー機能を参照してください。

rsync、cpio、または別のファイル転送メカニズムを使用することで、複製されたファイルシステムを保守できます。複製されたファイルシステムを更新すると不一致が発生するため、最良の結果を得るには次の予防策を考慮してください。

• 新しいバージョンのファイルをインストールする前に、古いバージョンのファイル名を変更する。

• クライアント使用率が低い夜間に更新を実行する。

• 更新は小規模にとどめる。

• ファイルのコピーの数を最小限に抑える。

フェイルオーバー機能と NFS ロック

ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバーがロックを検出できないため、再マッピング時もロックは永続します。ファイルはもともと変更が許されないので、サーバー側でファイルをロックする必要はありません。

NFS Version 4 におけるクライアント側フェイルオーバー機能

NFS Version 4 では、ファイルサイズが違うまたはファイルタイプが同じでないために複製を確立できない場合、次のことが起こります。

1. ファイルが使用不能とマークされる。

2. 警告が表示される。

3. 複製されたマウントのファイルを使用するアプリケーションがシステムコール失敗を受け取る。

NFS Version 4 では、ディレクトリのサイズが異なっていてもレプリケーションエラーを受け取ることはありません。以前のバージョンの NFS では、この状態はエラーとして扱われ、再マッピングプロセスを妨げました。

さらに、NFS Version 4 では、ディレクトリ読み取り操作が不成功の場合、次にリストされたサーバーによって操作が行われます。以前のバージョンの NFS では、読み取り操作が不成功のときは、再マッピングが失敗し、プロセスは元のサーバーが使用可能になるまでハングアップします。

NFS サーバーログ機能のしくみ

NFS サーバーロギングは、NFS の読み取りと書き込み、およびこのファイルシステムを変更する操作の記録を提供します。これらのレコードは情報へのアクセスをトレースするのに利用できます。さらに、この記録は、情報へのアクセスを測定する定量的な方法を提供します。

ログ機能が有効になっているファイルシステムにアクセスすると、カーネルが raw データをバッファーファイルに書き込みます。このデータには、次の内容が含まれています。

• タイムスタンプ

• クライアント IP アドレス

• 要求者の UID

• アクセスされているファイルまたはディレクトリオブジェクトのファイルハンドル

• 発生した操作のタイプ

nfslogd デーモンはこの raw データを、ログファイルに保存される ASCII レコードに変換します。使用可能なネームサービス機能が一致しているものを見つけると、その変換中に IP アドレスはホスト名に変更され、UID はログインに変更されます。ファイルハンドルはパス名にも変換されます。デーモンはファイルハンドルを追跡し、情報を別のファイルハンドルパステーブルに保存して、変換を完了します。このようにすると、ファイルハンドルにアクセスされるたびに、パスを識別し直す必要がなくなります。nfslogd が無効になっている場合はファイルハンドル - パステーブル内のマッピングへの変更が行われないため、このデーモンは実行したままにする必要があります。

WebNFS サービスのしくみ

WebNFS サービスとは、あるディレクトリに置かれたファイルを、公開ファイルハンドルを使ってクライアントからアクセスできるようにするものです。ファイルハンドルは、NFS クライアントがファイルを識別できるようにカーネルが生成するアドレスです。公開ファイルハンドルの値はあらかじめ定義されているため、サーバーがクライアントに対してファイルハンドルを生成する必要はありません。定義済みのファイルハンドルを使用するというこの機能によって、MOUNT プロトコルが不要になってネットワークトラフィックが減り、クライアントにとってはプロセスが高速化します。

デフォルトでは、NFS サーバーの公開ファイルハンドルはルートファイルシステムに対して設定されます。このデフォルトのため、サーバーに対してマウント権限を持っているすべてのクライアントに対して WebNFS アクセス権が与えられます。公開ファイルハンドルは、share コマンドによって任意のファイルシステムに切り替えることができます。

ファイルシステムに対するファイルハンドルを NFS クライアントが持っているとき、アクセスするファイルに対応するファイルハンドルを判断するために LOOKUP が実行されます。NFS プロトコルでは、パス名のコンポーネントを 1 度に 1 つしか評価できません。したがって、ディレクトリ階層のレベルが 1 つ増えるたびに 1 回ずつ LOOKUP を実行します。LOOKUP が公開ファイルハンドルへの相対パスのときは、WebNFS サーバーは単一マルチコンポーネントルックアップトランザクションでパス名全体を評価できます。WebNFS サーバーはマルチコンポーネントルックアップにより、パス名内でディレクトリレベルごとにファイルハンドルを交換せずに、目的のファイルにファイルハンドルを配布できます。

また、NFS クライアントは、単一の TCP 接続を介して、複数のファイルを同時にダウンロードすることができます。このようにして接続すると、サーバーに複数の接続を設定することによる負荷をかけることなく、すばやくアクセスすることができます。Web ブラウザアプリケーションも複数ファイルを同時にダウンロードできますが、それぞれのファイルに独自の接続が確立されます。WebNFS ソフトウェアは接続を 1 つしか使用しないため、サーバーに対するオーバーヘッドを軽減できます。

パス名の中の最後のコンポーネントが他のファイルシステムに対するシンボリックリンクである場合、通常の NFS アクティビティーによってあらかじめそのファイルへのアクセス権を持っていれば、クライアントはそのファイルにアクセスできます。

通常、NFS URL は公開ファイルハンドルからの相対位置として評価されます。評価をサーバーのルートファイルシステムへの相対パスに変更するには、パスの先頭にスラッシュを追加してください。次の 2 つの NFS URL は、公開ファイルハンドルが /export/ftp ファイルシステムで確立されている場合は同等です。

nfs://server/junk
nfs://server//export/ftp/junk

WebNFS セキュリティーネゴシエーション機能のしくみ

NFS サービスには、WebNFS クライアントが WebNFS サーバーと、選択されたセキュリティーメカニズムについてネゴシエーションできるようにするプロトコルが含まれています。この新しいプロトコルは、以前のバージョンの WebNFS プロトコルで使用されていたマルチコンポーネントルックアップの拡張である、セキュリティーネゴシエーションマルチコンポーネントルックアップを使用します。

WebNFS クライアントは、公開ファイルハンドルを使って通常のマルチコンポーネントルックアップ要求を行うことにより、このプロセスを開始します。このクライアントには、サーバーがどのようにしてこのパスを保護しているかについての知識がないため、デフォルトのセキュリティーメカニズムが使用されます。デフォルトセキュリティーメカニズムでは不十分な場合は、サーバーは AUTH_TOOWEAK エラーを返します。クライアントはより強力なメカニズムを使用する必要があることを意味しています。

クライアントは、AUTH_TOOWEAK エラーを受信すると、サーバーに対してどのセキュリティーメカニズムが必要か決定するように要求します。この要求が成功すると、サーバーは、指定されたパスに必要なセキュリティーメカニズムの配列を返します。このセキュリティーメカニズムの配列のサイズによっては、クライアントは完全な配列を得るためにさらに要求を出さなければならない場合があります。サーバーが WebNFS セキュリティーネゴシエーションをサポートしていない場合は、この要求は失敗します。

要求が成功すると、WebNFS クライアントは、クライアントがサポートしている最初のセキュリティーメカニズムを配列から選択します。クライアントはその後、選択したセキュリティーメカニズムを使用して、通常のマルチコンポーネントルックアップ要求を発行し、ファイルハンドルを獲得します。この後に続くすべての NFS 要求は、選択されたセキュリティーメカニズムとファイルハンドルを使って出されます。

Web ブラウザの使用と比較した場合の WebNFS の制約

HTTP を使用する Web サイトが提供できる機能のいくつかは、WebNFS ソフトウェアではサポートされていません。この違いは NFS サーバーがファイルを送信するだけであるという事実に由来するため、クライアント側で特別な処理を行う必要があります。ある Web サイトを WebNFS と HTTP 両方のアクセスに対応させるには、次を考慮してください。

• NFS によるブラウズでは CGI スクリプトは実行されません。したがって、CGI スクリプトを多用している Web サイトを含むファイルシステムは、NFS によるブラウズに適していない可能性があります。

• 新しい NFS URL から異なるファイル形式のこれらのファイルにアクセスすると、ファイル名からファイルタイプが判別可能な場合には外部のビューアが起動されます。WebNFS ソフトウェアはファイル内部をチェックしてファイルタイプを判別することはしないため、ファイルタイプを判別する唯一の方法はファイル名拡張子です。ブラウザは、標準 MIME タイプについてはファイル名拡張子を認識するはずです。

• NFS ブラウズではサーバー側イメージマップを使用できませんが、クライアント側イメージマップは使用できます (URL が場所で定義されているため)。ドキュメントサーバーからの応答は不要です。

Secure NFS システム

NFS 環境は、アーキテクチャーやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するための強力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティー上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使用してきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証を使用している場合、NFS サーバーはユーザーではなくファイル要求を行ったコンピュータを認証することで要求を認証します。したがって、NFS クライアントユーザーはスーパーユーザーになるために suを実行し、ファイルの所有者を偽装できます。DH 認証では、NFS サーバーはユーザーを認証するため、このような操作が困難になります。

ルートアクセス権とネットワークプログラミングについての知識があれば、だれでも任意のデータをネットワークに取り入れたり、任意のデータをネットワークから取り出したりできます。もっとも危険な攻撃にはデータの持ち込みが伴います。たとえば、有効なパケットを生成したり、または「対話」を記録し後で再生することによってユーザーを装うなどの手段があります。これらはデータの整合性に影響を与えます。ユーザーを装わず、単にネットワークトラフィックを傍受するための受動的な盗聴が行われる攻撃であれば、データの整合性が損なわれることはないため、それほど危険ではありません。ネットワーク上でやりとりされるデータを暗号化すると、機密情報のプライバシを保護できます。

ネットワークのセキュリティー問題に対する共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。

Oracle Solaris オペレーティングシステムには、NFS の操作が構築されるメカニズムである RPC のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティーを大幅に向上させるとともに、NFS のセキュリティーを強化します。Secure RPC が提供する機能を利用した NFS システムを Secure NFS システムといいます。

Secure RPC

Secure RPC は Secure NFS システムの基盤です。Secure RPC の目標は、少なくともタイムシェアリングシステム程度に安全なシステムを構築することです。タイムシェアリングシステムでは、すべてのユーザーが 1 つのコンピュータを共有し、ユーザーはログインパスワードによって認証されます。データ暗号化規格 (DES) 認証でも、同じ認証処理が実行されます。ユーザーは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザーのログインパスワードは、ネットワークセキュリティーへの保証です。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更してだれかを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。

RPC 認証システムは、資格とベリファイアを使用します。ID バッジを例にとれば、 資格とは、名前、住所、誕生日など個人を識別するものです。ベリファイアとはバッジに添付された写真です。バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバーに送信します。クライアントはサーバーの資格をすでに知っているため、サーバーはベリファイアだけを送り返します。

RPC の認証は拡張が可能で、UNIX、DH、および KERB などのさまざまな認証システムを組み込むことができます。

ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのホスト名、UID、GID、グループアクセスリストが含まれます。ただし、ベリファイアが存在しないため、スーパーユーザーは su などのコマンドを使用して、適切な資格を偽ることができます。もう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内の他のオペレーティングシステムに適用した場合、これは正常に動作しません。

UNIX 認証の問題を克服するために、Secure RPC では DH 認証を使用します。

DH 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使ってネットワーク上のユーザーとコンピュータの両方を認証します。DES は、標準の暗号化メカニズムです。Diffie-Hellman 公開鍵暗号手法は、2 つの鍵、つまり公開鍵と秘密鍵を持つ暗号方式です。 公開鍵と秘密鍵は名前空間に格納されます。NIS では、これらの鍵は public-key マップに保存されています。これらのマップにはすべての認証の候補ユーザーの公開鍵と秘密鍵が入っています。マップの設定方法に関する詳細は、Oracle Solaris 11.3 ディレクトリサービスとネームサービスでの作業: DNS と NISを参照してください。

DH 認証のセキュリティーは、送信側が現在時間を暗号化する機能に基づいていて、受信側はこれを復号化して、自分の時間と照合します。タイムスタンプは DES を使用して暗号化されます。2 つのエージェントは現在の時間で同意し、送信側と受信側が同じ暗号化鍵を使用する必要があます。

ネットワークが時間同期プログラムを実行する場合、NFS クライアントと NFS サーバー上の時間は自動的に同期がとられます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバーの時間を使ってタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバーに時間を要求し、自分のクロックとサーバーのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使ってクライアントのクロックを補正します。クライアントとサーバーのクロックが同期しなくなると、サーバーはクライアントの要求を拒否し始めます。その場合、クライアントの DH 認証システムはサーバーとの間で再び同期をとります。

クライアントとサーバーは、ランダムな対話鍵 (セッション鍵とも呼ばれる) を生成したあと公開鍵暗号方式を使って共通鍵を類推することによって、同一の暗号化鍵に到達します。この共通鍵は、クライアントとサーバーだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。

NFS での Secure RPC の使用

Secure RPC を使用する予定の場合は、次の点を考慮してください。

• NFS サーバーがクラッシュしたときにシステム管理者がいない場合 (停電のあとなど) には、システムに格納されていた秘密鍵がすべて削除されます。どのプロセスからも、セキュアなネットワークサービスにアクセスしたり NFS ファイルシステムをマウントしたりできません。リブート中の重要な処理は、通常 root として実行されます。そのため、root の秘密鍵を別に保存していればこれらのプロセスを実行できますが、その秘密鍵を復号化するパスワードを入力することはできません。keylogin -r を使用すると root の秘密鍵がそのまま /etc/.rootkey に格納され、keyserv がそれを読み取ります。

• システムによっては、シングルユーザーモードでブートし、コンソールには root のログインシェルが表示されてパスワードの入力が要求されないことがあります。このような場合は、物理的なセキュリティーが不可欠です。

• ディスクレスコンピュータのブートは、完全に安全とはいえません。ブートサーバーになりすましてリモートコンピュータで秘密鍵を記録するような、不正なカーネルをだれかがブートする可能性があります。Secure NFS システムによって保護されているのはカーネルと鍵サーバーが起動した後だけです。そうでないと、ブートサーバーからの応答を認証することができません。この制限は重大な問題につながる可能性がありますが、この制限を攻撃するにはカーネルのソースコードを使用した高度な技術が必要です。また、不法行為の痕跡が残ります。つまり、ネットワークを通じてブートサーバーにポーリングすれば、不正なブートサーバーの場所がわかります。

• 多くの setuid プログラムは root が所有者です。root の秘密鍵が /etc/.rootkey に格納されていれば、これらのプログラムは正常に動作します。しかし、ユーザーが所有者である setuid プログラムは動作しない可能性があります。たとえば、ある setuid プログラムの所有者が dave であり、ブート後 dave が 1 度もログインしていないとします。このプログラムはセキュアなネットワークサービスにはアクセスできません。

• リモートコンピュータに (login、rlogin、または telnet を使用して) ログインし、keylogin を使ってアクセスすると、自分のアカウントへのアクセスを提供することになります。秘密鍵がそのコンピュータの鍵サーバーに渡され、その秘密鍵が格納されます。このプロセスが問題になるのは、相手側のリモートコンピュータを信用できない場合だけです。しかし、疑いがある場合は、パスワードを要求するリモートコンピュータにはログインしないでください。代わりに NFS 環境を使用して、そのリモートコンピュータから共有されているファイルシステムをマウントします。または、keylogout を使って鍵サーバーから秘密鍵を消去します。

• ホームディレクトリが –o sec=dh オプションにより共有されていると、リモートログインによって問題が生じる可能性があります。/etc/hosts.equiv ファイルまたは ~/.rhosts ファイルに、パスワードを要求するように設定されていない場合は、ログインが成功します。ただし、ローカルで認証されていないため、ユーザーは自分のホームディレクトリにアクセスできません。ユーザーがパスワードを要求される場合には、パスワードがネットワークパスワードと一致すれば自分のホームディレクトリにアクセスできます。