Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. I 認証
    1. 2 PAM を利用した認証
    2. 3 NIS の使用
    3. 4 YaST を利用した認証クライアントの設定
    4. 5 389 Directory Server を利用した LDAP サービス
    5. 6 Kerberos を利用したネットワーク認証
    6. 7 Active Directory サポート
    7. 8 FreeRADIUS サーバの構築
  4. II ローカルセキュリティ
    1. 9 物理的なセキュリティ
    2. 10 ソフトウエア管理
    3. 11 ファイルの管理
    4. 12 パーティションやファイルの暗号化
    5. 13 cryptctl を利用したアプリケーション向けのストレージ暗号化
    6. 14 ユーザ管理
    7. 15 cronat の制限
    8. 16 Spectre/Meltdown チェッカー
    9. 17 YaST を利用したセキュリティの設定
    10. 18 Polkit 認可フレームワーク
    11. 19 Linux でのアクセス制御リスト
    12. 20 AIDE を利用した侵入検知
  5. III ネットワークセキュリティ
    1. 21 X Window System と X 認証
    2. 22 OpenSSH によるネットワーク操作の機密保持
    3. 23 マスカレードとファイアウオール
    4. 24 VPN サーバの設定
    5. 25 X Window System で動作する PKI マネージャ XCA による管理
    6. 26 sysctl 変数によるネットワークセキュリティの改善
  6. IV AppArmor による権限の制限
    1. 27 AppArmor の紹介
    2. 28 入門
    3. 29 プログラムに対する予防接種
    4. 30 プロファイルのコンポーネントと文法
    5. 31 AppArmor のプロファイルリポジトリ
    6. 32 YaST を利用したプロファイルの構築と管理
    7. 33 コマンドラインからのプロファイル構築
    8. 34 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 35 pam_apparmor によるユーザの制限
    10. 36 プロファイルを作成したアプリケーションの管理
    11. 37 サポート
    12. 38 AppArmor 用語集
  7. V SELinux
    1. 39 SELinux の設定
  8. VI Linux 監査フレームワーク
    1. 40 Understanding Linux audit
    2. 41 Linux 監査フレームワークの設定
    3. 42 監査ルールセットの紹介
    4. 43 その他の情報源
  9. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.6

2 PAM を利用した認証 Edit source

概要

Linux では認証処理に際して PAM (Pluggable Authentication Modules; プラグインを使用することのできる認証モジュール) を利用し、ユーザとアプリケーションとの間の仲介を行っています。 PAM のモジュールはシステム全体に対して提供されているため、様々なアプリケーションから利用できるようになっています。本章では、このようなモジュール型の認証機構の動作と、設定方法について説明しています。

2.1 PAM とは? Edit source

システム管理者やプログラマは、システムの特定の箇所や、アプリケーション内の特定の機能に対してアクセスを制限したいと考えることがあります。 PAM の無い状態では、それぞれのアプリケーションは LDAP や Samba, Kerberos など、様々な認証機構に対応しなければならなくなります。このような開発には時間を要するばかりか、開発によってエラーを引き起こす可能性すらあります。このような欠点を防ぐ唯一の方法は、認証の仕組みとアプリケーションを分離するという方法で、集中管理されたモジュール内で、認証の仕組みを代行させるやり方です。このような仕組みであれば、新しい認証方式が開発された場合でも、対応する PAM モジュール を作成すれば、アプリケーション側ですぐに利用できるようになります。

PAM は下記のような考え方から成り立っています:

  • PAM モジュール: 特定の認証機構に対応する共有ライブラリです。

  • モジュールスタック: 複数の PAM モジュールから構成されるものです。

  • PAM 対応の サービス: モジュールスタック、もしくは PAM モジュールを利用して、認証の仕組みを利用するものです。通常、サービスは loginsu のように、対応するアプリケーションに対する分かりやすい名前を指定します。サービス名 other は、既定のルールで使用される予約語です。

  • モジュールのパラメータ: 特定の PAM モジュールに対して、その処理に影響を与えるためのものです。

  • 結果: それぞれの PAM モジュールの実行結果を意味します。正の値が返された場合、次の PAM モジュールを実行します。負の値は設定によって異なる動作となり、 何も影響を与えず、そのまま次のモジュールに進む から 即時に終了する まで、様々な処理を行うことができます。

