LoginSignup
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@gin_135

PAM認証について

Last updated at Posted at 2025-09-03

初めに

本記事では、PAMの概要と設定方法およびLinuxにおけるPAMの設定例を解説します。

PAMとは

PAM(Pluggable Authentication Modules)とは、Unixシステムにおいて、ユーザ認証方式を一元管理する仕組みです。

※以下、Linux-PAMプロジェクトWebサイトの説明文からの引用です。

PAM provides a way to develop programs that are independent of authentication scheme.
These programs need "authentication modules" to be attatched to them at run-time in order to work.
Which authentication module is to be attatched is dependent upon the local system setup and is at the discretion of the local system administrator.

PAMは、認証スキームに依存しないプログラムを開発する方法を提供します。
これらのプログラムは、実行時に「認証モジュール」をアタッチして動作させる必要があります。
どの認証モジュールをアタッチするかは、ローカルシステムの設定に依存し、ローカルシステム管理者の裁量に委ねられます。

https://web.archive.org/web/20220402070708/http://linux-pam.org/whatispam.html

PAMの目的は、認証サービスを必要とする各種プログラムや機能に関係なく、管理者が柔軟に設定できるユーザ認証メカニズムを確立することです。
また、PAMのメリットとして、特定のユーザ認証方式に依存せずプログラムを開発可能になり、プログラム毎に認証システムを実装する必要が無くなる事が挙げられます。

PAMの構成要素

PAMは以下の4つの要素から構成されます。

  • サービス:
    PAMを認識できる認証プログラム(loginやpasswdなど)
  • モジュール:
    様々な特殊認証作業を実行するもの
    • 共有ライブラリ(.soファイル)として実装され、Linuxでは/lib/securityに格納される
    • 各モジュールは認証プロセスのごく一部のみを担当する
    • 認証実行後、モジュールは該当ユーザへのアクセスを認めるか拒否するかの返り値をPAM機能に返す
  • 設定データ:
    サポートされている書くサービスに対して、どの認証プロセスを実行すべきかを示すファイル
    • 1つまたは複数のPAM設定ファイルで構成される
    • Linuxでは、サービスごとに独自の設定ファイルが/etc/pam.dに格納されている
      • 設定ファイル名はサービス名と同じ(passwdなら/etc/pam.d/passwd)
  • 付加設定:
    モジュールへのオプションとして付加する設定
    • 代表的な設定は、limits.confを用いたユーザが使用できるリソースの制限など
    • 設定ファイルは/etc/securityに格納される
    • 設定ファイル名は対応するサービス名に.confを付けたもの

PAM設定の構造

Linux-PAMの設定ファイルは、1行につき以下の4つの要素で構成されます。

TYPE    CONTROL     MODULE_PATH     MODULE_ARGS

各要素の概要や記載する内容などについて、それぞれ解説します。

TYPE

モジュールのタイプを宣言します。
各モジュールはスタックとして処理されます。
PAMは次の4タイプのモジュールを認識します。

  • auth:
    パスワード等を用いてユーザの真正性を確認する
  • account:
    ユーザがリクエストしたサービスを使用するための、認証に基づかないアカウント管理(アカウントが失効していないかどうか等)を確認する
  • password:
    現行サービスの実行中、パスワード等の認証トークンを変更する際に用いる
  • session:
    ユーザセッションの管理(認証の前後に起動してログイン試行をログに記録する)と設定(ユーザ固有の環境設定を行う)に用いられる

なお、設定ファイル内に同じTYPEが複数記載されている場合、処理はTYPE毎にまとめて実行されます。
処理は、auth→account→password→sessionの順に、上から順に、まとめて実行されます。

以下、処理の具体例を挙げます。

auth
auth
account
auth
password
account
session

