Solaris のシステム管理 (セキュリティサービス)

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

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

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

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

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 での 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 セッションを開始する前にサーバーと同期を取るため、クライアントの要求は拒否されません。

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

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

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

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

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

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

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

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

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

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

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


注 –

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


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

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

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

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

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

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

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

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

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

作業 

説明 

参照先 

1. キーサーバーを起動します。 

ユーザーが認証されるために鍵を作成できるようにします。 

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

2. NIS+ ホストで資格を設定します。 

NIS+ 環境でホスト上の root ユーザーが認証されるようにします。

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

3. NIS+ ユーザーに鍵を指定します。 

NIS+ 環境でユーザーが認証されるようにします。 

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

4. NIS ホストで資格を設定します。 

NIS 環境でホスト上の root ユーザーが認証されるようにします。

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

5. NIS ユーザーに鍵を指定します。 

NIS 環境でユーザーが認証されるようにします。 

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

6. 認証によって NFS ファイルを共有します。 

NFS サーバーが認証によって共有ファイルシステムを安全に保護できるようにします。 

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

Secure RPC による認証の管理

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

ProcedureSecure 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
    

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

この手順は、NIS+ ドメインのすべてのホストで実行します。rootkeylogin コマンドを実行すると、サーバーは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>
#

ProcedureNIS+ ユーザーに 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>
%

ProcedureNIS ホストに 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.
#

ProcedureNIS ユーザーに 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...

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

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

始める前に

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

PAM を使用する利点

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

PAM フレームワークの概要

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

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

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

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

この図は、アプリケーションと PAM サービスモジュールが PAM ライブラリにアクセスする方法を示しています。

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

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

PAM (手順)

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

PAM (作業マップ)

作業 

説明 

参照先 

PAM のインストールを計画します。 

ソフトウェア構成処理を開始する前に、構成を検討および決定します。 

「PAM の実装計画」

新しい PAM モジュールを追加します。 

必要に応じて、サイト固有のモジュールを作成およびインストールし、汎用ソフトウェアにない要件に対応します。この手順ではこれらの新しい PAM モジュールのインストール方法について説明します。 

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

~/.rhosts によるアクセスを拒否します。

~/.rhosts によるアクセスを拒否して、セキュリティーを強化します。

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

エラー記録を開始します。 

syslog を使用して PAM エラーメッセージの記録を開始します。

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

PAM の実装計画

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    # svcadm disable network/shell
    

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

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

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

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

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

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


    # svcadm refresh system/system-log
    

PAM の構成 (参照)

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

PAM 構成ファイルの構文

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

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

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

module-type

サービスのタイプ。具体的には authaccountsessionpassword のいずれかです。

control-flag

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

module-path

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

module-options

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

PAM スタックのしくみ

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

認証管理やアカウント管理など、このサービスのある操作に対するモジュールが /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 モジュールが果たす役割を示します。制御フラグとその効果は、次のとおりです。

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

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

このフロー図は、制御フラグが PAM スタックにどのような影響を与えるのかを示しています。

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

このフロー図は、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_dhkeyspam_unix_auth のいずれかが失敗を返していた場合、ユーザーは rlogin 経由でのアクセスを拒否されます。


第 18 章 SASL の使用

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

SASL (概要)

簡易認証セキュリティー層 (SASL) は、ネットワークプロトコルに認証サービスとセキュリティーサービス (オプション) を提供するフレームワークです。アプリケーションは、SASL ライブラリ /usr/lib/libsasl.so を呼び出します。SASL ライブラリは、アプリケーションと各種 SASL メカニズムを結び付ける層の役割を果たします。このメカニズムは、認証プロセスや、オプションのセキュリティーサービスの提供時に使用されます。Solaris 10 リリースで提供される SASL のバージョンは、いくつかの変更が行われた Cyrus 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 には、遠隔ログインおよび遠隔ファイル転送を行うコマンドが組み込まれています。この章で説明する内容は次のとおりです。

参照情報については、第 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 では、次の操作を行うことができます。

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


注 –

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


Solaris Secure Shell 認証

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

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

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

表 19–1 Solaris Secure Shell の認証方式

認証方式 (プロトコルのバージョン) 

ローカルホスト (クライアント) の要件 

