Ubuntu12.04VPSでPAMを使用して認証を構成する方法
ステータス:非推奨
この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。
理由:
Ubuntu 12.04は2017年4月28日に保守終了(EOL)に達しました and no longer receives security patches or updates. This guide is no longer maintained.
代わりに参照してください:このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。
序章
PAM 、またはPluggable Authentication Modulesは、さまざまなサービス間の認証を可能にするために使用されるLinuxおよびUnixライクなオペレーティングシステムに存在する抽象化レイヤーです。
このシステムは、認証サービスとユーザー認証を必要とするアプリケーションの仲介として構築されており、コードを書き直すことなく、これら2つのレイヤーを適切に統合して認証モデルを変更できます。 これは、モジュールを使用することで実現されます。
このガイドでは、Ubuntu 12.04 VPSのPAMシステムについて説明しますが、最近のほとんどのLinuxディストリビューションも同様に機能するはずです。
舞台裏:PAMの要点
プラグ可能な認証のしくみ
Linux環境で日常的に操作する多くの通常のアプリケーションは、実際には内部でPAMを使用しています。
アプリケーションは、PAMライブラリをサポートして作成する必要があります。 何らかの方法でPAMを使用できるシステム上のアプリケーションのリストを取得するには、次のように入力します。
ldd /{,usr/}{bin,sbin}/* | grep -B 5 libpam | grep '^/'
/bin/login:
/bin/su:
/sbin/mkhomedir_helper:
/sbin/pam_tally2:
/usr/bin/chfn:
/usr/bin/chsh:
/usr/bin/passwd:
/usr/sbin/atd:
/usr/sbin/chpasswd:
/usr/sbin/cron:
/usr/sbin/newusers:
/usr/sbin/sshd:
次のように入力して、特定のアプリケーションのPAM機能を確認できます。
ldd $(どのprog_name )| grep libpam
何かを返す場合は、PAMを使用できます。
ご覧のとおり、多くの一般的なユーティリティとツールは、実際にはPAMを仲介者として使用してタスクを実行します。
PAM組織
LinuxのバージョンのPAMは、プロセスのどの部分に関与しているかに応じて、モジュールの機能をさまざまなカテゴリに分類します。 カテゴリの簡単な説明は次のとおりです。
-
認証機能:認証モジュールはユーザーの認証資格情報を検証します。 これは、ユーザーが有効な資格情報を提供できるかどうかをチェックすることを意味します。
-
アカウント機能:これらのモジュールは、サインインしようとしているアカウントが、現時点で要求しているリソースにアクセスできるかどうかを判断する役割を果たします。 PAMを使用すると、事前に定義された基準に基づいてユーザーを拒否または許可できるコントロールを指定できます。
-
セッション機能:これらのモジュールは、ユーザーがログインまたはログオフした後に構築および破棄される環境を確立します。 セッションファイルは、環境を準備するために実行する必要のあるコマンドを決定できます。
-
パスワード機能:これらのモジュールは、さまざまなサービスの認証の詳細を更新する役割を果たします。 サービスのパスワードを変更する必要がある場合、このモジュールはサービスとの通信と正しい値の変更を支援します。
これらのモジュールカテゴリの最初の2つは、プログラムが認証にPAMを正常に使用するたびに参照されます。 セッションモジュールは、必要に応じて最初の2つの後に実行されます。 パスワードモジュールはオンデマンドでアクセスされます。
ディレクトリ構造に関して、PAM構成ファイルは/etc/pam.d
に保存されます。
ls /etc/pam.d
atd chsh common-password cron other su
chfn common-account common-session login passwd sudo
chpasswd common-auth common-session-noninteractive newusers sshd
このディレクトリには通常、PAM認証を要求する各アプリケーションの構成ファイルがあります。 アプリケーションがPAMを呼び出したが、関連する構成ファイルがない場合、「その他」の構成ファイルが適用されます。
構成ファイル内には、通常、「common-」で始まる構成ファイルを含めるための呼び出しがあります。 これらは、ほとんどの状況でルールを適用する必要がある一般的な構成ファイルです。
構成ファイルで参照されているモジュールは、次のコマンドで見つけることができます。
ls /lib/*/security
pam_access.so pam_keyinit.so pam_permit.so pam_tally.so
pam_debug.so pam_lastlog.so pam_pwhistory.so pam_time.so
pam_deny.so pam_limits.so pam_rhosts.so pam_timestamp.so
pam_echo.so pam_listfile.so pam_rootok.so pam_umask.so
. . .
このディレクトリを調べて、使用できるモジュールの種類を確認してください。 ほとんどすべてのモジュールには、使用法を説明できるマニュアルページがあります。
PAMが認証を評価する方法
アプリケーションがPAMシステムに認証を問い合わせると、PAMは関連するPAM構成ファイルを読み取ります。
構成ファイルには、PAMモジュールのリストとそれらの処理方法が含まれています。 各モジュールは順番に呼び出され、モジュールへの各呼び出しは成功または失敗の結果を生成します。
次に、これらの値に基づいて、構成ファイルは、呼び出し元に「認証OK」メッセージを返すか、認証失敗メッセージを送信するかを決定します。
呼び出されたモジュールから最初の障害が戻ったときに構成が失敗するか、代替ポリシーを構成できます。 たとえば、システムはLDAPユーザーに認証を許可する場合があります。 それが失敗した場合は、ローカルユーザーのリストと照合する場合があります。
行の評価によって構成ファイルの残りの部分がスキップされない限り、各構成ファイルの行は上から下に評価されます。
ポリシーラインの読み方
構成ファイルの各行には、次の構文が含まれています。各フィールドは空白で区切られています。
[service] type control module-path [module-arguments]
/etc/pam.d
内にあるファイルは、サービスフィールドを除外し、代わりに、サービスを提供するアプリケーションにちなんで構成ファイルに名前を付けます。 pam.dディレクトリがない場合は、代わりに/etc/pam.conf
ファイルが必要であり、関連するアプリケーションを各行の先頭にリストする必要があります。
Type は、提供されるサービスの種類です。 これは、上記の4つのカテゴリ(認証、アカウント、パスワード、セッション)の1つです。
Control は、モジュール呼び出しの戻りステータスを受信したときに実行されるアクションを指定します。 これらの値のいずれかを指定できます(さらに、ここでは説明しない、より複雑な構文を使用することもできます)。
-
required :これにより、モジュール呼び出しが失敗した場合に認証が失敗します。 ただし、指定された残りのモジュールは引き続き呼び出されます。
-
require :これは必要な動作とまったく同じように動作しますが、残りのモジュールを呼び出す代わりに、すぐに認証に失敗します。
-
sufficient :この制御は、この行が成功した場合(必要なモジュール障害がまだ発生していない場合)、残りのモジュールを実行せずに認証がすぐに成功として戻ることを意味します。 この行に障害が発生すると、次のモジュール呼び出しにスキップされます。
-
オプション:これらの回線の成功または失敗は、それらがそのタイプの唯一のモジュール呼び出しでない限り、認証全体の成功または失敗とは関係ありません。
-
include :この行は、特定のタイプの行を別の構成スクリプトから読み取る必要があることを示します。 これは、「共通」ファイルを参照するためによく使用されます。
-
substack :これはインクルードに似ていますが、失敗または成功してもファイル全体が終了するのではなく、サブスタックだけが終了します。
Module-path は、呼び出すpamモジュールの名前です。
Module-arguments は、モジュールに渡されるオプションのパラメーターです。 モジュールが成功した場合に実行するアクションを知るために、これらが必要になる場合があります。
個々のファイルは、次の構文を使用してチェックする必要がある他のファイルを参照する場合もあります。
@含む config_file
これにより、構成ファイル全体が読み込まれます。これは、同じタイプの行のみを読み込む「include」コントロールタイプとは異なります。
構成例の調査
/etc/pam.d
ディレクトリにあるいくつかの例を確認することで、クライアントがどのように構成されているかを理解できます。
スケジューリングデーモンである「atd」の認証要件を記述したファイルを開きます。
less /etc/pam.d/atd
auth required pam_env.so
@include common-auth
@include common-account
@include common-session-noninteractive
session required pam_limits.so
最初の行は「pam_env」モジュールを呼び出します。 マニュアルページを見ると、このモジュールがいくつかの環境変数を設定するために使用されていることがわかります。これらはデフォルトで/etc/security/pam_env.conf
に格納されています。 これは「必須」です。つまり、このモジュールが「失敗」を返した場合、構成全体が失敗しますが、それは発生しないはずです。
次の3行は、「common-auth」、「common-account」、および「common-session-noninteractive」ファイルを読み込んで、それぞれの役割を処理します。
最後の行は「pam_limits」モジュールを呼び出し、/etc/security/limits.conf
ファイルまたは/etc/security/limits.d/
ディレクトリをチェックします。 これは、とりわけ、サービスを同時に使用できるユーザーの数に制限を適用するために使用できます。
参照されているファイルを確認することで、実行されているすべてのチェックをより完全に理解できます。
common-authファイルを確認する
情報を要約するために、ファイルからコメントを削除しました。
less /etc/pam.d/common-auth
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_ecryptfs.so unwrap
最初の行はまだ説明していません。 「/etc/nsswitch.conf」ファイルを介して構成された標準のUNIX認証を提供する「pam_unix」モジュールを呼び出していることがわかります。 通常、これは、予想どおり、/etc/passwd
および/etc/shadow
ファイルをチェックすることを意味します。
UNIXモジュールに渡される「nullok_secure」引数は、ログイン情報が/etc/securetty
ファイルでチェックアウトする限り、パスワードのないアカウントで問題がないことを指定します。
「[success=1default =ignore]」を持つコントロールフィールドは、この例の奇妙な部分です。 これは、単純化された「必須」、「十分」などのパラメーターを置き換え、よりきめ細かい制御を可能にします。
この場合、モジュールが成功を返すと、次の「1」行をスキップします。 モジュールの他のすべての戻り値を処理するデフォルトのケースでは、行が無視されて先に進みます。
2行目の制御値は「必須」です。これは、失敗した場合、構成全体がすぐに失敗を返すことを意味します。 また、「pam_deny」モジュールを呼び出します。このモジュールは、呼び出しごとに失敗を返します。
これは、これが常に失敗することを意味します。 唯一の例外は、この行がスキップされた場合です。これは、最初の行が正常に戻ったときに発生します。
3行目が必要で、「pam_permit」モジュールを呼び出します。このモジュールは毎回成功を返します。 これにより、この時点で現在の「合格/不合格」レコードがリセットされ、以前の奇妙な値がないことが保証されます。
4行目はオプションとしてリストされており、「unwrap」オプションを使用して「pam_ecryptfs」モジュールを呼び出します。 これは、提供されたパスワードを使用してパスフレーズをアンラップするために使用されます。このパスワードは、プライベートディレクトリのマウントに使用されます。 これは、このテクノロジーを使用する場合にのみ関係するため、オプションです。
共通アカウントファイルの確認
「atd」構成で参照される次のファイルを見ていきます。 繰り返しになりますが、簡潔にするためにコメントを削除します。
less /etc/pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account requisite pam_permit.so
このファイルのほとんどすべては、「common-auth」ファイルのファイルと似ています。 最初の行では、「pam_unix」モジュールを使用したアカウントチェックが必要です。
モジュールは、呼び出しの「タイプ」に応じてさまざまな機能を実行できます。 アカウント呼び出しの場合、pam_unixは、アカウントの有効期限が切れておらず、時間ベースのログイン制限によって制御されていないことを確認します。
合格すると、その下の「pam_deny」呼び出しをスキップし、最後に許可ルールを処理します。 一方、失敗した場合は、拒否ラインに移動し、失敗して終了します。
common-session-noninteractiveファイルを確認する
次のセクションでは、非対話型プログラムまたは環境のセッションチェックについて説明します。
less /etc/pam.d/common-session-noninteractive
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_unix.so
session optional pam_ecryptfs.so unwrap
最初の3行は奇妙に見えるかもしれません。 この時点でプログラムの流れを理解できるはずですが、おそらく恣意的で冗長に見えるでしょう。 最初の行は常に成功し、次の行はスキップされ、3番目の行は常に成功します。
多くのPAM構成が自動生成され、追加のPAM対応認証方式が使用可能な場合に、より実質的なルールを提供するように変更されるため、これらはこの方法です。 これは、後でプログラムフローに影響を与えるために新しいルールを挿入できるフレームワークを作成するだけです。
4行目は、「pam_umask」モジュールの呼び出しであり、オプションとしてマークされています。 これにより、セッションのファイル作成マスクが設定されます。 いくつかの異なるファイルの場所をチェックして、関連するumaskの場所を見つけようとします。
5行目は、pam_unixモジュールを再度呼び出すために必要な呼び出しです。 これは「セッション」タイプの呼び出しであるため、UNIXモジュールの動作は異なります。 この場合、システムのユーティリティを使用してロギングを実装します。
最後の行は、再び「pam_ecryptfs」呼び出しです。 「auth」ファイルへの配置と同様の機能を実行します。
結論
PAMは、最初に習得するのが非常に複雑になる可能性があります。 ただし、システムがどのように機能し、さまざまなコンポーネントをどのようにリンクするかについての基本的な理解は、適切な認証手順を開発するために不可欠です。
PAMルールの構成に関するすべてを理解しているとは限りませんが、コンピューターの不正使用を防ぐためにどのシステムが導入されているかを知っておくとよいでしょう。
LDAPなどの新しい認証スキームを実装する場合は、PAMを理解することが特に重要です。 新しいシステムを完全に、または条件付きで使用するには、認証スキームを切り替える必要があります。