上記のような設定ファイルの場合、まず評価順序が最も高いauthTYPEの1行目と2行目が実行されます。
次に、3行目のaccountではなく、同じauthTYPEである4行目が実行されます。
その後、評価順序が最も高いauthTYPEを全て実行したため、評価順序が次に高いaccountTYPEの3行目が実行されます。
同様に、5行目のpasswordではなく、同じaccountTYPEである6行目が実行されます。
そして、評価順序がaccountの次であるpasswordTYPEの5行目が実行されます。
最後に、評価順序が最も低いsessionTYPEの7行目が実行されます。

このように、処理は設定ファイルの記述順序とは別に、TYPE毎にまとめて実行されます。
ただし、上記の例のように異なるTYPEを混在させた記法は可能ですが、可読性・保守性の点から好ましくありません。
実際の設定ファイルでは、下記のようにTYPE毎に処理をまとめて記載する方が良いでしょう。

auth
auth
auth
account
account
password
session

CONTROL

モジュールの動作を指定します。
各モジュールには、主に以下の制御フラグを設定可能です。

  • required:
    このフラグが付いているモジュールは、認証を進める前に正常に処理される必要がある
    • このフラグが付いたモジュールが失敗すると、同じフラグが付いた他のモジュールが全て処理されてから、認証の失敗に関するメッセージがユーザに返される
  • requisite:
    このフラグが付いているモジュールは、認証を進める前に正常に処理される必要がある
    • requiredとの違いは、このフラグが付いたモジュールが失敗した場合、他のモジュールは処理されず、ユーザに即時にフィードバック(エラーメッセージ)が送られる点
  • sufficient:
    このフラグが付いたモジュールが正常に処理されると、呼び出し元アプリケーションは即時に成功メッセージを受け取り、前にrequiredフラグが付いたモジュールが失敗していなければ、他のモジュールは処理されない
    • sufficientフラグが付いたモジュールが失敗しても、直接的な結果は発生せず、以降のモジュールはそれぞれの順序で処理される
  • optional:
    このフラグが付いたモジュールが成功もしくは失敗しても、直接的な影響は無い
    • ユーザへのメール着信通知など、それ以上はアクションを実行しないメッセージ表示専用モジュールなどに用いる
  • include:
    このフラグが設定された場合、引数として指定されたファイルがこの場所に挿入される
  • substack:
    このフラグが設定された場合、引数として指定されたファイルがこの場所に挿入される
    • includeとの違いは、引数に指定されたファイルを読み込み、その内容を実行したものを、この行の処理結果とする点

その他、[success=1 default=ignore]のように、制御フラグを細かく指定する方法もあります。
詳細はman pam.confなどを参照ください。

MODULE_PATH

モジュールのフルパスを記載します。
ただし、モジュールがデフォルトのディレクトリ(/lib/security)にある場合は、パスを省略してモジュール名だけ記載する表記も許可されています。

MODULE_ARGS

モジュールの動作に影響を与えるオプション(debug, nullokなど)をスペース区切りで記載します。

モジュールの例

PAMで使用されるモジュールを幾つか紹介します。

  • pam_unix.so:
    伝統的なUnixパスワード認証を提供するモジュール
  • pam_nologin.so:
    非rootユーザのログインを禁止する為のモジュール
  • pam_securetty.so:
    rootのログインを特別なデバイスに制限する為のモジュール
  • pam_ldap.so:
    LDAPサーバを認証バックエンドとして提供するモジュール
  • pam_google_authenticator.so:
    Google Authenticatorを用いた二段階認証を提供するモジュール

PAM設定の例

以下、PAMの設定をシンプルな設定ファイル(抜粋)を用いて簡単に解説します。

#%PAM-1.0
auth    required    pam_securetty.so
auth    required    pam_unix.so nullok
auth    required    pam_nologin.so

まず、1行目の#%PAM-1.0は、コメント行になります。
PAMの設定ファイルでは、行頭に#が付いている行はコメント扱いになります。

次に2~4行目では、ログイン認証に関する3つのモジュールをスタックして処理しています。