遠隔ホスト (サーバー) の要件 

GSS-API (v2)

GSS メカニズムのイニシエータの資格。 

GSS メカニズムのアクセプタの資格。詳細については、「Solaris Secure Shell での GSS 資格の取得」を参照してください。

ホストベース (v2)

ユーザーアカウント 

/etc/ssh/ssh_host_rsa_key または /etc/ssh/ssh_host_dsa_key にローカルホストの非公開鍵

/etc/ssh/ssh_config 内で HostbasedAuthentication yes

ユーザーアカウント 

/etc/ssh/known_hosts または ~/.ssh/known_hosts にローカルホストの公開鍵

/etc/ssh/sshd_config 内で HostbasedAuthentication yes

/etc/ssh/sshd_config 内で IgnoreRhosts no

/etc/ssh/shosts.equiv/etc/hosts.equiv~/.rhosts、または ~/.shosts にローカルホストのエントリ

RSA または DSA 公開鍵 (v2)

ユーザーアカウント 

~/.ssh/id_rsa または ~/.ssh/id_dsa に非公開鍵

~/.ssh/id_rsa.pub または ~/.ssh/id_dsa.pub にユーザーの公開鍵

ユーザーアカウント 

~/.ssh/authorized_keys にユーザーの公開鍵

RSA 公開鍵 (v1) 

ユーザーアカウント 

~/.ssh/identity に非公開鍵

~/.ssh/identity.pub にユーザーの公開鍵

ユーザーアカウント 

~/.ssh/authorized_keys にユーザーの公開鍵

キーボードによる対話 (v2)

ユーザーアカウント 

ユーザーアカウント 

パスワードの有効期限が切れたときの任意のプロンプトやパスワード変更など、PAM をサポートします。 

パスワードに基づく (v1 または v2)

ユーザーアカウント 

ユーザーアカウント 

PAM をサポートします。 

.rhosts のみ (v1)

ユーザーアカウント 

ユーザーアカウント 

/etc/ssh/sshd_config 内で IgnoreRhosts no

/etc/ssh/shosts.equiv/etc/hosts.equiv~/.shosts、または ~/.rhosts にローカルホストのエントリ

.rhosts と RSA (v1) (サーバーのみ)

ユーザーアカウント 

/etc/ssh/ssh_host_rsa1_key にローカルホストの公開鍵

ユーザーアカウント 

/etc/ssh/ssh_known_hosts または ~/.ssh/known_hosts にローカルホストの公開鍵

/etc/ssh/sshd_config 内で IgnoreRhosts no

/etc/ssh/shosts.equiv/etc/hosts.equiv~/.shosts、または ~/.rhosts にローカルホストのエントリ

企業における 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」の順にクリックします。アーカイブには次の記事が含まれています。

Solaris Secure Shell と OpenSSH プロジェクト

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

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

Solaris 9 リリース以降、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 の使用 (作業マップ)」

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

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

作業 

説明 

参照先 

ホストに基づく認証を構成します 

クライアントとサーバーでのホストに基づく認証を構成します。 

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

v1 および v2 を使用できるようにホストを構成します 

v1 および v2 のプロトコルを使用するホストに対して公開鍵のファイルを作成します。 

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

ポート転送を構成します 

ユーザーがポート転送を使用できるようにします。 

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

Solaris Secure Shell の構成

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

Procedureホストに基づく認証を 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 ファイルで、IgnoreRhostsno に設定します。


    ## 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 接続を開始できます。次の構成によって、各ホストがサーバーおよびクライアントになります。


ProcedureSolaris 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
    

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

ProcedureSolaris 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 で使用する公開鍵と非公開鍵のペアを生成する方法」

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

非公開鍵を認証するフレーズを変更します。 

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

Solaris Secure Shell を使用してログインします 

遠隔ログイン時に、暗号化された Solaris Secure Shell 通信を行うことができるようにします。この方法は、 rsh コマンドを使用する場合と同様です。

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

パスワードのプロンプトを表示せずに Solaris Secure Shell にログインします  

パスワードを Solaris Secure Shell に提供するエージェントを使用してログインできるようにします。 

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

   

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

Solaris Secure Shell のポート転送を使用します 