2.2 PAM 設定ファイルの構造 Edit source

PAM は下記の 2 種類の方式で設定することができます:

ファイルベースの設定 ( /etc/pam.conf )

それぞれのサービスに対する設定を /etc/pam.conf に書き込む方式です。この方式は、メンテナンス性と利便性が損なわれることから、 openSUSE Leap では使用していません。

ディレクトリベースの設定 ( /etc/pam.d/ )

PAM の仕組みを利用する各サービス (もしくはプログラム) に対する設定を、 /etc/pam.d/ ディレクトリ内のそれぞれの設定ファイルに保存する方式です。たとえば sshd サービスに対する設定は、 /etc/pam.d/sshd ファイル内に書き込むことになります。

/etc/pam.d/ ディレクトリ内のファイルでは、認証に使用する PAM モジュールを設定します。ファイル内の各行には最大で 4 つの値を指定します:

種類  制御
 モジュールパス  モジュールパラメータ

それぞれの意味は下記のとおりです:

種類

PAM モジュールの種類を指定します。 PAM モジュールはスタックとして処理されます。それぞれの種類はそれぞれ別々の目的で使用します。たとえば一方のモジュールではパスワードをチェックし、他方のモジュールではシステムにアクセスする際のアクセス元をチェックし、さらに別のモジュールではユーザ固有の設定を読み込む、などです。 PAM では、下記 4 つのモジュールの種類に対応しています:

auth

従来であればパスワードの問い合わせなど、ユーザの正当性を確認するための種類です。現在では IC カードによる認証や生体認証 (指紋認証、虹彩認証など) も使用することができます。

account

そのサービスを使用できる権限があるかどうかを確認するための種類です。たとえば有効期限の切れたユーザ名でログインできないようにする、などの目的で使用します。

password

認証トークン (通常はパスワード) の変更を有効化するための種類です。

session

ユーザセッションを管理したり設定したりするための種類です。ログインに際しては認証前と認証後の両方で開始され、ユーザ固有の環境 (メールアカウント、ホームディレクトリ、システム制限など) を設定するために使用します。

制御

PAM モジュールの動作を表す箇所です。それぞれのモジュールには、下記のような制御フラグを設定することができます:

required

このフラグを設定したモジュールは、認証を成功させるにあたって必ず成功しなければならないものであることを表します。 required フラグを設定したモジュールが失敗すると、同じフラグを設定した他のモジュールは、ユーザが認証失敗メッセージを受け取る前に処理が行われます。

requisite

このフラグを設定したモジュールは、 required フラグと同様に処理が成功しなければならないものであることを表します。ただし、このフラグを設定したモジュールが失敗すると、ユーザに対して即時にフィードバックが送られ、その他のモジュールは処理されなくなります。成功した場合は、 required フラグを設定した場合と同様に、その他のモジュールは引き続き処理されます。 requisite フラグは、認証を成功させるために必要な条件をチェックするための基本フィルタとして動作します。

sufficient

このフラグを設定したモジュールの処理が成功すると、それより前に存在する required フラグ付きのモジュールの処理が失敗しない限り、サービスは成功を示すメッセージを即時に受け取り、その他のモジュールが処理されなくなります。なお、 sufficient フラグが設定されたモジュールの処理が失敗しても、直接的な結果には至らず、残りのモジュールは通常通り処理されます。

optional

このフラグを設定したモジュールの処理は、成功した場合も失敗した場合も、直接的な影響を与えません。このフラグは、メッセージ (たとえばメールが到着しているなど) を表示し、それ以外の処理を行わないモジュールを使用する場合に有用です。