2行目のauth required pam_securetty.soでは、ユーザがrootとしてログインを試みている場合、rootログインが許可されているデバイス(ttyなど)を照合します。
照合に失敗した場合、rootでのログインを拒否し、ユーザにはエラーメッセージを返します。

3行目のauth required pam_unix.so nullokでは、ユーザにパスワードを要求し、/etc/passwdもしくは/etc/shadowに保存された情報を用いて、パスワードチェックを実行します。
この時、MODULE_ARGSとしてnullokを指定しているため、ユーザがパスワードを設定していなくても(パスワードが空に設定されている場合でも)、認証が成功します。

最後に4行目のauth required pam_nologin.soでは、/etc/nologinファイルが存在するかどうかを確認します。
このファイルが存在しており、かつユーザがrootでない場合は、ログインを拒否します。

設定ディレクトリ

PAMで使用する設定ディレクトリを紹介します。

  • /etc/pam.conf: PAMの設定ファイル
  • /etc/pam.d: Linux-PAMの設定ファイル格納ディレクトリ。このディレクトリが存在する場合、/etc/pam.confは無視される
  • /usr/lib/pam.d: Linux-PAMのベンダー設定ファイル格納ディレクトリ。/etc/pam.d内の設定ファイルは、このディレクトリ内の同名設定ファイルを上書きする
  • /etc/security: PAMモジュールの設定ファイル格納ディレクトリ

Linuxにおけるユーザ認証

別の例として、PAM設定を変更した際のユーザ認証動作の変化を解説します。
具体的には、suコマンドの認証動作を変更してみます。

suコマンドのPAM設定は、/etc/pam.d/suを変更することで行います。
この設定ファイルには、一般的なLinuxディストリビューションでは、以下のような設定が記述されています。

/etc/pam.d/su
#%PAM-1.0
auth            sufficient      pam_rootok.so
auth            required        pam_unix.so
account         required        pam_unix.so
session         required        pam_unix.so
password        include         system-auth

この設定状態では、どの一般ユーザでもパスワードを入力すれば、suコマンドを実行可能です。

[user@localhost ~]$ su -
パスワード:
[root@localhost ~]#
[root@localhost ~]# su - user2
[user2@localhost ~]$
[user2@localhost ~]$ su -
パスワード:
[root@localhost ~]#

ここで、上記設定の1行目の後に、auth require pam_wheel.so use_uidという記述を追加します。
※PAMの設定ファイルは、内容を変更すると設定が即時反映されます

/etc/pam.d/su
#%PAM-1.0
auth            sufficient      pam_rootok.so
auth            required        pam_wheel.so use_uid
auth            required        pam_unix.so
account         required        pam_unix.so
session         required        pam_unix.so
password        include         system-auth

新たに追加した設定によって、ユーザがwheelグループに所属していなければsuコマンドが拒否されるようになります。

[user@localhost ~]$ id -n -G
user wheel
[user@localhost ~]$ su -
パスワード:
[root@localhost ~]#
[root@localhost ~]# su - user2
[user2@localhost ~]$
[user2@localhost ~]$ id -n -G
user2
[user2@localhost ~]$ su -
パスワード:
su: 拒否されたパーミッション

このようにPAMの設定を変更することで、ユーザ認証の動作を変更することが可能です。

セキュリティ要件にあった設定サンプル

最後に実用的な例として、実際にありうるセキュリティ要件を満たすような設定を幾つか紹介します。

一定回数ログイン失敗でアカウントを一時ロック

  • セキュリティ要件:
    • 5回連続でログインに失敗した場合、10分間アカウントをロックする
    • rootにも適用する

モジュールpam_tally2.soを利用して、/etc/pam.d/system-authに以下の設定を記載します。

