パート V 認証サービスと安全な通信

このパートでは、ネットワークに接続されていないシステム、または 2 つのシステム間で設定される認証サービスについて説明します。認証されたユーザーとシステムのネットワークを設定するには、パート VI「Kerberos サービス」を参照してください。

第 16 章 認証サービスの使用 (手順)

この章では、Secure RPC を使用して NFS マウントでホストとユーザーを認証する方法について説明します。この章で説明する内容は次のとおりです。

• 「Secure RPC の概要」

• 「Secure RPC の管理 (作業マップ)」

Secure RPC の概要

Secure RPC (遠隔手続き呼び出し) は、認証メカニズムによって遠隔手続きを保護します。Diffie-Hellman 認証メカニズムは、サービスを要求するホストとユーザーを認証します。この認証メカニズムはデータ暗号化規格 (Data Encryption Standard、DES) 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS、およびネームサービスの NIS と NIS+ があります。

NFS サービスと Secure RPC

NFS を使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS サービスでは、サーバーは、複数のクライアントから利用できるデータとリソースを保持します。クライアントは、サーバーがクライアントと共有するファイルシステムにアクセスできます。クライアントシステムにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントシステム上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS のもっとも一般的な使用形態の 1 つは、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理することです。mount コマンドの -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限を持たないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。

NFS サービスでは Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。このプロセスは、Secure NFS と呼ばれます。Diffie-Hellman 認証メカニズム AUTH_DH は、DES 暗号化を使用し、承認されたアクセスを保証します。AUTH_DH メカニズムは、AUTH_DES とも呼ばれます。詳細については、次を参照してください。

• Secure NFS の設定と管理については、『Solaris のシステム管理 (ネットワークサービス)』の「Secure NFS システムの管理」を参照してください。

• NIS+ テーブルの設定と cred テーブルへの名前の入力については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

• RPC 認証トランザクションの概要については、「Diffie-Hellman 認証の実装」を参照してください。

Secure NFS での DES 暗号化

データ暗号化規格 (Data Encryption Standard、DES) 暗号化機能は 56 ビットの鍵を使用して、データを暗号化します。資格を持つ 2 人のユーザー、すなわち主体が同じ DES 鍵を知っている場合、その鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化メカニズムです。DES チップは暗号化をより高速にします。ただし、チップがなくても、ソフトウェアで代用できます。

DES 鍵を使用する上での問題点は、同じ鍵で暗号化された多数のテキストメッセージを侵入者が収集することによって、鍵が発見されてメッセージが解読される危険性があるということです。このため、Secure NFS などのセキュリティーシステムは鍵を頻繁に変更する必要があります。

Kerberos 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos には DES に基づく暗号化もあります。Kerberos V4 は、Secure RPC ではサポートされていません。クライアント側とサーバー側には、RPCSEC_GSS を使用する Kerberos V5 がこのリリースに実装されています。詳細については、第 21 章Kerberos サービスについてを参照してください。

Diffie-Hellman 認証と Secure RPC

Diffie-Hellman (DH) のユーザー認証方式は簡単には破られません。クライアントとサーバーは、独自の非公開鍵と公開鍵を使って共通鍵を作り出します。非公開鍵は秘密鍵とも呼ばれます。クライアントとサーバーは、共通鍵を使って相互に通信します。共通鍵は、相互に合意した暗号化機能 (DES など) によって暗号化されます。

認証では、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期している必要があります。詳細については、『Solaris のシステム管理 (ネットワークサービス)』の「NTP の管理 (作業)」を参照してください。

公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、これらの鍵を publickey マップに格納します。NIS+ では、cred テーブルに格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。

システム管理者は、NIS マップまたは NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する必要があります。非公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これにより、その非公開鍵はそのユーザーだけが知っていることになります。

Diffie-Hellman 認証の実装

この節では、Diffie-Hellman 認証 (AUTH_DH) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。

Secure RPC 用の公開鍵と秘密鍵を生成

システム管理者は、認証を開始する前に、newkey または nisaddcred コマンドを実行して公開鍵と秘密鍵を生成します。ユーザーごとに一意の公開鍵と秘密鍵が与えられます。公開鍵は、公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。chkey コマンドは、公開鍵と秘密鍵のペアを変更します。

Secure RPC 用に keylogin コマンドを実行する

通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin コマンドは必要ありません。ただし、これらのパスワードが異なる場合は、ユーザーはログインしたあとに keylogin コマンドを実行する必要があります。

keylogin コマンドを入力すると、Secure RPC パスワードの入力を求めるプロンプトが表示されます。コマンドは、このパスワードを使って秘密鍵を復号化します。次に keylogin コマンドは、復号化された秘密鍵をキーサーバープログラムに渡します。キーサーバーは、各コンピュータ上でローカルインスタンスを伴う RPC サービスです。キーサーバーは、復号化された秘密鍵を格納し、ユーザーとサーバーが Secure RPC トランザクションを開始するのを待機します。

ログインパスワードと RPC パスワードが一致している場合は、ログインプロセスは秘密鍵をキーサーバーに渡します。これらのパスワードが異なる場合は、ユーザーが常に keylogin コマンドを実行する必要があります。keylogin コマンドをユーザーの環境構成ファイル ( ~/.login、~/.cshrc、~/.profile ファイルなど) に設定すると、ユーザーがログインしたときに、keylogin コマンドが自動的に実行されます。

Secure RPC 用の対話鍵の生成

ユーザーがサーバーとトランザクションを開始すると、次の処理が行われます。

1. キーサーバーはランダムに対話鍵を生成します。

2. カーネルは、この対話鍵などを使用してクライアントのタイムスタンプを暗号化します。

3. キーサーバーは、公開鍵データベースからサーバーの公開鍵を検索します。詳細は、publickey(4) のマニュアルページを参照してください。

4. キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。

5. キーサーバーは共通鍵を使用して対話鍵を暗号化します。

Secure RPC におけるサーバーとの最初の通信

次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。

• クライアントのネットワーク名

• 共通鍵で暗号化された対話鍵

• 対話鍵で暗号化された「ウィンドウ」

この場合の「ウィンドウ」とは、サーバーの時刻とクライアントのタイムスタンプとの間で許容される時間差のことで、クライアントが指定します。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。通常の状態では、クライアントは RPC セッションを開始する前にサーバーと同期を取るため、クライアントの要求は拒否されません。

クライアントベリファイアは、次の要素で構成されます。

• 暗号化されたタイムスタンプ

• 指定したウィンドウから 1 を引いた値の暗号化されたベリファイア

ウィンドウベリファイアは、他人がユーザーになりすますのを防ぐために使用されます。なりすましを試みる人は、資格やベリファイアの暗号化された各フィールドに正しい情報の代わりにランダムなビットを挿入するプログラムを作成します。サーバーはこの対話鍵を任意のランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。結果は、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウとタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、偽の資格が認証される可能性を小さくします。

Secure RPC における対話鍵の復号化

サーバーがクライアントから伝送データを受信すると、次の処理が行われます。

1. キーサーバーは、公開鍵データベース内でクライアントの公開鍵を検索します。

2. キーサーバーはクライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計 算します。この共通鍵はクライアントが計算したものと同じです。共通鍵の計算は、秘密鍵の 1 つを知っている必要があるため、そのサーバーとクライアント以外は計算できません。

3. カーネルは共通鍵を使用して、対話鍵を復号化します。

4. カーネルはキーサーバーを呼び出して、復号化された対話鍵によりクライアントのタイムスタンプを復号化します。

Secure RPC におけるサーバーへの情報の格納

サーバーは、クライアントのタイムスタンプを復号化したあと、次の 4 つの情報を資格テーブルに格納します。

• クライアントのコンピュータ名

• 対話鍵

• ウィンドウ

• クライアントのタイムスタンプ

サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはクライアントのタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的にあとのタイムスタンプだけを受け付けます。結果として、すでに届いたトランザクションと同じタイムスタンプを持つトランザクションはすべて拒否されることが保証されます。

このトランザクションにおいて暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証する必要があります。キーサーバーは、呼び出し側を認証するときに、DES 認証を使用できません。キーサーバーが DES 認証を使用すると、デッドロックが発生するためです。キーサーバーは、ユーザー ID (UID) ごとに秘密鍵を格納し、ローカルの root のプロセスへの要求だけを認可することによってデッドロックを回避します。

Secure RPC でベリファイアをクライアントに返す

サーバーは、ベリファイアをクライアントに返します。ベリファイアには、次の構成要素が含まれます。

• サーバーが自分の資格キャッシュに記録するインデックス ID

• クライアントのタイムスタンプから 1 を引いた値。対話鍵によって暗号化されます

クライアントのタイムスタンプから 1 を引くのは、タイムスタンプを期限切れにするためです。期限切れのタイムスタンプはクライアントのベリファイアとして再利用できません。

Secure RPC におけるサーバーの認証

クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。

Secure RPC におけるトランザクションの処理

2 番目以降のすべてのトランザクションごとに、クライアントは次のトランザクションでインデックス ID をサーバーに返します。クライアントは、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いた値を対話鍵で暗号化して、返信します。

Secure RPC の管理 (作業マップ)

次の作業マップでは、NIS、NIS+、および NFS に対して Secure RPC を構成する手順を示します。

Secure RPC による認証の管理

マウントされた NFS ファイルシステムの使用に対する認証を要求することにより、ネットワークのセキュリティーが増します。

Secure RPC キーサーバーを再起動する方法

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. keyserv デーモンが動作していることを検証します。

   # svcs \*keyserv\* STATE STIME FMRI disabled Dec_14 svc:/network/rpc/keyserv

3. キーサーバーサービスがオンラインになっていない場合は、サービスを有効にします。

   # svcadm enable network/rpc/keyserv

NIS+ ホストに Diffie-Hellman 鍵を設定する方法

この手順は、NIS+ ドメインのすべてのホストで実行します。root が keylogin コマンドを実行すると、サーバーはmech_dhに対して GSS-API のアクセプタの資格をもち、クライアントは GSS-API のイニシエータの資格を持ちます。

NIS+ セキュリティーの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. ネームサービスの publickey テーブルを有効にします。

   次の行を /etc/nsswitch.conf ファイルに追加します。

   publickey: nisplus

3. NIS+ クライアントを起動します。

   # nisinit -cH hostname

   hostname は、そのテーブルにクライアントシステム用のエントリを持つ、信頼されている NIS+ サーバー名です。

4. クライアントを cred テーブルに追加します。

   次のコマンドを入力します。

   # nisaddcred local # nisaddcred des

5. keylogin コマンドを使用して、設定を確認します。

   パスワードを求めるプロンプトが出力されたら、この手順は成功です。

   # keylogin Password:

例 16–1 NIS+ クライアント上で root の新しい鍵を設定する

次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth がセキュリティー保護された NIS+ クライアントとして正しく設定されていることを確認しています。