include

このフラグを指定した場合、この位置に指定した追加設定を取り込むことを表します。

モジュールパス

PAM モジュールに対する完全なファイル名を指定します。モジュールが既定のディレクトリ (32 ビット版の場合は /lib/security, 64 ビット版の場合は /lib64/security) 内に存在している場合、ディレクトリを指定する必要はありません。

モジュールパラメータ

PAM モジュールの動作に影響を与えるための、スペース区切りのパラメータリストです。たとえば debug (デバッグの有効化) や nullok (空のパスワードを許可する) などがあります。

これらに加えて、 /etc/security ディレクトリ内には PAM モジュール向けのグローバルな設定ファイルが用意されています。このディレクトリ内には、モジュールに対する動作設定が書かれています (pam_env.conftime.conf など) 。 PAM モジュールを使用する各アプリケーションは、 PAM の機能を実際に呼び出したあと、様々な設定ファイルに含まれる情報を処理して、結果を返します。

PAM モジュールの作成やメンテナンスを簡略化する目的で、 auth , account , password , session の各種類に対応する一般的な既定の設定ファイルが用意されています。これらは、各アプリケーション側の PAM 設定から読み込まれるようになっているため、これらの設定ファイルが更新されると、それぞれの PAM 設定ファイルを個別に書き換えることなく、各アプリケーションに適用できるようになっています。

このような PAM のグローバル設定ファイルは、 pam-config ツールを利用して管理します。このツールは設定ファイルに新しいモジュールを自動的に追加したり、既存の設定ファイルを変更したり、既存の設定ファイルからモジュール (もしくはオプション) を削除したりすることができます。このような仕組みにより、 PAM の設定ファイルを手作業で管理する手間が最小化できているばかりか、場合によっては全く不要にもなっています。

注記
注記: 64 ビットアプリケーションと 32 ビットアプリケーションの混在する環境について

64 ビットのオペレーティングシステムをお使いの場合、 32 ビットアプリケーション向けのランタイム環境をそろえることもできます。この場合、 32 ビット版の PAM モジュールを追加でインストールする必要があります。

2.3 sshd の PAM 設定 Edit source

sshd の PAM 設定ファイルを例として取り上げてみます:

例 2.1: sshd の PAM 設定 ( /etc/pam.d/sshd )
#%PAM-1.0 1
  

auth     requisite      pam_nologin.so                              2
auth     include        common-auth                                 3
account  requisite      pam_nologin.so                              2
account  include        common-account                              3
password include        common-password                             3
session  required       pam_loginuid.so                             4
session  include        common-session                              3
session  optional       pam_lastlog.so   silent noupdate showfailed 5

1

設定ファイルのバージョンを表す文字列です。慣習として書かれているだけの項目ですが、将来のバージョンでも使用できるよう、必ず記述しておくことをお勧めします。

2

/etc/nologin ファイルが存在するかどうかをチェックするモジュールの指定です。存在した場合、 root 以外のユーザがログインできなくなります。

3

4 種類のモジュールタイプに対して、それぞれ設定ファイルを参照しています (common-auth , common-account , common-password , common-session) 。これらの 4 種類のファイルには、それぞれのモジュールの種類に対応する既定の設定が含まれています。

4

認証を行ったプロセスに対して、ログイン UID プロセス属性を設定します。

5

ユーザの最終ログイン情報を表示します。

それぞれの PAM モジュールに対する設定ファイルに個別に追加していく代わりに、他の設定ファイルを取り込むように指定することで、管理者側が既定値を変更するだけで、その設定を取り込み元のモジュールに反映させることができるようになります。従来は PAM に対して変更があったり、新しいアプリケーションをインストールしたりするたびに、全ての設定ファイルを手作業で調整しなければなりませんでした。現在はこのような仕組みになっているため、設定の変更を一箇所で行うことができるようになっていて、各サービスの PAM 設定にもそのまま反映できるようになっています。