auth required pam_tally2.so deny=5 unlock_time=600 even_deny_root root_unlock_time=600
  • deny=5:
    5回連続失敗でロック
  • unlock_time=600:
    600秒(10分)後にロック解除
  • even_deny_root:
    rootに対しても適用
  • root_unlock_time=600:
    rootアカウントは600秒(10分)後にロック解除

なお、RHEL8からはpam_tally2.soはpam_faillock.soに置き換えられています。
参考として、pam_faillock.soを用いた設定例も紹介します。

モジュールpam_faillock.soを利用する場合は、/etc/pam.d/system-authと/etc/pam.d/password-authの2つのファイル両方に、以下の設定を記載します。
※/etc/pam.d/system-authはローカル認証に、/etc/pam.d/password-authはリモート認証に主に利用されます。

auth     required       pam_faillock.so preauth silent deny=5 unlock_time=600
auth     sufficient     pam_unix.so
auth     [default=die]  pam_faillock.so authfail deny=5 unlock_time=600
auth     sufficient     pam_faillock.so authsucc
  • 1行目:
    • preauth silent:
      認証前の事前チェック、失敗回数が閾値未満ならエラーメッセージを出さずに処理を進める
    • deny=5:
      5回連続失敗でロック
    • unlock_time=600:
      600秒(10分)後にロック解除
  • 2行目:
    実際にUNIXパスワード認証を実施
  • 3行目:
    • (※補足)[default=die]:
      この行の処理が失敗した場合、authスタック全体を即終了する(=4行目は実行されない)
    • authfail:
      認証失敗時に失敗回数を加算
  • 4行目:
    • authsucc:
      認証成功時に失敗回数をリセット

特定ユーザのみSSHログイン可能

  • セキュリティ要件:
    • 一般ユーザによるSSHログインを禁止する
    • wheelグループに所属しているユーザのみSSHログインを可能にする

モジュールpam_listfile.soを利用して、/etc/pam.d/sshdに以下の設定を記載します。

auth required pam_listfile.so item=group sense=allow file=/etc/ssh/sshallowgroups onerr=fail
  • item=group:
    リストファイルの種別の指定(ユーザグループ)
  • sense=allow:
    リストファイル内の項目に対して実行するアクション(許可)
  • file=/etc/ssh/sshallowgroups:
    リストファイルのパス
  • onerr=fail:
    ファイルが開けない等のエラーが発生した際の動作

また、SSHログインを許可するグループを、/etc/ssh/sshallowgroupsに記述します。
※上記ファイルが存在していなければ、新規に作成します。

/etc/ssh/sshallowgroups
wheel

sudo実行時にGoogle Authenticator必須

  • セキュリティ要件:
    • sudoコマンド実行時にOTP認証を要求する
    • OTPはGoogle Authenticatorを利用する

モジュールpam_google_authenticator.soを利用して、/etc/pam.d/sudoに以下の設定を記載します。

auth required pam_google_authenticator.so

※実際に使用する際は、ユーザ毎にgoogle-authenticatorコマンドを実行し、OTP秘密鍵を生成する必要があります。

パスワードポリシーの設定

  • セキュリティ要件:
    • パスワードポリシーを設定する
      • 最低16文字以上
      • 大文字・小文字・数字・記号を全て含む
      • 過去3回分のパスワード再利用を禁止

モジュールpam_pwquality.soとpam_unix.soを利用して、/etc/pam.d/system-authに以下の設定を記載します。

password   requisite    pam_pwquality.so retry=3 minlen=16 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password   sufficient   pam_unix.so sha512 shadow remember=3
  • pam_pwquality.so
    • minlen=16:
      最低16文字
    • dcredit=-1:
      数字を最低1文字含む
    • ucredit=-1:
      大文字を最低1文字含む
    • ocredit=-1:
      記号を最低1文字含む
    • lcredit=-1:
      小文字を最低1文字含む
  • pam_unix.so
    • remember=3:
      過去3回分のパスワード再利用を禁止

参考資料

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?