TCP 経由の Solaris Secure Shell 接続で使用するローカルポートまたは遠隔ポートを指定します。 

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

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

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

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

ファイアウォールの内部のホストから外部のホストに安全に接続します 

HTTP または SOCKS5 と互換性のある Solaris Secure Shell のコマンドを使用して、ファイアウォールで分断されているホスト間を接続します。 

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

Solaris Secure Shell の使用

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

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

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

始める前に

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

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


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

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

  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"'

ProcedureSolaris 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 は、非公開鍵ファイルのパスフレーズの変更を要求します。

ProcedureSolaris 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%

ProcedureSolaris 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)

ProcedureCDE で 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 セッションでこの手順を実行しても、エージェントデーモンは終了しません。

ProcedureSolaris 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 のサーバーポートです。ユーザーがメールアプリケーションを起動するときは、次のダイアログボックスのように、ローカルポート番号を指定する必要があります。

ダイアログボックスのタイトルは「Mailer - Login」です。「IMAP Server」フィールドでは、サーバー名のあとにコロンとポート番号が続きます。

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



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

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


myLocalHost% ssh -R 9022:myLocalHost:22 myOutsideHost

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


myOutsideHost% ssh -p 9022 localhost
myLocalHost%

ProcedureSolaris 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

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

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

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

ファイルは、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

    これらのオプションは、プロキシサーバーとプロキシポートをそれぞれ指定します。これらのオプションは、HTTPPROXYHTTPPROXYPORTSOCKS5_PORTSOCKS5_SERVERhttp_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 オプションには、プロキシコマンドを指定するコマンド行を入力できます。この例のコマンドは次のことを行います。


第 20 章 Solaris Secure Shell (参照)

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

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

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

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

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

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

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

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

たとえば、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 では、サーバーは、rootkeylogin コマンドを実行すると、GSS-API アクセプタの資格を持ちます。

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

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

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

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 つのプロトコルのバージョンにのみ適用される場合には、そのバージョンが記載されています。

表 20–1 Solaris Secure Shell 構成ファイルでのキーワード (A から Escape まで)

キーワード 

デフォルト値 

場所 

プロトコル 

AllowGroups

デフォルトなし 

サーバー 

 

AllowTcpForwarding

yes

サーバー 

 

AllowUsers

デフォルトなし 

サーバー 

 

AuthorizedKeysFile

~/.ssh/authorized_keys

サーバー 

 

Banner

/etc/issue

サーバー 

 

Batchmode

no

クライアント 

 

BindAddress

デフォルトなし 

クライアント 

 

CheckHostIP

yes

クライアント 

 

Cipher

blowfish3des

クライアント 

v1 

Ciphers

aes128-ctr、aes128-cbc、3des-cbc、blowfish-cbc、arcfour

両方 

v2 

ClearAllForwardings

デフォルトなし 

クライアント 

 

ClientAliveInterval

0

サーバー 

v2 

ClientAliveCountMax

3

サーバー 

v2 

Compression

yes

両方 

 

CompressionLevel

デフォルトなし 

クライアント 

 

ConnectionAttempts

1

クライアント 

 

DenyGroups

デフォルトなし 

サーバー 

 

DenyUsers

デフォルトなし 

サーバー 

 

DynamicForward

デフォルトなし 

クライアント 

 

EscapeChar

~

クライアント 

 

表 20–2 Solaris Secure Shell 構成ファイルでのキーワード (Fall から Local まで)

キーワード 

デフォルト値 

場所 

プロトコル 

FallBackToRsh

no

クライアント 

 

ForwardAgent

no

クライアント 

 

ForwardX11

no

クライアント 

 

GatewayPorts

no

両方 

 

GlobalKnownHostsFile

/etc/ssh/ssh_known_hosts

クライアント 

 

GSSAPIAuthentication

yes

両方 

v2 

GSSAPIDelegateCredentials

no

クライアント 

v2 

GSSAPIKeyExchange

yes

両方 

v2 

GSSAPIStoreDelegateCredentials

no

クライアント 

v2 

Host

* 詳細については、「Solaris Secure Shell でのホスト固有のパラメータ」を参照してください。

クライアント 

 

HostbasedAuthentication

no

両方 

v2 

HostbasedUsesNamesFromPacketOnly

no

サーバー 