# nisinit -cH pluto
NIS Server/Client setup utility.
This system is in the example.com. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@example.com
Adding new key for unix.earth@example.com (earth.example.com.)
Network password:<Type password>
Warning, password differs from login password.
Retype password: <Retype password>
# keylogin
Password:        <Type password>
#

NIS+ ユーザーに Diffie-Hellman 鍵を設定する方法

この手順は、NIS+ ドメインのすべてのユーザーで実行します。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. ユーザーをルートマスターサーバー上の cred テーブルに追加します。

   次のコマンドを入力します。

   # nisaddcred -p unix.UID@domain-name -P username.domain-name. des

   この場合、username.domain-name の終わりにピリオド (.) を付けてください。

3. クライアントとしてログインし、keylogin コマンドを入力して、設定を確認します。

例 16–2 NIS+ ユーザー用の新しい鍵を設定する

次の例では、Diffie-Hellman 認証用の鍵をユーザー jdoe に与えます。

# nisaddcred -p unix.1234@example.com -P jdoe.example.com. des
DES principal name : unix.1234@example.com
Adding new key for unix.1234@example.com (jdoe.example.com.)
Password:       <Type password>
Retype password:<Retype password>
# rlogin rootmaster -l jdoe
% keylogin
Password:       <Type password>
%

NIS ホストに Diffie-Hellman 鍵を設定する方法

この手順は、NIS ドメインのすべてのホストで実行します。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. ネームサービスの publickey マップを有効にします。

   次の行を /etc/nsswitch.conf ファイルに追加します。

   publickey: nis

3. newkey コマンドを使用して、新しい鍵のペアを作成します。

   # newkey -h hostname

   hostname は、クライアント名です。

例 16–3 NIS クライアント上で root の新しい鍵を設定する

次の例では、earth をセキュリティー保護された NIS クライアントとして設定します。

# newkey -h earth
Adding new key for unix.earth@example.com
New Password:   <Type password>
Retype password:<Retype password>
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

NIS ユーザーに Diffie-Hellman 鍵を設定する方法

この手順は、NIS ドメインの各ユーザーに対して実行します。

始める前に

システム管理者だけが NIS マスターサーバーにログインしたときに、ユーザーの新しい鍵を作成できます。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. ユーザーの新しい鍵を作成します。

   # newkey -u username

   username はユーザー名です。システムはパスワードを求めるプロンプトを出します。汎用パスワードを入力できます。非公開鍵は、汎用パスワードを使用して暗号化されて格納されます。

3. ユーザーに、ログインして chkey -p コマンドを入力するように伝えます。

   このコマンドでは、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を暗号化し直すことができます。

   ---

   注 –

   chkey コマンドを使用すると、新しい鍵のペアをユーザーに作成できます。

   ---

例 16–4 NIS で新しいユーザー鍵を設定して暗号化する

この例では、スーパーユーザーが鍵を設定します。

# newkey -u jdoe
Adding new key for unix.12345@example.com
New Password:   <Type password>
Retype password:<Retype password>
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

次に、ユーザー jdoe が非公開パスワードで鍵を再暗号化します。

% chkey -p
Updating nis publickey database.
Reencrypting key for unix.12345@example.com
Please enter the Secure-RPC password for jdoe:<Type password>
Please enter the login password for jdoe:     <Type password>
Sending key change request to centralexample...

Diffie-Hellman 認証で NFS ファイルを共有する方法

この手順では、アクセスに対する認証を要求することにより、NFS サーバー上で共有されているファイルシステムを保護します。

始める前に

Diffie-Hellman の公開鍵認証がネットワークで有効である必要があります。ネットワークで認証を有効にするには、次のいずれかを行います。

• 「NIS+ ホストに Diffie-Hellman 鍵を設定する方法」

• 「NIS ホストに Diffie-Hellman 鍵を設定する方法」

1. スーパーユーザーになるか、System Management プロファイルを含む役割を引き受けます。

   System Administrator 役割には、System Management プロファイルが含まれます。役割を作成し、作成した役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

2. NFS サーバーで、 Diffie-Hellman 認証でファイルシステムを共有します。

   # share -F nfs -o sec=dh /filesystem

   filesystem は、共有されているファイルシステムです。

   -o sec=dh オプションは、ファイルシステムにアクセスするために AUTH_DH 認証が必要になるということです。

3. NFS クライアントで、Diffie-Hellman 認証でファイルシステムをマウントします。

   # mount -F nfs -o sec=dh server:filesystem mount-point

   server

   filesystem を共有しているシステムの名前です

   filesystem

   /opt など、共有されているファイルシステムの名前です

   mount-point

   /opt など、マウントポイントの名前です

   -o sec=dh オプションにより、AUTH_DH 認証を使ってファイルシステムがマウントされます。

第 17 章 PAM の使用

この章では、プラグイン可能認証モジュール (PAM) フレームワークについて説明します。PAM は、認証サービスを Solaris オペレーティングシステム (Solaris OS) に「プラグイン」する方法を提供します。PAM によって、システムへのアクセス時に複数の認証サービスを使用できるようになります。

• 「PAM (概要)」

• 「PAM (手順)」

• 「PAM の構成 (参照)」

PAM (概要)