最初の include では common-auth という設定ファイルを取り込むように指定していますが、ここでは auth の種類に対して、 3 種類のモジュール (pam_env.so , pam_gnome_keyring.so , pam_unix.so を呼び出しています。詳しくは 例2.2「auth セクションに対する既定の設定 ( common-auth )」) をご覧ください。

例 2.2: auth セクションに対する既定の設定 ( common-auth )
auth  required  pam_env.so                   1
auth  optional  pam_gnome_keyring.so         2
auth  required  pam_unix.so  try_first_pass 3

1

pam_env.so/etc/security/pam_env.conf ファイルを読み込んで、そのファイルに指定されているとおりに環境変数を設定します。これは、 pam_env ではログインが行われた場所に関する情報を保持していることから、 DISPLAY 環境変数を適切な値に設定するために使用されています。

2

pam_gnome_keyring.so では、 GNOME 鍵リングに対してユーザのログイン名とパスワードをチェックします。

3

pam_unix は、ユーザのログイン名とパスワードを、 /etc/passwd および /etc/shadow でチェックします。

auth 内の全てのモジュールは、 sshd 側でログインが成功したかどうかについて、結果を得る前に処理が行われます。また、制御フラグ required が設定された全てのモジュールは、 sshd が肯定応答を受け取るよりも前に成功していなければなりません。これらのうちのいずれかのモジュールが成功以外の状態になると、残りのモジュールはそのまま処理されるものの、最終的には sshd が否定応答を受け取ることになります。

auth の種類が設定された全てのモジュールが成功すると、その他のステートメントが処理されるようになります。この場合は 例2.3「account セクションに対する既定の設定 ( common-account )」 で示されている内容になります。この common-account には 1 つのモジュール (pam_unix) のみが書かれています。この pam_unix は対象のユーザが存在しているかどうかを返すもので、 sshd が成功を表すメッセージを受け取ると、さらに続くモジュールスタック (この場合は 例2.4「password セクションに対する既定の設定 ( common-password )」 に示されている password) を実行することになります。

例 2.3: account セクションに対する既定の設定 ( common-account )
account  required  pam_unix.so  try_first_pass
例 2.4: password セクションに対する既定の設定 ( common-password )
password  requisite  pam_cracklib.so
password  optional   pam_gnome_keyring.so  use_authtok
password  required   pam_unix.so  use_authtok nullok shadow try_first_pass

sshd の PAM 設定では、 common-password のファイル名で指定されている password モジュール向けの既定の設定のみが include で設定されています。ここには、アプリケーションが認証トークンの変更を要求した場合、必ず成功しておかなければならないもの (制御フラグ requisite および required) が書かれています。

パスワードなどの認証トークンを変更する際には、セキュリティチェックを必要とします。セキュリティチェックは pam_cracklib モジュールで行います。 pam_unix モジュールはその後に動作するモジュールで、 pam_cracklib から古いパスワードと新しいパスワードを受け取ります。これにより、パスワードの変更に際しても、ユーザ側で再度認証を行う必要が無いようにしています。また、このような仕組みにより、 pam_cracklib 側のチェックは回避できないようにもなっています。 accountauth の種類でパスワードの有効期限を確認するよう設定する場合は、 password モジュールも使用する必要があります。

例 2.5: session セクションに対する既定の設定 ( common-session )
session  required  pam_limits.so
session  required  pam_unix.so  try_first_pass
session  optional  pam_umask.so
session  optional  pam_systemd.so
session  optional  pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
session  optional  pam_env.so