v2 

HostKey

/etc/ssh/ssh_host_key

サーバー 

v1 

HostKey

/etc/ssh/host_rsa_key/etc/ssh/host_dsa_key

サーバー 

v2 

HostKeyAlgorithms

ssh-rsa、ssh-dss

クライアント 

v2 

HostKeyAlias

デフォルトなし 

クライアント 

v2 

IdentityFile

~/.ssh/identity

クライアント 

v1 

IdentityFile

~/.ssh/id_dsa、~/.ssh/id_rsa

クライアント 

v2 

IgnoreRhosts

yes

サーバー 

 

IgnoreUserKnownHosts

yes

サーバー 

 

KbdInteractiveAuthentication

yes

両方 

 

KeepAlive

yes

両方 

 

KeyRegenerationInterval

3600 (秒)

サーバー 

 

ListenAddress

デフォルトなし 

サーバー 

 

LocalForward

デフォルトなし 

クライアント 

 

表 20–3 Solaris Secure Shell 構成ファイルでのキーワード (Login から R まで)

キーワード 

デフォルト値 

場所 

プロトコル 

LoginGraceTime

600 (秒)

サーバー 

 

LogLevel

info

両方 

 

LookupClientHostname

yes

サーバー 

 

MACs

hmac-sha1、hmac-md5

両方 

v2 

MaxAuthTries

6

サーバー 

 

MaxAuthTriesLog

サーバー 

 

MaxStartups

10:30:60

サーバー 

 

NoHostAuthenticationForLocalHost

no

クライアント 

 

NumberOfPasswordPrompts

3

クライアント 

 

PAMAuthenticationViaKBDInt

yes

サーバー 

v2 

PasswordAuthentication

yes

両方 

 

PermitEmptyPasswords

no

サーバー 

 

PermitRootLogin

no

サーバー 

 

PermitUserEnvironment

no

サーバー 

 

PreferredAuthentications

gssapi-keyex、gssapi-with-mic、hostbased、publickey、keyboard-interactive、password

クライアント 

v2 

Port

22

両方 

 

PrintMotd

no

サーバー 

 

Protocol

2

両方 

 

ProxyCommand

デフォルトなし 

クライアント 

 

PubkeyAuthentication

yes

両方 

v2 

RemoteForward

デフォルトなし 

クライアント 

 

RhostsAuthentication

no

両方 

v1 

RhostsRSAAuthentication

no

両方 

v1 

RSAAuthentication

no

両方 

v1 

表 20–4 Solaris Secure Shell 構成ファイルでのキーワード (S から X まで)

キーワード 

デフォルト値 

場所 

プロトコル 

ServerKeyBits

768

サーバー 

 

StrictHostKeyChecking

ask

クライアント 

 

StrictModes

yes

サーバー 

 

Subsystem

sftp /usr/lib/ssh/sftp-server

サーバー 

 

SyslogFacility

auth

サーバー 

 

UseLogin

no 非推奨として無視される

サーバー 

 

UseOpenSSLEngine

yes

両方 

v2 

User

デフォルトなし 

クライアント 

 

UserKnownHostsFile

~/.ssh/known_hosts

クライアント 

 

VerifyReverseMapping

no

サーバー 

 

X11Forwarding

yes

サーバー 

 

X11DisplayOffset

10

サーバー 

 

X11UseLocalHost

yes

サーバー 

 

XAuthLocation

/usr/openwin/bin/xauth

両方 

 

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

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

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

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

/etc/default/login のエントリ

sshd_config のキーワードと値

CONSOLE=*

PermitRootLogin=without-password

#CONSOLE=*

PermitRootLogin=yes

PASSREQ=YES

PermitEmptyPasswords=no

PASSREQ=NO

PermitEmptyPasswords=yes

#PASSREQ

PermitEmptyPasswords=no

TIMEOUT=secs

LoginGraceTime=secs

#TIMEOUT

LoginGraceTime=300

RETRIES および SYSLOG_FAILED_LOGINS

password および keyboard-interactive 認証方式にのみ適用される

次の変数は、ユーザーのログインシェルから初期化スクリプトで設定され、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 ファイルを配布するときは、次のようなセキュリティー保護されたメカニズムで行う必要があります。

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

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

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

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

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

