標準的な Secure Shell セッション

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

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

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

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

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

• コマンド行オプション

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

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

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

Secure Shell での認証と鍵の交換

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

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

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

Secure Shell での GSS 資格の取得

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) のマニュアルページを参照してください。

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

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

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

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

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

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

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

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