最後のステップとして、 session の種類が指定されたモジュール (common-session ファイル内に書かれています) を呼び出して、対象のユーザの設定に従ってセッションを設定します。 pam_limits モジュールは /etc/security/limits.conf ファイルを読み込むモジュールで、特定のシステム資源の使用に対して制限を設定することができるものです。ここでは再度 pam_unix モジュールを使用しています。 pam_umask モジュールは、ファイル作成時のマスクを設定するためのモジュールです。このモジュールには optional フラグが設定されているため、このモジュールの処理が失敗しても、セッションモジュールスタックの処理には影響を与えないようになっています。なお、 session の種類が設定されたモジュールは、ユーザがログアウトする際にも再度呼び出されます。

2.4 PAM モジュールの設定 Edit source

PAM モジュールによっては、設定ファイルが別途用意されているものがあります。設定ファイルは /etc/security 内に配置します。本章では、 sshd の例に示されているモジュール (pam_env.conf および limits.conf) について、概要を説明しています。

2.4.1 pam_env.conf Edit source

pam_env.conf は、 pam_env モジュールが呼び出された際に、対象のユーザに対して標準化された環境を設定するために使用するファイルです。このファイルでは、下記のような書式で環境変数を設定します:

変数名  [DEFAULT=]  [OVERRIDE=]
変数名

設定したい環境変数の名前を指定します。

[DEFAULT=<値>]

管理者側で設定したい既定値を指定します。

[OVERRIDE=<値>]

pam_env に対して問い合わせ、必要であれば既定値を上書きして設定する値を指定します。

pam_env の一般的な用途としては、 DISPLAY 環境変数があげられます。これはリモートからログインが行われることで、常に変化する可能性があるものです。詳しくは 例2.6「pam_env.conf」 をご覧ください。

例 2.6: pam_env.conf
REMOTEHOST  DEFAULT=localhost          OVERRIDE=@{PAM_RHOST}
DISPLAY     DEFAULT=${REMOTEHOST}:0.0  OVERRIDE=${DISPLAY}

最初の行では環境変数 REMOTEHOST の値に対して、 pam_env 側で判断が付かなかった場合、 localhost を設定するよう指定しています。 2 行目の DISPLAY 環境変数は、 REMOTEHOST の値をもとに設定を行う意味です。詳しくは /etc/security/pam_env.conf 内のコメント (英語) をお読みください。

2.4.2 pam_mount.conf.xml Edit source

pam_mount は、ログインの処理中にユーザのホームディレクトリをマウントし、ログアウト時にマウントを解除するためのモジュールです。一般的には、中央のファイルサーバ内にユーザのホームディレクトリが存在しているような環境で使用するものです。この方式を使用することで、 /home 全体を共有してマウントする必要がなくなり、ログインしているユーザのホームディレクトリのみをマウントして使用できるようになります。

pam_mount をインストールすると、 /etc/security 内に pam_mount.conf.xml に対するテンプレートファイルが用意されるようになります。要素の説明について、詳しくは man 5 pam_mount.conf で表示されるマニュアルページをお読みください。

なお、 YaST を利用することで、この機能に対する基本的な設定を行うことができます。 ネットワークサービス › Windows ドメインメンバーシップ › 熟練者向け設定 を選択して、ファイルサーバを追加してください。

2.4.3 limits.conf Edit source

システムに対する制限は、 pam_limits モジュールが読み込む limits.conf ファイルで設定することができます。制限はユーザ単位やグループ単位で設定することができます。このファイルでは、超過を許さないハード制限のほか、一時的であれば超過を許すソフト制限も設定することができます。文法とオプションについて、詳しくは /etc/security/limits.conf ファイル内のコメント (英語) をお読みください。

2.5 pam-config を利用した PAM の設定 Edit source

pam-config ツールは、グローバルな PAM 設定ファイル ( /etc/pam.d/common-* ) やいくつかのアプリケーション設定を行う際の支援ツールとなるものです。対応するモジュールの一覧は、 pam-config --list-modules を実行して得ることができます。また、 pam-config コマンドは、お使いの PAM 設定ファイルを管理するためにも使用することができます。 PAM 設定への新しいモジュールの追加や、既存のモジュールの削除、モジュールに対する設定の変更などを行うことができます。グローバルな PAM 設定ファイルを変更する場合は、個別のアプリケーションに対して PAM の設定を手作業で調整する必要はありません。