Solaris Secure Shell ファイル

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

表 20–5 Solaris Secure Shell ファイル

ファイル名 

説明 

推奨アクセス権と所有者 

/etc/ssh/sshd_config

sshd (Solaris Secure Shell デーモン) の構成データを含みます。

-rw-r--r-- root

/etc/ssh/ssh_host_key

ホスト非公開鍵 (v1) を含みます。 

-rw------- root

/etc/ssh/ssh_host_dsa_key または /etc/ssh/ssh_host_rsa_key

ホスト非公開鍵 (v2) を含みます。 

-rw------- root

host-private-key.pub

ホスト公開鍵を含みます。/etc/ssh/ssh_host_rsa_key.pub など。ホスト鍵をローカル known_hosts ファイルにコピーするときに使用します。

-rw-r--r-- root

/var/run/sshd.pid

Solaris Secure Shell デーモン sshd のプロセス ID を含みます。複数のデーモンが実行されている場合は、起動された最後のデーモンを含みます。

-rw-r--r-- root

~/.ssh/authorized_keys

ユーザーアカウントへのログインが許可されているユーザーの公開鍵を保持します。 

-rw-r--r-- username

/etc/ssh/ssh_known_hosts

このクライアントがセキュリティー保護された通信を行うことのできるすべてのホストのホスト公開鍵を含みます。このファイルはシステム管理者が管理します。 

-rw-r--r-- root

~/.ssh/known_hosts

このクライアントがセキュリティー保護された通信を行うことのできるすべてのホストのホスト公開鍵を含みます。このファイルは自動的に管理されます。ユーザーが未知のホストに接続すると、遠隔ホスト鍵がファイルに追加されます。 

-rw-r--r-- username

/etc/default/login

対応する sshd_config パラメータが設定されていないときの、sshd デーモンのデフォルトを指定します。

-r--r--r-- root

/etc/nologin

このファイルが存在する場合、sshd デーモンは root のログインのみを許可します。このファイルの内容は、ログインしようとするユーザーに対して表示されます。

-rw-r--r-- root

~/.rhosts

ホスト名とユーザー名のペアを含みます。ユーザーは、対応するホストにパスワードを使用しないでログインできます。このファイルは、rlogind デーモンおよび rshd デーモンでも使用されます。

-rw-r--r-- username

~/.shosts

ホスト名とユーザー名のペアを含みます。ユーザーは、対応するホストにパスワードを使用しないでログインできます。このファイルは、ほかのユーティリティーでは使用されません。詳細については、sshd(1M) のマニュアルページの「FILES」節を参照してください。

-rw-r--r-- username

/etc/hosts.equiv

.rhosts 認証で使用されるホストを含みます。このファイルは、rlogind デーモンおよび rshd デーモンでも使用されます。

-rw-r--r-- root

/etc/ssh/shosts.equiv

ホストに基づく認証で使用されるホストを含みます。このファイルは、ほかのユーティリティーでは使用されません。 

-rw-r--r-- root

~/.ssh/environment

ログイン時の初期割り当てを含みます。デフォルトでは、このファイルは読み取られません。このファイルを読み取るには、sshd_config ファイルの PermitUserEnvironment キーワードが yes に設定されている必要があります。

-rw-r--r-- username

~/.ssh/rc

ユーザーシェルが起動する前に実行される初期化ルーチンを含みます。初期化ルーチンの例については、sshd のマニュアルページを参照してください。 

-rw-r--r-- username

/etc/ssh/sshrc

システム管理者が用意したホスト固有の初期化ルーチンを含みます。 

-rw-r--r-- root

/etc/ssh/ssh_config

クライアントシステムでのシステム設定を構成します。 

-rw-r--r-- root

~/.ssh/config

ユーザーの設定を構成します。システム設定より優先されます。 

-rw-r--r-- username

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

表 20–6 優先される Solaris Secure Shell ファイルの場所

ファイル名 

キーワードの優先指定 

コマンド行の優先指定 

/etc/ssh/ssh_config

 

ssh -F config-file

scp -F config-file

~/.ssh/config

 

ssh -F config-file

/etc/ssh/host_rsa_key

/etc/ssh/host_dsa_key

HostKey

 

~/.ssh/identity