プラグイン可能認証モジュール (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムに入るためのサービスを変更しなくても、新しい認証サービスを「プラグイン」できるようになります。また、PAM を使用すると、UNIX ログインを Kerberos などほかのセキュリティーメカニズムと統合できます。また、アカウント、資格、セッション、およびパスワードの管理メカニズムも「プラグイン」できます。

PAM を使用する利点

PAM フレームワークを使用すると、システムに入るためのサービス (ftp、login、telnet、rsh など) のユーザー認証を構成できます。PAM には次の利点があります。

• 柔軟な構成ポリシー

  • アプリケーションごとの認証ポリシー

  • デフォルトの認証メカニズムを選択する機能

  • 高度なセキュリティーシステムにおいて複数の承認を要求する機能

• 一般ユーザーにも使いやすい

  • 認証サービスが異なってもパスワードが同じであれば、パスワードを再入力する必要がない

  • ユーザーが複数のコマンドを入力しなくても、複数の認証方式のパスワードを求めるプロンプトを表示できる

• 任意のオプションをユーザー認証サービスに渡す機能

• システムに入るためのサービスを変更しなくても、サイト固有のセキュリティーポリシーを実装する機能

PAM フレームワークの概要

PAM フレームワークは次の 4 つの部分から成ります。

• PAM コンシューマ

• PAM ライブラリ

• pam.conf(4) 構成ファイル

• PAM サービスモジュール。プロバイダとも呼ばれる

このフレームワークは、認証関連アクティビティーの統一的な実施手段を提供します。このアプローチを使えば、アプリケーション開発者は、PAM サービスのポリシーの意味を知らなくてもサービスを使用できるようになります。アルゴリズムは一元的に提供されます。アルゴリズムの変更は、個々のアプリケーションとは無関係に行えます。PAM を使えば、管理者は、アプリケーションを変更しないで、特定システムのニーズに合わせて認証プロセスを調整できるようになります。この調整は、PAM 構成ファイル pam.conf を通じて行われます。

次の図は、PAM のアーキテクチャーを示したものです。アプリケーションは、PAM アプリケーションプログラミングインタフェース (API) 経由で PAM ライブラリと通信します。PAM モジュールは、PAM サービスプロバイダインタフェース (SPI) 経由で PAM ライブラリと通信します。したがって、PAM ライブラリを使えば、アプリケーションとモジュールとの相互通信を実現できます。

図 17–1 PAM のアーキテクチャー

Solaris 10 リリースにおける PAM への変更

Solaris 10 リリースには、プラグイン可能認証モジュール (PAM) フレームワークに対する、次のような変更が含まれています。

• pam_authtok_check モジュールが、/etc/default/passwd ファイルの新しい調整可能なパラメータを使用して、厳しいパスワードチェックができるようになりました。新しいパラメータは次を定義します。

  • パスワードの共通辞書ワードをチェックするために使用する、コンマで区切られた辞書ファイルのリスト

  • 新しいパスワードと古いパスワードの間に必要な最小限の差異

  • 新しいパスワードで使用する必要がある英字または英字以外の最小文字数

  • 新しいパスワードで使用する必要がある大文字または小文字の最小文字数

  • 許容できる連続的に繰り返される文字の数

• pam_unix_auth モジュールが、ローカルユーザーに対するアカウントロックを実装しています。アカウントロックは、/etc/security/policy.conf の LOCK_AFTER_RETRIES パラメータおよび /etc/user_attr の lock_after-retries 鍵によって有効になります。詳細は、policy.conf(4) および user_attr(4) のマニュアルページを参照してください。

• 新しいbinding 制御フラグが定義されました。この制御フラグについては、pam.conf(4) のマニュアルページおよび 「PAM スタックのしくみ」に記載されています。

• pam_unix モジュールが削除され、同等またはそれ以上の機能を備えた一連のサービスモジュールで置き換えられました。これらのモジュールの多くは、Solaris 9 リリースで導入されました。置き換え後のモジュールのリストは、次のとおりです。

  • pam_authtok_check

  • pam_authtok_get

  • pam_authtok_store

  • pam_dhkeys

  • pam_passwd_auth

  • pam_unix_account

  • pam_unix_auth

  • pam_unix_cred

  • pam_unix_session

• 以前の pam_unix_auth モジュールの機能は、2 つのモジュールに分割されました。pam_unix_auth モジュールは、ユーザーのパスワードが正しいかどうかを検証するように変更されました。新しく追加された pam_unix_cred モジュールは、ユーザーの資格情報を確立する機能を提供します。

• pam_krb5 モジュールに、PAM フレームワークを使って Kerberos 資格キャッシュを管理する機能が追加されました。

• 新しい pam_deny モジュールが追加されました。このモジュールは、サービスへのアクセスを拒否するために使用できます。デフォルトでは、pam_deny モジュールは無効になっています。詳細は、pam_deny(5) のマニュアルページを参照してください。

PAM (手順)

この節では、PAM のフレームワークが特定のセキュリティーポリシーを使用するために必要な作業について説明します。PAM 構成ファイルに関連するセキュリティーのいくつかの問題について注意する必要があります。セキュリティーの問題については、「PAM の実装計画」を参照してください。

PAM (作業マップ)

PAM の実装計画

配布時に、pam.conf 構成ファイルは Solaris の標準的なセキュリティーポリシーを実装します。このポリシーは、多くの状況で機能します。別のセキュリティーポリシーを実装する必要がある場合に注意すべき問題は、次のとおりです。

• 何が必要か、特にどの PAM サービスモジュールを選択するかを決定します。

• 特別な構成オプションが必要なサービスを確認します。適宜、other を使用します。

• モジュールを実行する順番を決定します。

• 各モジュールに対する制御フラグを選択します。すべての制御フラグの詳細については、「PAM スタックのしくみ」を参照してください。

• 各モジュールに必要なオプションを選択します。各モジュールのマニュアルページには、特別なオプションが一覧表示されます。

ここで、PAM 構成ファイルを変更する前に次のことを考慮することをお勧めします。

• /etc/pam.conf ですべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに other エントリを使用します。

• binding、sufficient、および optional 制御フラグのセキュリティーへの影響を確認します。

• モジュールに関連するマニュアルページを参照します。これらのマニュアルページには、各モジュールの機能、使用可能なオプション、スタック内のモジュール間の相互作用などの説明があります。

  ---

  注意 –

  PAM 構成ファイルの構成を間違えたり壊したりすると、どのユーザーもログインできなくなる可能性があります。この場合、sulogin コマンドは PAM を使用しないので、root パスワードを使用してマシンをシングルユーザーモードでブートして問題を解決する必要があります。

  ---

  /etc/pam.conf ファイルを変更したあと、システムにアクセスできる間にできる限り調査して問題を解決します。変更によって影響を受ける可能性があるコマンドは、すべてテストしてください。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行った変更が期待どおりに動作しているかどうかを検証します。

PAM モジュールを追加する方法

この手順では、新しい PAM モジュールを追加する方法を示します。新しいモジュールは、サイト固有のセキュリティーポリシーを網羅するためや、Sun 以外のアプリケーションをサポートするために作成します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

2. 使用する制御フラグとオプションを決定します。

   制御フラグについては、「PAM スタックのしくみ」を参照してください。

3. モジュールファイルの所有者が root で、そのアクセス権が 555 になるように設定します。

4. PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。

5. モジュールが適切に追加されたことを検証します。

   構成ファイルが間違って構成されているおそれもあるので、システムをリブートする前にテストを行う必要があります。システムをリブートする前に、ssh などの直接サービスを使用してログインし、su コマンドを実行します。サービスは、システムをブートしたときに 1 度だけ生成されるデーモンである場合があります。その場合には、システムをリブートしてから、モジュールが追加されていることを確認する必要があります。

PAM を使用して、遠隔システムからの rhost 式アクセスを防ぐ方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

2. rhosts_auth.so.1 を含む行をすべて PAM 構成ファイルから削除します。

   この手順によって、rlogin セッション中、~/.rhosts ファイルは読み取られなくなります。これにより、ローカルシステムに認証されていない遠隔システムからのアクセスを防止できます。~/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにはパスワードが必要になります。

3. rsh サービスを無効にします。

   ~/.rhosts ファイルへのその他の非承認アクセスを防ぐには、rsh サービスも無効にする必要があります。

   # svcadm disable network/shell

PAM のエラーレポートを記録する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

2. 必要な記録のレベルに /etc/syslog.conf ファイルを構成します。

   記録レベルの詳細については、syslog.conf(4) を参照してください。

3. syslog デーモンの構成情報を再表示します。

   # svcadm refresh system/system-log

PAM の構成 (参照)

login、rlogin、su、cron などのシステムサービスに対する PAM サービスモジュールを構成するには、PAM 構成ファイル pam.conf(4) を使用します。システム管理者がこのファイルを管理します。pam.conf 内のエントリの順番が間違っていると、予期しない副作用が生じる可能性があります。たとえば、pam.conf の設定が不適切であると、ユーザーがロックアウトされ、修復のためにシングルユーザーモードが必要になる可能性があります。順番の設定方法については、「PAM スタックのしくみ」を参照してください。

PAM 構成ファイルの構文

構成ファイル内のエントリの形式は、次のとおりです。

service-name module-type control-flag module-path module-options

service-name

サービスの名前。たとえば、ftp、login、または passwd などです。アプリケーションは、自身が提供するサービスごとに異なるサービス名を使用できます。たとえば、Solaris Secure Shell デーモンが使用するサービス名は次のとおりです。 sshd-none、sshd-password、sshd-kbdint、sshd-pubkey、sshd-hostbased。サービス名 other は事前に定義された名前であり、ワイルドカードのサービス名として使用されます。構成ファイル内で特定のサービス名が見つからない場合には、other の構成が使用されます。

module-type

サービスのタイプ。具体的には auth、account、session、password のいずれかです。

control-flag

サービスの統合された成功または失敗の値を決定するうえで、そのモジュールの果たす役割を示します。有効な制御フラグは、binding、include、optional、required、requisite、および sufficient です。制御フラグの使用方法については、「PAM スタックのしくみ」を参照してください。

module-path

サービスを実装しているライブラリオブジェクトへのパス。パス名が絶対パスでない場合、そのパス名は /usr/lib/security/$ISA/ に対する相対パスとみなされます。libpam による検索が、アプリケーションの特定のアーキテクチャーに対するディレクトリ内で行われるように、アーキテクチャーに依存するマクロ $ISA を使用します。

module-options

サービスモジュールに渡されるオプション。各モジュールのマニュアルページには、そのモジュールで使用できるオプションの説明があります。典型的なモジュールオプションとしては、nowarn や debug などがあります。

PAM スタックのしくみ

あるアプリケーションが次の関数を呼び出すと、libpam は構成ファイル /etc/pam.conf を読み取り、そのサービスの操作に関与するモジュールを決定します。

• pam_authenticate(3PAM)

• pam_acct_mgmt(3PAM)

• pam_setcred(3PAM)

• pam_open_session(3PAM)

• pam_close_session(3PAM)

• pam_chauthtok(3PAM)

認証管理やアカウント管理など、このサービスのある操作に対するモジュールが /etc/pam.conf に 1 つしか含まれていない場合、そのモジュールの結果によって、その操作の結果が決まります。たとえば、passwd アプリケーションのデフォルトの認証操作には、1 つのモジュール pam_passwd_auth.so.1 が含まれています。

passwd  auth required           pam_passwd_auth.so.1

これに対し、サービスのある操作に対して複数のモジュールが定義されている場合、それらのモジュールは「スタック」を形成しており、そのサービスに対する「PAM スタック」が存在している、と言います。たとえば、pam.conf に次のエントリが含まれる場合を考えます。

login   auth requisite          pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_cred.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

これらのエントリは、login サービスに対するサンプルの auth スタックを表現したものです。このスタックの結果を決定するには、個々のモジュールの結果コードに対して「統合プロセス」を実行する必要があります。統合プロセスでは、各モジュールが、/etc/pam.conf 内で指定された順番で実行されます。個々の成功コードまたは失敗コードが、モジュールの制御フラグに基づいて総合結果へと統合されます。制御フラグによっては、スタックの早期終了が発生する可能性があります。たとえば、requisite モジュールが失敗したり、sufficient モジュールや binding モジュールが成功したりする可能性があります。スタックの処理が完了すると、個々の結果が組み合わされて単一の総合結果が算出され、それがアプリケーションに渡されます。

制御フラグは、サービスへのアクセスを決定するうえで、ある PAM モジュールが果たす役割を示します。制御フラグとその効果は、次のとおりです。

• binding – binding モジュールの要件を満たすことに成功すると、その時点までの required モジュールがどれも失敗しなかった場合には、すぐにアプリケーションに成功が返されます。これらの条件が満たされると、後続のモジュールは実行されません。失敗すると、required 失敗が記録され、モジュールの処理が継続されます。

• include – 別の PAM 構成ファイルに含まれる行を追加し、それらの行がその時点で PAM スタック内で使用されるようにします。このフラグは成功または失敗の動作を制御しません。新しいファイルが読み取られると、PAM のインクルードスタックが 1 増やされます。新しいファイル内でのスタックチェックが完了すると、インクルードスタック値が 1 減らされます。ファイルの末尾に到達し、かつ PAM インクルードスタックが 0 であれば、スタック処理は終了します。PAM インクルードスタックの最大数は、32 です。

• optional – optional モジュールの要件を満たすことに成功することは、サービスを使用するために必要な条件ではありません。失敗すると、optional 失敗が記録されます。

• required – required モジュールの要件を満たすことに成功することは、サービスを使用するために必要な条件です。失敗すると、このサービスの残りのモジュールの実行完了後に、エラーが返されます。サービスの最終的な成功が返されるのは、binding または required モジュールがどれも失敗を報告しなかった場合だけです。

• requisite – requisite モジュールの要件を満たすことに成功することは、サービスを使用するために必要な条件です。失敗するとすぐにエラーが返され、後続のモジュールは実行されません。あるサービスのすべての requisite モジュールが成功を返さないと、この機能がアプリケーションに成功を返すことができません。

• sufficient – その時点までに required 失敗が一度も発生しなかった場合、sufficient モジュールが成功するとすぐにアプリケーションに成功が返され、後続のモジュールは実行されません。失敗すると、optional 失敗が記録されます。

次の 2 つの図は、統合プロセスでアクセスがどのように決定されるかを示したものです。最初の図は、制御フラグのタイプごとに成功または失敗がどのように記録されるのかを示しています。2 番目の図は、統合された値の決定方法を示しています。

図 17–2 PAM スタック: 制御フラグの効果

図 17–3 PAM スタック: 統合された値の決定方法

PAM スタックの例

次のような、認証を要求する rlogin サービスの例を考えます。

例 17–1 典型的な PAM 構成ファイルの内容の一部

この例の pam.conf ファイルには、rlogin サービスに対して次のような内容が含まれています。

     # Authentication management
     ...     
     # rlogin service 
     rlogin  auth sufficient         pam_rhosts_auth.so.1
     rlogin  auth requisite          pam_authtok_get.so.1
     rlogin  auth required           pam_dhkeys.so.1
     rlogin  auth required           pam_unix_auth.so.1
     ...

rlogin サービスが認証を要求すると、libpam はまず、pam_rhosts_auth(5) モジュールを実行します。pam_rhosts_auth モジュールの制御フラグは、sufficient に設定されています。pam_rhosts_auth モジュールがユーザーの認証に成功すると、処理が中止され、アプリケーションに成功が返されます。

pam_rhosts_auth モジュールがユーザーの認証に失敗すると、次の PAM モジュールである pam_authtok_get(5) が実行されます。このモジュールの制御フラグは、requisite に設定されています。pam_authtok_get が失敗すると、認証処理が終了し、失敗が rlogin に返されます。

pam_authtok_get が成功すると、次の 2 つのモジュール pam_dhkeys(5) と pam_unix_auth(5) が実行されます。どちらのモジュールにも、required に設定された制御フラグが関連付けられているため、各モジュールが失敗を返すかどうかにかかわらず、処理が継続されます。pam_unix_auth の実行が終了すると、rlogin 認証用のモジュールはもう残っていません。この時点で、pam_dhkeys、pam_unix_auth のいずれかが失敗を返していた場合、ユーザーは rlogin 経由でのアクセスを拒否されます。

第 18 章 SASL の使用

この章では、簡易認証セキュリティー層 (SASL) について説明します。

• 「SASL (概要)」

• 「SASL (参照)」

SASL (概要)

簡易認証セキュリティー層 (SASL) は、ネットワークプロトコルに認証サービスとセキュリティーサービス (オプション) を提供するフレームワークです。アプリケーションは、SASL ライブラリ /usr/lib/libsasl.so を呼び出します。SASL ライブラリは、アプリケーションと各種 SASL メカニズムを結び付ける層の役割を果たします。このメカニズムは、認証プロセスや、オプションのセキュリティーサービスの提供時に使用されます。Solaris 10 リリースで提供される SASL のバージョンは、いくつかの変更が行われた Cyrus SASL に基づいています。

SASL は、次のサービスを提供します。

• プラグインを読み込む

• アプリケーションから必要なセキュリティーオプションを判断してセキュリティーメカニズムの選択を支援する

• アプリケーションで使用可能なプラグインを一覧表示する

• 特定の認証の試みに対して、使用可能なメカニズムの一覧から最適なメカニズムを選択する

• アプリケーションと選択されたメカニズムの間で認証データの経路を指定する

• アプリケーションに返す SASL ネゴシエーションに関する情報を提供する

SASL (参照)

次の節では、Solaris 10 リリースの SASL の実装について説明します。

SASL プラグイン

SASL プラグインは、セキュリティーメカニズム、ユーザーの正規化、および補助プロパティーの検索をサポートします。デフォルトでは、動的に読み込まれる 32 ビットのプラグインは /usr/lib/sasl にインストールされ、64 ビットのプラグインは /usr/lib/sasl/$ISA にインストールされます。次のセキュリティーメカニズムのプラグインが、Solaris 10 リリースで提供されています。

crammd5.so.1

CRAM-MD5。認証のみをサポートし、承認はサポートしません

digestmd5.so.1

DIGEST-MD5。認証、整合性、機密性のほか、承認もサポートします

gssapi.so.1

GSSAPI。認証、整合性、機密性のほか、承認もサポートします。GSSAPI セキュリティーメカニズムには、機能している Kerberos 基盤が必要です。

plain.so.1

PLAIN。認証と承認をサポートします。

さらに、 EXTERNAL セキュリティーメカニズムのプラグインと INTERNAL ユーザー正規化プラグインが、libsasl.so.1に装備されています。EXTERNAL メカニズムは、認証と承認をサポートします。外部のセキュリティーソースによって提供された場合には、整合性と機密性がサポートされます。INTERNAL プラグインは、必要に応じて、レルム名をユーザー名に追加します。

Solaris 10 は、現時点では auxprop プラグインを提供していません。CRAM-MD5 および DIGEST-MD5 メカニズムプラグインをサーバー側で完全に機能させるには、ユーザーは auxprop プラグインを用意して平文のパスワードを取り出す必要があります。PLAIN プラグインでは、さらに、パスワードを検証できるようにするために追加のサポートが必要です。パスワード検証に利用できるものは、 サーバーアプリケーションへのコールバック、auxprop プラグイン、saslauthd、または pwcheck のいずれかです。salauthd デーモンおよび pwcheck デーモンは、今回の Solaris のリリースでは提供されません。相互運用性を向上させるために、サーバーアプリケーションは、mech_list SASL オプションによって完全に機能するメカニズムに制限してください。

SASL の環境変数

デフォルトでは、クライアントの認証名は getenv("LOGNAME") に設定されます。この変数は、クライアントまたはプラグインによってリセットすることができます。

SASL のオプション

libsasl およびプラグインの動作は、/etc/sasl/app.conf ファイルで設定可能なオプションを使用してサーバー上で変更することができます。変数 app は、サーバー定義のアプリケーション名です。サーバー app のマニュアルでは、サーバー定義のアプリケーション名が指定されています。

次のオプションが、Solaris 10 リリースでサポートされるようになりました。

auto_transition

ユーザーが平文認証に成功すると、自動的にそのユーザーをほかのメカニズムに切り替えます。

auxprop_login

使用する補助プロパティープラグインの名前を列挙します。

canon_user_plugin

使用する canon_user プラグインを選択します。

mech_list

サーバーアプリケーションが使用可能なメカニズムを列挙します。

pwcheck_method

パスワードを検証するために使用するメカニズムを列挙します。現在は、auxprop が唯一使用可能な値です。

reauth_timeout

迅速に再認証するために認証情報がキャッシュされる時間の長さを分単位で設定します。このオプションは、DIGEST-MD5 プラグインで使用されます。このオプションを 0 に設定すると、再認証が無効になります。

次のオプションは、Solaris 10 リリースでサポートされなくなりました。

plugin_list

使用可能なメカニズムを列挙します。このオプションは、プラグインの動的な読み込みの動作を変えるため、使用されなくなりました。

saslauthd_path

saslauthd デーモンとの通信に使用される saslauthd ドアの場所を定義します。saslauthd デーモンは、Solaris 10 リリースに組み込まれていません。このため、このオプションも組み込まれていません。

keytab

GSSAPI プラグインによって使用される keytab ファイルの場所を定義します。代わりに KRB5_KTNAME 環境変数を使用して、デフォルトの keytab の場所を設定します。

次のオプションは、Cyrus SASL では用意されていません。ただし、Solaris 10 リリースでは追加されています。

use_authid

GSS クライアントセキュリティーコンテキストの作成時に、デフォルトの資格を使用するのではなく、クライアントの資格を取得します。デフォルトでは、デフォルトのクライアント Kerberos 識別情報が使用されます。

log_level

サーバーのログのレベルを設定します。

第 19 章 Solaris Secure Shell の使用 (手順)

Solaris Secure Shell を使用すると、セキュリティー保護されていないネットワーク上の遠隔ホストに、安全にアクセスすることができます。Solaris Secure Shell には、遠隔ログインおよび遠隔ファイル転送を行うコマンドが組み込まれています。この章で説明する内容は次のとおりです。

• 「Solaris Secure Shell (概要)」

• 「Solaris Secure Shell と OpenSSH プロジェクト」

• 「Solaris Secure Shell の構成 (作業マップ)」

• 「Solaris Secure Shell の使用 (作業マップ)」

参照情報については、第 20 章Solaris Secure Shell (参照)を参照してください。Solaris Secure Shell と OpenSSH プロジェクトの関係については、「Solaris Secure Shell と OpenSSH プロジェクト」を参照してください。

Solaris Secure Shell (概要)

Solaris Secure Shell の認証は、パスワードまたは公開鍵、あるいはその両方を使用して行われます。すべてのネットワークトラフィックは暗号化されます。このため、Solaris Secure Shell では、悪意を持つ侵入者が傍受した通信を読むことはできません。また、攻撃者が偽装することもできません。

Solaris Secure Shell は、オンデマンドタイプの 仮想プライベートネットワーク (VPN) として使用することもできます。VPN では、暗号化されたネットワークリンクを介して、ローカルマシンと遠隔マシン間で、X ウィンドウシステムのトラフィックを転送したり個々のポート番号を接続したりできます。

Solaris Secure Shell では、次の操作を行うことができます。

• セキュリティー保護されていないネットワークを介して、別のホストに安全にログインします。

• 2 つのホスト間でファイルを安全にコピーします。

• 遠隔ホスト上でコマンドを安全に実行します。

Solaris Secure Shell では、2 つのバージョンの Secure Shell プロトコルを利用できま す。バージョン 1 は、Secure Shell プロトコルのオリジナルバージョンです。バージョン 2 は、安全性が向上し、バージョン 1 の基本的なセキュリティー設計上の欠陥が修正されています。バージョン 1 は、バージョン 2 へ移行するユーザーを支援する目的だけに提供しています。バージョン 1 は、極力使用しないでください。

このマニュアルでは、v1 はバージョン 1、v2 はバージョン 2 を表しています。

Solaris Secure Shell 認証

Solaris Secure Shell は、遠隔ホストへの接続を認証するために、公開鍵とパスワードの方式を提供します。公開鍵認証は、パスワード認証よりも強力な認証メカニズムです。これは、非公開鍵がネットワーク上を移動しないためです。

認証方式は、次の順序で試されます。構成が認証方式を満たさないときは、次の方式が試されます。

• GSS-API – mech_krb5 (Kerberos V) や mech_dh (AUTH_DH) などの GSS-API メカニズムの資格を使用して、クライアントとサーバーを認証します。GSS-API の詳細については、『Oracle Solaris セキュリティーサービス開発ガイド』の「GSS-API の紹介」を参照してください。

• ホストに基づく認証 – ホスト鍵と rhosts ファイルを使用します。クライアントの RSA および DSA 公開/非公開ホスト鍵を使用してクライアントを認証します。rhosts ファイルを使用して、ユーザーに対してクライアントを承認します。

• 公開鍵認証 – RSA および DSA 公開/非公開鍵によってユーザーを認証します。

• パスワード認証 – PAM を使用してユーザーを認証します。v2 でのキーボード認証方式では、PAM による任意のプロンプトが可能です。詳細については、sshd(1M) のマニュアルページの「SECURITY」のセクションを参照してください。

次の表では、遠隔ホストにログインしようとするユーザーを認証するための要件を示します。ユーザーは、ローカルホスト (クライアント) 上に存在します。遠隔ホスト (サーバー) は、sshd デーモンを実行しています。次の表は、Solaris Secure Shell の認証方式、互換性のあるプロトコルのバージョン、およびホストの要件の一覧です。

企業における Solaris Secure Shell

Solaris システム上の Secure Shell の総合的な説明については、『Secure Shell in the Enterprise』 (Jason Reid 著、ISBN 0-13-142900-0、2003 年 6 月) を参照してください。このドキュメントは、Sun Microsystems Press によって発行されている Sun BluePrints Series の 1 つです。

オンラインでの情報については、Sun の BigAdmin System Administration Portal ウェブサイト (http://www.sun.com/bigadmin/home/index.jsp) にアクセスしてください。「Docs」をクリックし、「Misc./Comprehensive」の下の「Sun BluePrints」をクリックします。「BluePrints OnLine」をクリックし、「Archives by Subject」、「Security」の順にクリックします。アーカイブには次の記事が含まれています。

• Role Based Access Control and Secure Shell – A Closer Look At Two Solaris Operating Environment Security Features

• Integrating the Secure Shell Software

• Configuring the Secure Shell Software

Solaris Secure Shell と OpenSSH プロジェクト

Solaris Secure Shell は OpenSSH プロジェクトのフォークです。OpenSSH の最近のバージョンに見つかった脆弱性に対するセキュリティー関連の修正が、個別のバグ修正および機能として Solaris Secure Shellに組み込まれています。Solaris Secure Shell フォークに対しては内部開発が継続されます。

Sun の技術者はプロジェクトにバグ修正を提供するほか、次の Solaris の機能を Secure Shell の Solaris フォークに組み込みました。

• PAM - Solaris Secure Shell では PAM が使用されます。OpenSSH の UsePAM 設定オプションはサポートされていません。

• 特権の分離 - Solaris Secure Shell では OpenSSH プロジェクトの特権分離コードは使用されません。Solaris Secure Shell では、監査、記録管理、および再キーイングの処理がセッションプロトコルの処理から分離されます。

  Solaris Secure Shell の特権分離コードは常にオンに設定されており、オフに切り替えることはできません。OpenSSH の UsePrivilegeSeparation 設定オプションはサポートされていません。

• ロケール - Solaris Secure Shell では、RFC 4253「Secure Shell Transfer Protocol」で定義されている言語ネゴシエーションが完全にサポートされています。ユーザーがログインしたあと、ユーザーのログインシェルプロファイルを Solaris Secure Shell でネゴシエーションを行なったロケール設定に優先することができます。

• 監査 - Solaris Secure Shell は Solaris 監査サブシステムに完全に統合されています。監査については、パート VII「Solaris 監査」を参照してください。

• GSS-API のサポート - GSS-API はユーザー認証と初期鍵交換の両方に使用できます。GSS-API は RFC 4462「Generic Security Service Application Program Interface」で定義されています。

• プロキシコマンド - Solaris Secure Shell では、SOCKS5 プロトコルと HTTP プロトコルのプロキシコマンドが提供されています。例については、「ファイアウォール外部のホストにデフォルト接続を設定する方法」を参照してください。

Solaris 9 リリース以降、Solaris Secure Shell に次の変更点が取り入れられています。

• Solaris Secure Shell は OpenSSH 3.5p1 からフォークされます。

• /etc/ssh/sshd_config ファイルの X11Forwarding のデフォルト値が、yes になりました。

• 次のキーワードが採用されました。

  • GSSAPIAuthentication

  • GSSAPIKeyExchange

  • GSSAPIDelegateCredentials

  • GSSAPIStoreDelegatedCredentials

  • KbdInteractiveAuthentication

  GSSAPI キーワードによって、 Solaris Secure Shell で GSS 資格を認証に使用できます。KbdInteractiveAuthentication キーワードが、PAM での任意のプロンプトとパスワードの変更をサポートします。キーワードとそのデフォルト値の一覧については、「Solaris Secure Shell でのキーワード」を参照してください。

• ARCFOUR 暗号および AES128-CTR 暗号を使用できます。ARCFOUR は RC4 としても知られています。AES 暗号は、カウンタモードの AES です。

• sshd デーモンが、/etc/default/login および login コマンドの変数を使用します。/etc/default/login の変数は、sshd_config ファイルの値によって無効にすることができます。詳細は、「Solaris Secure Shell およびログインの環境変数」と sshd_config(4) のマニュアルページを参照してください。

Solaris Secure Shell (作業マップ)

次の作業マップは、Solaris Secure Shell の構成と Solaris Secure Shell の使用についての作業マップです。

Solaris Secure Shell の構成 (作業マップ)

次の作業マップでは、Solaris Secure Shell の構成手順を示します。

Solaris Secure Shell の構成

Solaris Secure Shell では、デフォルトでは、ホストに基づく認証と両方のプロトコルの使用は無効になっています。これらのデフォルトを変更するには、管理者の介入が必要です。また、ポート転送が機能するようにするためにも、管理者の介入が必要です。

ホストに基づく認証を Solaris Secure Shell に設定する方法

次の手順によって公開鍵システムが設定され、クライアントの公開鍵がサーバー上での認証に使用できるようになります。また、ユーザーは、公開鍵と非公開鍵のペアを作成する必要があります。

この手順での「クライアント」および「ローカルホスト」という用語は、ユーザーが ssh コマンドを入力するマシンを指しています。「サーバー」および「リモートホスト」という用語は、クライアントがアクセスを試みるマシンを指しています。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. クライアントで、ホストに基づく認証を有効にします。

   クライアントの構成ファイル /etc/ssh/ssh_config で、次のエントリを入力します。

   HostbasedAuthentication yes

   このファイルの構文については、ssh_config(4) のマニュアルページを参照してください。

3. サーバーで、ホストに基づく認証を有効にします。

   サーバーの構成ファイル /etc/ssh/ssh_config で、同じエントリを入力します。

   HostbasedAuthentication yes

   このファイルの構文については、sshd_config(4) のマニュアルページを参照してください。

4. サーバーで、クライアントが信頼されるホストとして認識されるようにするファイルを構成します。

   詳細については、sshd(1M) のマニュアルページの「FILES」のセクションを参照してください。

   • サーバーの /etc/ssh/shosts.equiv ファイルへのエントリとしてクライアントを追加します。

     client-host

   • または、クライアント用のエントリをサーバー上の ~/.shosts ファイルに追加するようにユーザーに指示することもできます。

     client-host

5. サーバーで、sshdデーモンが信頼されるホストのリストにアクセスできるようにします。

   /etc/ssh/sshd_config ファイルで、IgnoreRhosts を no に設定します。

   ## sshd_config IgnoreRhosts no

6. 使用するサイトの Solaris Secure Shell のユーザーが両方のホストでアカウントを持つようにします。

7. クライアントの公開鍵をサーバー上に置くために、次のどちらかを行います。

   • サーバー上の sshd_config ファイルを変更後、クライアントの公開ホスト鍵を ~/.ssh/known_hosts ファイルに追加するようにユーザーに指示します。

     ## sshd_config IgnoreUserKnownHosts no

     ユーザーへの指示については、「Solaris Secure Shell で使用する公開鍵と非公開鍵のペアを生成する方法」を参照してください。

   • クライアントの公開鍵をサーバーにコピーします。

     ホスト鍵は、/etc/ssh ディレクトリに格納されます。鍵は、通常、最初のブート時に sshd デーモンによって生成されます。

     1. サーバー上の /etc/ssh/ssh_known_hosts ファイルに鍵を追加します。

        クライアントで、バックスラッシュなしで 1 行に次のコマンドを入力します。

        # cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \ 'cat >> /etc/ssh/ssh_known_hosts && echo "Host key copied"'

     2. プロンプトが表示されたら、ログインパスワードを入力します。

        ファイルがコピーされると、「Host key copied」というメッセージが表示されます。

        /etc/ssh/ssh_known_hosts ファイルの各行は、スペースで区切られたフィールドで構成されています。

        hostnames algorithm-name publickey comment

     3. /etc/ssh/ssh_known_hosts ファイルを編集して、コピーしたエントリの最初のフィールドとして RemoteHost を追加します。

        ## /etc/ssh/ssh_known_hosts File RemoteHost <copied entry>

例 19–1 ホストに基づく認証を設定する

次の例では、各ホストがサーバーおよびクライアントとして構成されます。一方のホストのユーザーが、他方のホストへの ssh 接続を開始できます。次の構成によって、各ホストがサーバーおよびクライアントになります。

• ホストごとに、 Solaris Secure Shell 構成ファイルに次のエントリを入力します。

  ## /etc/ssh/ssh_config HostBasedAuthentication yes # ## /etc/ssh/sshd_config HostBasedAuthentication yes IgnoreRhosts no

• ホストごとに、shosts.equiv ファイルに他方のホストに対するエントリを入力します。

  ## /etc/ssh/shosts.equiv on machine2 machine1

  ## /etc/ssh/shosts.equiv on machine1 machine2

• 各ホストの公開鍵を、他方のホストの /etc/ssh/ssh_known_hosts ファイルに入力します。

  ## /etc/ssh/ssh_known_hosts on machine2 … machine1

  ## /etc/ssh/ssh_known_hosts on machine1 … machine2

• ユーザーは、両方のホストにアカウントを持ちます。

  ## /etc/passwd on machine1 jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh

  ## /etc/passwd on machine2 jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh

Solaris Secure Shell v1 を有効にする方法

この手順は、ホストが v1 および v2 を実行するホストと相互運用されるときに役立ちます。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. 両方の Solaris Secure Shell のプロトコルを使用するホストを構成します。

   /etc/ssh/sshd_config ファイルを編集します。

   # Protocol 2 Protocol 2,1

3. v1 のホスト鍵用に別ファイルを指定します。

   HostKey エントリを /etc/ssh/sshd_config ファイルに追加します。

   HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa1_key

4. v1 のホスト鍵を生成します。

   # ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa1_key -N ''

   -t rsa1

   v1 の RSA アルゴリズムを示します

   -f

   ホスト鍵を保持するファイルを示します。

   -N ''

   パスフレーズが必要ないことを示します。

5. sshd デーモンを再起動します。

   # svcadm restart network/ssh:default

   システムをリブートしても構いません。

Solaris Secure Shell のポート転送を構成する方法

ポート転送によって、ローカルポートを遠隔ホストに転送することができるようになります。指定すると、ソケットはローカル側で、そのポートを待機します。また、遠隔側のポートを指定することもできます。

Solaris Secure Shell ポート転送では TCP 接続を使用する必要があります。Solaris Secure Shell はポート転送のための UDP 接続をサポートしていません。

1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

   Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

2. ポート転送ができるように遠隔サーバーで Solaris Secure Shell の設定を構成します。

   /etc/ssh/sshd_config ファイルで AllowTcpForwarding の値を yes に変更します。

   # Port forwarding AllowTcpForwarding yes

3. Solaris Secure Shell サービスを再起動します。

   remoteHost# svcadm restart network/ssh:default

   永続的なサービスの管理方法については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」および svcadm(1M) のマニュアルページを参照してください。

4. ポート転送が使用できることを確認します。

   remoteHost# /usr/bin/pgrep -lf sshd 1296 ssh -L 2001:remoteHost:23 remoteHost

Solaris Secure Shell の使用 (作業マップ)

次の作業マップでは、ユーザーが Solaris Secure Shell を使用する際の手順を示します。

Solaris Secure Shell の使用

Solaris Secure Shell によって、ローカルシェルと遠隔シェルの間の安全なアクセスが可能になります。詳細は、ssh_config(4) および ssh(1) のマニュアルページを参照してください。

Solaris Secure Shell で使用する公開鍵と非公開鍵のペアを生成する方法

使用するサイトがホストに基づく認証またはユーザーの公開鍵認証を実装しているときは、ユーザーは公開鍵と非公開鍵のペアを生成する必要があります。追加のオプションについては、ssh-keygen(1) のマニュアルページを参照してください。

始める前に

ホストに基づく認証が構成されているかどうかをシステム管理者に確認します。

1. 鍵の生成プログラムを起動します。

   myLocalHost% ssh-keygen -t rsa Generating public/private rsa key pair. …

   -t はアルゴリズムの種類で、rsa、dsa、rsa1 のいずれかです。

2. 鍵が格納されるファイルのパスを指定します。

   デフォルトでは、RSA v2 の鍵を表すファイル名 id_rsa がカッコ内に表示されます。このファイルを選択するときは、Return キーを押します。代わりのファイル名を入力することもできます。

   Enter file in which to save the key (/home/jdoe/.ssh/id_rsa):<Press Return>

   文字列 .pub を非公開鍵のファイル名に追加すると、自動的に公開鍵のファイル名になります。

3. 鍵に使用するパスフレーズを入力します。

   このパスフレーズは、非公開鍵を暗号化するときに使用されます。空文字列入力は極力避けてください。入力したパスフレーズは表示されません。

   Enter passphrase (empty for no passphrase): <Type passphrase>

4. 確認のためにパスフレーズを再入力します。

   Enter same passphrase again: <Type passphrase> Your identification has been saved in /home/jdoe/.ssh/id_rsa. Your public key has been saved in /home/jdoe/.ssh/id_rsa.pub. The key fingerprint is: 0e:fb:3d:57:71:73:bf:58:b8:eb:f3:a3:aa:df:e0:d1 jdoe@myLocalHost

5. 結果を確認します。

   鍵ファイルへのパスが正しいことを確認します。

   % ls ~/.ssh id_rsa id_rsa.pub

   この時点で公開鍵と非公開鍵のペアが作成されました。

6. 適切なオプションを選択します。

   • 管理者がホストに基づく認証を構成しているときは、ローカルホストの公開鍵を遠隔ホストにコピーする必要がある場合があります。

     遠隔ホストにログインできるようになっています。詳細については、「Solaris Secure Shell を使用して遠隔ホストにログインする方法」を参照してください。

     1. 次のコマンドを入力します (ただし、バックスラッシュなしで 1 行に入力)。

        % cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \ 'cat >> ~./ssh/known_hosts && echo "Host key copied"'

     2. プロンプトが表示されたら、ログインパスワードを入力します。

        Enter password: <Type password> Host key copied %

   • 使用するサイトで公開鍵によるユーザー認証が使用されているときは、遠隔ホストの authorized_keys ファイルに反映します。

     1. 公開鍵を遠隔ホストにコピーします。

        次のコマンドを入力します (ただし、バックスラッシュなしで 1 行に入力)。

        myLocalHost% cat $HOME/.ssh/id_rsa.pub | ssh myRemoteHost \ 'cat >> .ssh/authorized_keys && echo "Key copied"'

     2. プロンプトが表示されたら、ログインパスワードを入力します。

        ファイルがコピーされると「Key copied」というメッセージが表示されます。

        Enter password: Type login password Key copied myLocalHost%

7. (省略可能) パスフレーズのプロンプトを減らします。

   手順については、「Solaris Secure Shell でのパスワードのプロンプトを減らす方法」を参照してください。詳細は、ssh-agent(1) および ssh-add(1) のマニュアルページを参照してください。

例 19–2 ユーザーに対して v1 RSA 鍵を確立する

次の例では、ユーザーが Solaris Secure Shell プロトコルの v1 を実行するホストと接続することができます。v1 ホストによって認証されるようにするために、ユーザーは、v1 鍵を作成後、公開鍵の部分を遠隔ホストにコピーします。

myLocalHost% ssh-keygen -t rsa1 -f /home/jdoe/.ssh/identity
Generating public/private rsa key pair.
…
Enter passphrase (empty for no passphrase): <Type passphrase>
Enter same passphrase again: <Type passphrase>
Your identification has been saved in /home/jdoe/.ssh/identity.
Your public key has been saved in /home/jdoe/.ssh/identity.pub.
The key fingerprint is:
…
myLocalHost% ls ~/.ssh
id_rsa
id_rsa.pub
identity
identity.pub
myLocalHost% cat $HOME/.ssh/identity.pub | ssh myRemoteHost \
'cat >> .ssh/authorized_keys && echo "Key copied"'

Solaris Secure Shell の公開鍵のパスフレーズを変更する方法

次の手順で非公開鍵が変更されることはありません。この手順は、非公開鍵 (パスフレーズ) の認証メカニズムを変更するものです。詳細は、ssh-keygen(1) のマニュアルページを参照してください。

1. パスフレーズを変更します。

   ssh-keygen コマンドを-p オプションを指定して入力し、プロンプトに答えます。

   myLocalHost% ssh-keygen -p Enter file which contains the private key (/home/jdoe/.ssh/id_rsa):<Press Return> Enter passphrase (empty for no passphrase): <Type passphrase> Enter same passphrase again: <Type passphrase>

   -p は、非公開鍵ファイルのパスフレーズの変更を要求します。

Solaris Secure Shell を使用して遠隔ホストにログインする方法

1. Solaris Secure Shell セッションを開始します。

   ssh コマンドを入力して、遠隔ホストの名前を指定します。

   myLocalHost% ssh myRemoteHost

   遠隔ホストの信頼性を尋ねるプロンプトが表示されます。

   The authenticity of host 'myRemoteHost' can't be established. RSA key fingerprint in md5 is: 04:9f:bd:fc:3d:3e:d2:e7:49:fd:6e:18:4f:9c:26 Are you sure you want to continue connecting(yes/no)?

   このプロンプトは、遠隔ホストに初めて接続する場合には正常なプロンプトです。

2. プロンプトが表示されたら、遠隔ホスト鍵の信頼性を確認します。

   • 遠隔ホストの信頼性を確認できない場合は、no と入力してシステム管理者に連絡します。

     Are you sure you want to continue connecting(yes/no)? no

     システム管理者は、大域の /etc/ssh/ssh_known_hosts ファイルを更新する責任があります。更新された ssh_known_hosts ファイルでは、このようなプロンプトは表示されません。

   • 遠隔ホストの信頼性を確認したら、プロンプトに答えて次の手順に進みます。

     Are you sure you want to continue connecting(yes/no)? yes

3. Solaris Secure Shell に対して自分を認証します。

   1. プロンプトが表示されたら、自分のパスフレーズを入力します。

      Enter passphrase for key '/home/jdoe/.ssh/id_rsa': <Type passphrase>

   2. プロンプトが表示されたら、アカウントのパスワードを入力します。

      jdoe@myRemoteHost's password: <Type password> Last login: Fri Jul 20 14:24:10 2001 from myLocalHost myRemoteHost%

4. 遠隔ホストでトランザクションを実行します。

   ユーザーが送信するコマンドはすべて暗号化されます。ユーザーが受信する応答はすべて暗号化されます。

5. Solaris Secure Shell の接続を切断します。

   終了したら、exit を入力するか、通常の方法でシェルを終了します。

   myRemoteHost% exit myRemoteHost% logout Connection to myRemoteHost closed myLocalHost%

Solaris Secure Shell でのパスワードのプロンプトを減らす方法

Solaris Secure Shell の使用に際してパスフレーズやパスワードを入力しない場合は、エージェントデーモンを使用できます。セッションを開始するときにデーモンを起動します。次に、エージェントデーモンを使用して非公開鍵を格納するために、ssh-add コマンドを使用します。ホストごとにアカウントが異なる場合は、セッションに必要な非公開鍵を追加します。

エージェントデーモンの起動は、次の手順で説明するように、必要に応じて手動で行うことができます。各セッションを開始するときに、エージェントデーモンが自動的に動作するように設定することもできます (「CDE で ssh-agent コマンドが自動的に動作するように設定する方法」を参照)。

1. エージェントデーモンを起動します。

   myLocalHost% eval `ssh-agent` Agent pid 9892

2. エージェントデーモンが起動していることを確認します。

   myLocalHost% pgrep ssh-agent 9892

3. 使用する非公開鍵をエージェントデーモンに追加します。

   ssh-add コマンドを入力します。

   myLocalHost% ssh-add Enter passphrase for /home/jdoe/.ssh/id_rsa: <Type passphrase> Identity added: /home/jdoe/.ssh/id_rsa(/home/jdoe/.ssh/id_rsa) myLocalHost%

4. Solaris Secure Shell セッションを開始します。

   myLocalHost% ssh myRemoteHost

   パスフレーズを要求するプロンプトは表示されません。

例 19–3 ssh-add オプションを使用する

この例では、jdoe が 2 つの鍵をエージェントデーモンに追加します。-l オプションは、デーモンに格納されているすべての鍵を一覧表示するために使用します。セッションの最後に、-D オプションを使用して、エージェントデーモンからすべての鍵を削除します。

myLocalHost% ssh-agent
myLocalHost% ssh-add
Enter passphrase for /home/jdoe/.ssh/id_rsa: <Type passphrase>
Identity added: /home/jdoe/.ssh/id_rsa(/home/jdoe/.ssh/id_rsa)
myLocalHost% ssh-add /home/jdoe/.ssh/id_dsa
Enter passphrase for /home/jdoe/.ssh/id_dsa: <Type passphrase>
Identity added:
/home/jdoe/.ssh/id_dsa(/home/jdoe/.ssh/id_dsa)

myLocalHost% ssh-add -l
md5 1024 0e:fb:3d:53:71:77:bf:57:b8:eb:f7:a7:aa:df:e0:d1
/home/jdoe/.ssh/id_rsa(RSA)
md5 1024 c1:d3:21:5e:40:60:c5:73:d8:87:09:3a:fa:5f:32:53
/home/jdoe/.ssh/id_dsa(DSA)

User conducts Solaris Secure Shell transactions

myLocalHost% ssh-add -D
Identity removed:
/home/jdoe/.ssh/id_rsa(/home/jdoe/.ssh/id_rsa.pub)
/home/jdoe/.ssh/id_dsa(DSA)

CDE で ssh-agent コマンドが自動的に動作するように設定する方法

CDE を使用する場合、Solaris Secure Shell を使用するときにパスフレーズとパスワードを入力しないようにするには、エージェントデーモン ssh-agent を自動的に起動します。このエージェントデーモンは、.dtprofile スクリプトから起動できます。パスフレーズとパスワードをエージェントデーモンに追加する方法については、例 19–3 を参照してください。

Sun Java Desktop System (Java DS) を使用する場合には、ssh-agent コマンドが自動的に実行されるように設定しないでください。ssh-agent プロセスの終了は CDE インタフェースによって制御されるため、Java DS を終了してもデーモンは動作し続けます。たとえば、CDE セッションでデーモンを起動し、Java DS セッションに移動してからログアウトした場合、デーモンは動作し続けます。

実行中のデーモンはシステムリソースを使用します。ssh-agent デーモンを実行したまま放置しても、何らかの既知の問題が発生するわけではありませんが、このデーモンにはパスワードが含まれているので、セキュリティーが脅かされる恐れがあります。

1. ユーザーの起動スクリプトでエージェントデーモンを自動的に起動します。

   $HOME/.dtprofile スクリプトの最後に次の行を追加します。

   if [ "$SSH_AUTH_SOCK" = "" -a -x /usr/bin/ssh-agent ]; then eval `/usr/bin/ssh-agent` fi

2. CDE セッションを終了するときにエージェントデーモンを終了します。

   $HOME/.dt/sessions/sessionexit スクリプトに次の行を追加します。

   if [ "$SSH_AGENT_PID" != "" -a -x /usr/bin/ssh-agent ]; then /usr/bin/ssh-agent -k fi

   このエントリにより、CDE セッションが終了したあとで、Solaris Secure Shell エージェントは使用できなくなります。このスクリプトは CDE に固有のインタフェース sessionexit を使用しているため、Sun Java Desktop System セッションでこの手順を実行しても、エージェントデーモンは終了しません。

Solaris Secure Shell のポート転送を使用する方法

遠隔ホストに転送されるローカルポートを指定することができます。指定すると、ソケットはローカル側で、そのポートを待機します。このポートから遠隔ホストへの接続は、セキュリティー保護されたチャネルを介して行われます。たとえば、ポート 143 を指定すれば、IMAP4 で電子メールを遠隔で取得できます。また、遠隔側のポートを指定することもできます。

始める前に

ポート転送を使用するために、管理者は、遠隔の Solaris Secure Shell サーバーでのポート転送を有効にする必要があります。詳細については、「Solaris Secure Shell のポート転送を構成する方法」を参照してください。

1. ポート転送を安全に使用するために、次のオプションのどちらかを選択してください。

   • ローカルポートを遠隔ポートからのセキュリティー保護された通信の受信側として設定するには、両方のポートを指定します。

     遠隔からの通信を待機するローカルポートを指定します。また、通信を転送する遠隔ホストと遠隔ポートを指定します。

     myLocalHost% ssh -L localPort:remoteHost:remotePort

   • 遠隔ポートをローカルポートからのセキュリティー保護された接続の受信側として設定するには、両方のポートを指定します。

     遠隔からの通信を待機する遠隔ポートを指定します。また、通信を転送するローカルホストとローカルポートを指定します。

     myLocalHost% ssh -R remotePort:localhost:localPort

例 19–4 ローカルポート転送を使用してメールを受信する

次の例は、ローカルポート転送を使用して、遠隔サーバーからのメールを安全に受信する方法を示しています。

myLocalHost% ssh -L 9143:myRemoteHost:143 myRemoteHost 

このコマンドは、myLocalHost のポート9143 からポート 143 に接続を転送します。ポート 143 は、myRemoteHost の IMAP v2 のサーバーポートです。ユーザーがメールアプリケーションを起動するときは、次のダイアログボックスのように、ローカルポート番号を指定する必要があります。

ダイアログボックスの localhost を myLocalHost と混同しないようにしてください。myLocalHost は仮のホスト名です。localhost はローカルシステムを表すキーワードです。

例 19–5 遠隔ポート転送を使用してファイアウォールの外部と通信する

この例では、エンタープライズ環境のユーザーが、外部ネットワーク上のホストから企業のファイアウォール内部のホストに接続を転送する方法を示しています。

myLocalHost% ssh -R 9022:myLocalHost:22 myOutsideHost

このコマンドは、myOutsideHost 上のポート 9022 からローカルホスト上のポート 22 (sshd サーバー) に接続を転送します。

myOutsideHost% ssh -p 9022 localhost
myLocalHost%

Solaris Secure Shell を使用してファイルをコピーする方法

次の手順では、scp コマンドを使用して、暗号化されたファイルをホスト間でコピーする方法を示します。暗号化されたファイルは、ローカルホストと遠隔ホストとの間、または 2 つの遠隔ホスト間でコピーできます。scp コマンドは、rcp コマンドと同様に動作しますが、認証を要求するプロンプトを表示する点で異なります。詳細は、scp(1) のマニュアルページを参照してください。

ftp コマンドより安全な sftp を使用することもできます。詳細は、sftp(1) のマニュアルページを参照してください。例については、例 19–6 を参照してください。

1. セキュリティー保護されたコピープログラムを起動します。

   ソースファイル、遠隔コピー先のユーザー名、およびコピー先ディレクトリを指定します。

   myLocalHost% scp myfile.1 jdoe@myRemoteHost:~

2. プロンプトが表示されたら、パスフレーズを入力します。

   Enter passphrase for key '/home/jdoe/.ssh/id_rsa': <Type passphrase> myfile.1 25% |******* | 640 KB 0:20 ETA myfile.1

   パスフレーズを入力すると、進行状況インジケータが表示されます。上記の出力の 2 行目が進行状況インジケータです。進行状況インジケータには、次の項目が表示されます。

   • ファイル名

   • そのファイル全体に対する、転送が完了した量の割合 (%)

   • そのファイル全体に対する、転送が完了した量の割合を示すアスタリスク(*)

   • 転送が完了したデータの量

   • ファイル全体が転送されるまでの推定時間 (ETA)。推定残り時間

例 19–6 sftp コマンドを使用するときにポートを指定する

この例では、ユーザーは sftp コマンドで特定のポートを使用しようとしています。ユーザーは -o オプションを使用してポートを指定します。

% sftp -o port=2222 guest@RemoteFileServer

ファイアウォール外部のホストにデフォルト接続を設定する方法

Solaris Secure Shell を使用して、ファイアウォール内部のホストからファイアウォール外部のホストに接続することができます。接続するには、構成ファイル内またはコマンド行オプションに ssh のプロキシコマンドを指定します。コマンド行オプションについては、例 19–7 を参照してください。

通常は、構成ファイルを使用して、ssh の対話操作をカスタマイズします。

• 1 つの方法として、~/.ssh/config の個人用構成ファイルをカスタマイズします。

• もう 1 つの方法として、管理構成ファイル /etc/ssh/ssh_config を使用します。

ファイルは、2 種類のプロキシコマンドでカスタマイズできます。一方が HTTP 接続用、もう一方が SOCKS5 接続用です。詳細は、ssh_config(4) のマニュアルページを参照してください。

1. 構成ファイルにプロキシコマンドとホストを指定します。

   次の構文を使用して、必要なプロキシコマンドとホストの数に応じて行を追加します。

   [Host outside-host] ProxyCommand proxy-command [-h proxy-server] \ [-p proxy-port] outside-host|%h outside-port|%p

   Host outside-host

   コマンド行で遠隔ホスト名を指定した場合、プロキシコマンド指定をインスタンスに限定します。outside-host でワイルドカードを使用した場合、一連のホストに対してプロキシコマンド指定が適用されます。

   proxy-command

   プロキシコマンドを指定します。

   次のいずれかを指定できます。

   • HTTP 接続の場合は、/usr/lib/ssh/ssh-http-proxy-connect

   • SOCKS5 接続の場合は、/usr/lib/ssh/ssh-socks5-proxy-connect

   -h proxy-server と -p proxy-port

   これらのオプションは、プロキシサーバーとプロキシポートをそれぞれ指定します。これらのオプションは、HTTPPROXY、HTTPPROXYPORT、SOCKS5_PORT、SOCKS5_SERVER、http_proxy などの、プロキシサーバーとプロキシポートを指定するどのような環境変数よりも優先されます。http_proxy 変数は URL を指定します。これらのオプションを指定しない場合、適切な環境変数を設定する必要があります。詳細は、ssh-socks5-proxy-connect(1) および ssh-http-proxy-connect(1) のマニュアルページを参照してください。

   outside-host

   接続先のホストを指定します。%h 代入引数を使うとコマンド行からホストを指定できます。

   outside-port

   接続先のポートを指定します。%p 代入引数を使うとコマンド行からポートを指定できます。Host outside-host オプションを使わずに %h と %p を指定した場合、ssh コマンドが呼び出されるたびに、引数に指定されたホストにプロキシコマンドが適用されます。

2. 外部のホストを指定して、Solaris Secure Shell を実行します。

   たとえば、次のように入力します。

   myLocalHost% ssh myOutsideHost

   このコマンドは、個人用構成ファイル内で myOutsideHost のプロキシコマンド指定を検索します。指定が検出されない場合、このコマンドは、システム全体の構成ファイル /etc/ssh/ssh_config から検索します。プロキシコマンドが ssh コマンドに置き換わります。

例 19–7 コマンド行からファイアウォール外部のホストに接続する

「ファイアウォール外部のホストにデフォルト接続を設定する方法」では、構成ファイルでプロキシコマンドを指定する方法について説明しました。この例では、プロキシコマンドを ssh コマンド行で指定します。

% ssh -o'Proxycommand=/usr/lib/ssh/ssh-http-proxy-connect \
-h myProxyServer -p 8080 myOutsideHost 22' myOutsideHost

ssh コマンドの -o オプションには、プロキシコマンドを指定するコマンド行を入力できます。この例のコマンドは次のことを行います。

• ssh を HTTP プロキシコマンドに置き換える

• プロキシサーバーとして、ポート 8080 および myProxyServer を使用する

• myOutsideHost のポート 22 に接続する

第 20 章 Solaris Secure Shell (参照)

この章では、Solaris Secure Shell の構成オプションについて説明します。この章の内容は次のとおりです。

• 「標準的な Solaris Secure Shell セッション」

• 「Solaris Secure Shell でのクライアントとサーバーの構成」

• 「Solaris Secure Shell でのキーワード」

• 「Solaris Secure Shell での既知のホストの管理」

• 「Solaris Secure Shell のパッケージと初期化」

• 「Solaris Secure Shell ファイル」

• 「Solaris Secure Shell コマンド」

Solaris Secure Shell を構成する手順については、第 19 章Solaris Secure Shell の使用 (手順)を参照してください。

標準的な Solaris Secure Shell セッション

Solaris Secure Shell デーモン (sshd) は通常、ネットワークサービスが開始されるブート時に起動されます。デーモンは、クライアントからの接続を待機します。Solaris Secure Shell セッションは、ssh、scp、または sftp コマンドが実行されると開始します。接続を受信するたびに、新しい sshd デーモンがフォークされます。フォークされたデーモンは、鍵の交換、暗号化、認証、コマンドの実行、およびクライアントとのデータ交換を行います。Secure Shell セッションの特性は、クライアント構成ファイルとサーバー構成ファイルによって決定されます。コマンド行引数は、構成ファイルの設定より優先されます。

クライアントとサーバーは、相互に認証する必要があります。認証に成功したあと、ユーザーはコマンドを遠隔で実行でき、ホスト間でデータをコピーできます。

Solaris Secure Shell でのセッションの特性

サーバー側の sshd デーモンの動作は、/etc/ssh/sshd_config ファイルのキーワードを設定することで変更できます。たとえば、sshd_config ファイルにより、サーバーにアクセスするときに使用する認証タイプを変更できます。サーバー側の動作は、sshd デーモンを起動するときに、コマンド行オプションによって変更することもできます。

クライアント側の動作は、Solaris Secure Shell のキーワードで変更できます。キーワードの優先順位は次のとおりです。

• コマンド行オプション

• ユーザーの構成ファイル (~/.ssh/config)

• システム全体の構成ファイル (/etc/ssh/ssh_config)

たとえば、aes128–ctr を優先しているシステム全体の Ciphers の設定を上書きするには、コマンド行に -c aes256–ctr,aes128-ctr,arcfour のように指定します。これで、最初の暗号化方式 aes256–ctr が優先されるようになります。

Solaris Secure Shell での認証と鍵の交換

Solaris Secure Shell の v1 のプロトコルと v2 のプロトコルは両方とも、クライアントのユーザーとホストの認証およびサーバーのホスト認証をサポートしています。両プロトコルは、Solaris Secure Shell セッションの保護のためにセッション暗号化鍵の交換を必要とします。各プロトコルには、認証と鍵の交換の方式がいくつかあります。その中には、任意のものもあります。Solaris Secure Shell は、多数のクライアント認証メカニズムをサポートしています (表 19–1 参照)。サーバーは、既知のホスト公開鍵を使用して認証されます。

v1 のプロトコルでは、Solaris Secure Shell は、パスワードによるユーザー認証をサポートしています。v1 のプロトコルは、ユーザー公開鍵と信頼されるホスト公開鍵による認証もサポートしています。サーバー認証は、ホスト公開鍵によって行われます。v1 のプロトコルでは、公開鍵はすべて RSA 鍵です。セッション鍵の交換には、定期的に再生成される短期サーバー鍵の使用が必要です。

v 2 のプロトコルでは、Solaris Secure Shell は、ユーザー認証と汎用対話型認証をサポートしています。汎用対話型認証は、通常、パスワードを必要とします。v 2 のプロトコルは、ユーザー公開鍵および信頼されるホスト公開鍵による認証もサポートしています。鍵は、RSA の場合と DSA の場合があります。セッション鍵の交換は、サーバー認証手順で署名される Diffie-Hellman 短期鍵の交換で構成されます。さらに、Solaris Secure Shell は認証に GSS 資格を使用することもできます。

Solaris Secure Shell での GSS 資格の取得

Solaris Secure Shell で認証のために GSS-API を使用するには、サーバーが GSS-API のアクセプタの資格を持ち、クライアントが GSS-API のイニシエータの資格を持つ必要があります。mech_dh および mech_krb5 がサポートされています。

mech_dh では、サーバーは、root が keylogin コマンドを実行すると、GSS-API アクセプタの資格を持ちます。

mech_krb5 では、サーバーは、サーバーに対応するホスト主体が /etc/krb5/krb5.keytab で有効なエントリを持つと、GSS-API アクセプタの資格を持ちます。

クライアントは、次のどちらかによって、mech_dh に対するイニシエータの資格を持ちます。

• keylogin コマンドが実行された。

• pam_dhkeys モジュールが pam.conf ファイルで使用されている。

クライアントは、次のどちらかによって、mech_krb5 に対するイニシエータの資格を持ちます。

• kinit コマンドが実行された。

• pam_krb5 モジュールが pam.conf ファイルで使用されている。

Secure RPC での mech_dh の使用方法については、第 16 章認証サービスの使用 (手順)を参照してください。mech_krb5 の使用方法については、第 21 章Kerberos サービスについてを参照してください。メカニズムの詳細については、mech(4) および mech_spnego(5) のマニュアルページを参照してください。

Solaris Secure Shell でのコマンドの実行とデータの転送

認証が完了すると、ユーザーは通常、シェルまたはコマンド実行を要求して Solaris Secure Shell を使用します。ユーザーは、ssh のオプションを使用して、要求を行うことができます。要求には、擬似端末の配置、X11 または TCP/IP の接続の転送、セキュリティー保護された接続上での ssh-agent 認証プログラムの有効化などがあります。

ユーザーセッションの基本手順は次のとおりです。

1. ユーザーがシェルまたはコマンドの実行を要求し、セッションモードを開始します。

   セッションモードでは、クライアント側では、データは端末を通して送受信されます。また、サーバー側ではシェルまたはコマンドを介して送受信されます。

2. データの転送が完了すると、ユーザープログラムは終了します。

3. 既存の接続を除いて、すべての X11 接続と TCP/IP 接続の転送を停止します。既存の X11 接続と TCP/IP 接続は、開いたままです。

4. サーバーは、終了状態のメッセージをクライアントに送信します。開いたままになっていた転送先のポートなど、すべての接続が切断されると、クライアントはサーバーへの接続を切断します。その後、クライアントが終了します。

Solaris Secure Shell でのクライアントとサーバーの構成

Solaris Secure Shell セッションの特性は、構成ファイルで変更できます。構成ファイルに対しては、コマンド行オプションを使用することで、ある程度優先することができます。

Solaris Secure Shell でのクライアントの構成

ほとんどの場合、Solaris Secure Shell セッションのクライアント側の特性は、システム全体の構成ファイル (/etc/ssh/ssh_config) によって決定されます。ユーザーの構成ファイル (~/.ssh/config) は、 ssh_config ファイル内の設定より優先されます。さらに、コマンド行での指定は、これらの構成ファイルより優先されます。

サーバーの /etc/ssh/sshd_config ファイル内の設定によって、クライアント側のどの要求がサーバーによって許可されるかが決まります。サーバー構成の設定の一覧については、「Solaris Secure Shell でのキーワード」を参照してください。詳細は、sshd_config(4) のマニュアルページを参照してください。

クライアントの構成ファイルのキーワードは、「Solaris Secure Shell でのキーワード」 に一覧表示されています。キーワードにデフォルト値がある場合は、その値が指定されます。これらのキーワードについては、ssh(1)、scp(1)、sftp(1)、および ssh_config(4) のマニュアルページに詳細を記載しています。アルファベット順のキーワードと相当するコマンド行の優先指定の一覧については、表 20–8 を参照してください。

Solaris Secure Shell でのサーバーの構成

サーバー側の Solaris Secure Shell セッションの特性は、/etc/ssh/sshd_config ファイルによって管理されます。サーバーの構成ファイルのキーワードは、「Solaris Secure Shell でのキーワード」 に一覧表示されています。キーワードにデフォルト値がある場合は、その値が指定されます。キーワードの詳細については、sshd_config(4) のマニュアルページを参照してください。

Solaris Secure Shell でのキーワード

次の表は、キーワードおよびそのデフォルト値 (存在する場合) の一覧です。キーワードはアルファベット順になっています。クライアント側のキーワードは、ssh_config ファイルにあります。サーバーに適用されるキーワードは、sshd_config ファイルにあります。両方のファイルで設定されているキーワードもあります。キーワードが 1 つのプロトコルのバージョンにのみ適用される場合には、そのバージョンが記載されています。

Solaris Secure Shell でのホスト固有のパラメータ

ローカルホストごとに異なる Solaris Secure Shell 特性を使用すると便利な場合、システム管理者は適用される /etc/ssh/ssh_config ファイルにホストまたはその正規表現形式に従って別々のパラメータセットを定義できます。ファイル内のエントリを、Host キーワードでグループ化してください。Host キーワードを使用しない場合、クライアント構成ファイル内のエントリは、ユーザーが使用しているローカルホストに適用されます。

Solaris Secure Shell およびログインの環境変数

次の Solaris Secure Shell キーワードが sshd_config ファイルに存在しないときは、 /etc/default/login ファイルの相当するエントリから値を取得します。

次の変数は、ユーザーのログインシェルから初期化スクリプトで設定され、sshd デーモンによってその値が使用されます。変数が設定されていない場合には、デーモンはデフォルト値を使用します。

TIMEZONE

TZ 環境変数の設定を制御します。設定されていない場合、sshd デーモンの起動時のTZ の値を使用します。

ALTSHELL

SHELL 環境変数の設定を制御します。デフォルトは ALTSHELL=YES で、sshd デーモンはユーザーのシェルの値を使用します。ALTSHELL=NO の場合、SHELL の値は設定されません。

PATH

PATH 環境変数の設定を制御します。値が設定されていない場合、デフォルトのパスは /usr/bin になります。

SUPATH

root に対する PATH 環境変数の設定を制御します。値が設定されていない場合、デフォルトのパスは /usr/sbin:/usr/bin になります。

詳細は、login(1) および sshd(1M) のマニュアルページを参照してください。

Solaris Secure Shell での既知のホストの管理

ホスト間の通信を安全に行うには、各ローカルホストの /etc/ssh/ssh_known_hosts ファイルにサーバーの公開鍵を格納する必要があります。 /etc/ssh/ssh_known_hosts ファイルを更新するときに、スクリプトを使用することもできますが、セキュリティーが大幅に低下するため、使用しないことを強くお勧めします。

/etc/ssh/ssh_known_hosts ファイルを配布するときは、次のようなセキュリティー保護されたメカニズムで行う必要があります。

• Solaris Secure Shell、IPsec、または Kerberos を使用した ftp などのセキュリティー保護された接続を使用して、既知の信頼できるマシンから配布する

• システムインストール時に配布する

known_hosts ファイルに偽の公開鍵を挿入してアクセス権を取得しようとする侵入者がいる可能性をなくすには、ssh_known_hosts ファイルの既知の信頼できる入手先として、Solaris JumpStart サーバーを使用します。ssh_known_hosts ファイルは、インストール中に配布できます。あとで、scp コマンドを使用するスクリプトを使用して、最新バージョンを取り込むこともできます。この方法は、JumpStart サーバーから得た公開鍵がすでに各ホストに保管されているため安全です。

Solaris Secure Shell のパッケージと初期化

Solaris Secure Shell は、Solaris の主要パッケージと次のパッケージに依存します。

• SUNWgss – Generic Security Service (GSS) ソフトウェアを含みます

• SUNWtcpd – TCP ラッパーを含みます

• SUNWopenssl-libraries – OpenSSL ライブラリを含みます

• SUNWzlib – zip 圧縮ライブラリを含みます

次のパッケージによって Solaris Secure Shell がインストールされます。

• SUNWsshr – ルート (/) ディレクトリのクライアントファイルおよびユーティリティーを含みます

• SUNWsshdr – ルート (/) ディレクトリのサーバーファイルおよびユーティリティーを含みます

• SUNWsshcu – /usr ディレクトリの共通ソースファイルを含みます

• SUNWsshdu – /usr ディレクトリのサーバーファイルを含みます

• SUNWsshu – /usr ディレクトリのクライアントファイルおよびユーティリティーを含みます

インストール後システムを再起動すると、sshd デーモンが実行されます。デーモンは、そのシステム上でホスト鍵を作成します。sshd デーモンを実行する Solaris システムが Solaris Secure Shell サーバーです。

Solaris Secure Shell ファイル

次の表は、重要な Solaris Secure Shell ファイルと推奨されるファイルアクセス権を示します。

次の表は、キーワードまたはコマンドオプションが優先される Solaris Secure Shell ファイルの一覧です。

Solaris Secure Shell コマンド

次の表は、主要な Solaris Secure Shell コマンドの要約です。

次の表は、Solaris Secure Shell のキーワードに優先するコマンドオプションの一覧です。キーワードは、ssh_config ファイルおよび sshd_config ファイルで指定します。