pam-config の使用例としては、下記のようなものがあります:

  1. 新しい Unix 形式の PAM 設定の自動生成: pam-config に対して、あとから追加や変更ができるよう、最もシンプルな設定を作成するように指示します。具体的には pam-config --create というコマンドを実行することで、シンプルな Unix 認証設定を作成することができます。 pam-config で管理されていない設定が既に存在していた場合、設定は上書きされてしまいますが、バックアップコピーが *.pam-config-backup という形式で保存されます。

  2. 新しい認証方式の追加: 新しい認証方式 (たとえば SSSD) をお使いの PAM モジュールスタックに追加するには、 pam-config --add --sss のようにコマンドを実行します。このコマンドを実行すると、全ての common-*-pc PAM 設定ファイルの該当箇所に対して SSSD が追加されます。

  3. テスト目的でのデバッグの有効化: 新しい認証の仕組みが期待通りに動作しているかどうかを確認するには、全ての PAM 関連操作に対して、デバッグ機能を有効化する必要があります。たとえば pam-config --add --sss-debug のように実行すると、 SSSD 関連の PAM 操作に対して、デバッグが有効化されます。 デバッグ出力は、 systemd のジャーナル (詳しくは 第11章 「journalctl : systemd ジャーナルへの問い合わせコマンド をお読みください) 経由で読むことができます。

  4. 設定の問い合わせ: 新しい PAM の設定を適用する際には、必要な全てのオプションを指定しているかどうかを確認しておいてください。 pam-config --query -- モジュール名 コマンドを実行すると、使用されている種類の一覧と、モジュールに対して指定されているオプションを表示することができます。

  5. デバッグオプションの削除: 設定に問題がないことを確認し終えたら、最後にデバッグオプションを削除します。たとえば pam-config --delete --sss-debug のように実行すると、たとえば pam_ssh.so に対して設定していたデバッグを無効化することができます。他のモジュールの場合も、同じようなコマンドで無効化することができます。

pam-config コマンドに対する詳しい使用方法と利用可能なオプションについて、詳しくは pam-config(8) のマニュアルページをお読みください。

2.6 PAM の手動設定 Edit source

PAM の設定ファイルを手作業で作成もしくは管理したい場合は、これらのファイルに対する pam-config を無効化する必要があります。

pam-config --create コマンドを利用して独自の PAM 設定ファイルを手作業で作成する場合、 common-* から common-*-pc ファイルに対するシンボリックリンクが作成されます。 pam-config では common-*-pc の設定ファイルのみを修正しますので、これらのシンボリックリンクを削除することで、 pam-config を効率的に無効化することができます。

警告
警告: 設定内に pam_systemd.so を含める必要性について

独自の PAM 設定を作成する場合は、 pam_systemd.so モジュールをsession optional で指定するようにしてください。 pam_systemd.so を含めるように指定しないと、 systemd のタスク制限で問題が発生するようになります。詳しくは pam_systemd.so のマニュアルページをお読みください。

2.7 ローカルログインのための U2F キーの使用 Edit source

ローカルログイン時にさらにセキュリティを高める方法として、 pam-u2f フレームワークと YubiKey 等の U2F 機能を持つセキュリティキーを利用した 2 要素認証を設定することができます。

お使いの システムに対して U2F を設定するには、まず システムで鍵とアカウントの紐付けを行う必要があります。紐付け後は鍵を使用するように設定するだけです。手順はそれぞれ後続の章で説明しています。

2.7.1 アカウントと U2F キーの紐付け Edit source