~/.ssh/id_dsa, ~/.ssh/id_rsa

IdentityFile

ssh -i id-file

scp -i id-file

~/.ssh/authorized_keys

AuthorizedKeysFile

 

/etc/ssh/ssh_known_hosts

GlobalKnownHostsFile

 

~/.ssh/known_hosts

UserKnownHostsFile

IgnoreUserKnownHosts

 

Solaris Secure Shell コマンド

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

表 20–7 Solaris Secure Shell でのコマンド

コマンド 

説明 

マニュアルページ 

ssh

ユーザーを遠隔マシンにログインさせ、遠隔マシン上でコマンドを安全に実行します。このコマンドは、Solaris Secure Shell での、rlogin コマンドと rsh コマンドに代わるコマンドです。ssh コマンドは、セキュリティー保護されていないネットワークを介して 2 つの信頼できないホスト間でセキュリティー保護された暗号化通信を行うことを可能にします。X11 接続と任意の TCP/IP ポートも、セキュリティー保護されたチャネルを介して転送されます。

ssh(1)

sshd

Solaris Secure Shell 用のデーモンです。このデーモンは、クライアントからの接続を待機します。セキュリティー保護されていないネットワークを介して 2 つの信頼できないホスト間でセキュリティー保護された暗号化通信を行うことを可能にします。 

sshd(1M)

ssh-add

RSA または DSA ID を認証エージェント ssh-agent に追加します。ID は「鍵」とも呼ばれます。

ssh-add(1)

ssh-agent

公開鍵認証時に使用される非公開鍵を保持します。ssh-agent プログラムは、X セッションまたはログインセッションの開始時に起動します。ほかのすべてのウィンドウおよびプログラムは、ssh-agent プログラムのクライアントとして起動します。環境変数を使用すれば、ユーザーが ssh コマンドを使用してほかのシステムにログインするときに、エージェントを検出して認証に使用することができます。

ssh-agent(1)

ssh-keygen

Solaris Secure Shell の認証鍵を生成および管理します。 

ssh-keygen(1)

ssh-keyscan

多数の Solaris Secure Shell ホストの公開鍵を収集します。ssh_known_hosts ファイルの作成および検証時に役立ちます。

ssh-keyscan(1)

ssh-keysign

ssh コマンドがローカルホスト上のホスト鍵にアクセスするときに使用されます。Solaris Secure Shell v2 によるホストに基づく認証中に必要となるデジタル署名を生成します。このコマンドは、ユーザーではなく ssh コマンドによって呼び出されます。

ssh-keysign(1M)

scp

暗号化された ssh トランスポートを介して、ネットワーク上のホスト間でファイルを安全にコピーします。rcp コマンドと異なり、scp コマンドは、パスワード情報が認証に必要な場合、パスワードまたはパスフレーズを要求します。

scp(1)

sftp

ftp コマンドと同様の対話型ファイル転送プログラムです。ftp コマンドと異なり、sftp コマンドは、暗号化された ssh トランスポートを介してすべての操作を実行します。このコマンドは、指定したホスト名に接続してログインし、対話型コマンドモードに入ります。

sftp(1)

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

表 20–8 Solaris Secure Shell のキーワードに相当するコマンド行

キーワード 

ssh コマンド行の優先指定

scp コマンド行の優先指定

BatchMode

 

scp -B

BindAddress

ssh -b bind-addr

scp -a bind-addr

Cipher

ssh -c cipher

scp -c cipher

Ciphers

ssh -c cipher-spec

scp -c cipher-spec

Compression

ssh -C

scp -C

DynamicForward

ssh -D SOCKS4-port

 

EscapeChar

ssh -e escape-char

 

ForwardAgent

ssh -A (有効)

ssh -a (無効)

 

ForwardX11

ssh -X (有効)

ssh -x (無効)

 

GatewayPorts

ssh -g

 

IPv4

ssh -4

scp -4

IPv6

ssh -6

scp -6

LocalForward

ssh -L localport:remotehost:remoteport

 

MACS

ssh -m mac-spec

 

Port

ssh -p port

scp -P port

Protocol

ssh -1 (v1 のみ)

ssh -2 (v2 のみ)

 

RemoteForward

ssh -R remoteport:localhost:localport