U2F キーとアカウントの紐付けを行うには、下記の手順を行います:

  1. まずは通常通りシステムにログインします。

  2. U2F キーを接続します。

  3. U2F キーの設定のためのディレクトリを作成します:

    > sudo mkdir -p ~/.config/Yubico
  4. pamu2fcfg コマンドを実行して、出力結果を設定として出力します:

    > sudo pamu2fcfg > ~/.config/Yubico/u2f_keys
  5. 接続したデバイスに搭載された LED が点灯したら、接続確認のためにデバイスの金属接点に触ってください。

なお、予備の U2F デバイスを用意して設定しておくことをお勧めします。下記のようなコマンドを実行します:

  1. 下記を実行します:

    > sudo pamu2fcfg -n >> ~/.config/Yubico/u2f_keys
  2. 接続したデバイスに搭載された LED が点灯したら、接続確認のためにデバイスの金属接点に触ってください。

出力されたファイルは、既定の場所から sudo での許可が必要なディレクトリに移動させておくことで、さらにセキュリティを高めることができます。たとえば /etc ディレクトリ以下に移動したい場合は、下記のような手順を実施します:

  1. まずは /etc 以下にディレクトリを作成します:

    > sudo mkdir /etc/Yubico
  2. あとは作成したファイルを移動するだけです:

    > sudo mv ~/.config/Yubico/u2f_keys /etc/Yubico/u2f_keys
注記
注記: u2f_keys ファイルの非標準の場所への移動について

出力されたファイルを既定のディレクトリ ( $HOME/.config/Yubico/u2f_keys ) 以外に移動させる場合、 2.7.2項 「PAM 設定の更新」 に示された手順に従って、 /etc/pam.d/login ファイル内にそのディレクトリを設定しておく必要があります。

2.7.2 PAM 設定の更新 Edit source

U2F キーの設定が終わったら、あとはシステムの PAM 設定を調整するだけです。

  1. まずは /etc/pam.d/login ファイルを開きます。

  2. 下記のようにして auth required pam_u2f.so という行を追加します:

    #%PAM-1.0
    auth      include    common-auth
    auth      required   pam_u2f.so
    account   include    common-account
    password  include    common-password
    session   optional   pam_keyinit.so revoke
    session   include    common-session
    #session  optional   pam_xauth.so
  3. なお、 $HOME/.config/Yubico/u2f_keys 以外のディレクトリに u2f_keys ファイルを配置している場合は、 /etc/pam.d/login ファイル内で、 authfile オプションを指定する必要があります:

    #%PAM-1.0
    auth     requisite pam_nologin.so
    auth     include   common-auth
    auth  required pam_u2f.so authfile=<U2F_キーのディレクトリ>
    ...

    ここで、 <U2F_キーのディレクトリ> には、 u2f_keys ファイルのあるディレクトリを絶対パスで指定します。

2.8 さらなる情報 Edit source

pam-doc パッケージをインストールすると、 /usr/share/doc/packages/pam ディレクトリ内に下記のような追加のドキュメンテーションが提供されるようになります:

README

このディレクトリの直下には modules サブディレクトリがあり、ここには利用可能な PAM モジュールに関する説明 (英語) の書かれた README ファイルがあります。

The Linux-PAM System Administrators' Guide (Linux-PAM システム管理者ガイド)

この文書には、システム管理者が PAM について知っておくべき内容を説明しています。設定ファイルの文法から、 PAM のセキュリティ要素までの範囲を説明しています。

The Linux-PAM Module Writers' Manual (Linux-PAM モジュール開発者マニュアル)

この文書には、開発者の観点からの内容を説明しています。具体的には、標準に準拠した PAM モジュールの作成方法などを説明しています。

The Linux-PAM Application Developers' Guide (Linux-PAM アプリケーション開発者マニュアル)

この文書には、 PAM ライブラリを使用したいアプリケーション開発者に対して、必要な情報が含まれています。

PAM マニュアルページ

PAM の一般的な説明と、全てのコンポーネントの機能をよりよく説明するためのモジュール向けマニュアルページが用意されています。

このページを印刷