PAMデバッグをSyslogに切り替えます

PAMが登場して以来、私はPAMが嫌いです。

Debian Squeezeで管理者レベルでPAMデバッグを有効にするにはどうすればよいですか？

見つけたすべてのリソースを確認しました。Google、マンページ、何でも。まだ試していない唯一のこと（私はあえてPAMが嫌いだと言ったのですか？）は、PAMのライブラリソースを掘り下げることです。

私は解決策を求めてグーグルを試みましたが、何もしませんでした。私がこれまでに見つけたもの：

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion（/etc/pam_debug）と http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html（debugPAMエントリのオプションで/etc/pam.d/）。

いいえ、動作しません。 PAM出力なし、無音、完全な無音。

解決策を探している間、私はドイツのガソリンスタンドであるパムへのリンクをたどりました。まあ、はい、おそらくこれらの数十億のヒットすべてで手がかりを隠すかもしれませんが、私を発見する前に私を撃ちます

残りは参考です：

どのような問題がありましたか？

Debian Squeezeにアップグレードした後、何かがおかしくなりました（まあ、かつて、それはEtchのすぐ上にあったものでした..ああ、そう、ウッディ）。おそらく、Debianのせいではなく、長続きするねじ込みセットアップです。すぐにPAMで何かをする必要があるという印象を受けましたが、何が起こっているのか本当に分かりませんでした。私は完全に暗闇の中で、放置されたまま、赤ちゃんのように無力でした、YKWIM。いくつかのsshログインが機能し、一部は機能しませんでした。ちょっと面白かった。何の手がかりもssh -v、何の手がかりも/var/log/*ありません。単に「認証成功」または「認証失敗」、同じユーザーが並行してログインすることで、一方のセッションで成功し、他方のセッションで同時に失敗することもありました。そして、あなたが本当に手に入れることができるものは何もありません。

他の選択肢の列車を掘った後、私は見つけることができました。あるnullokとnullok_secureDebianの特別は、。何かをねじ込み/etc/securettyとに応じて、ttyログインは拒否されたりされなかった（ややランダムです）。本当にすてきです、ふー！

修正は簡単で、すべてが再び正常になりました。

しかし、これにより、このような混乱を将来どのようにデバッグするかという疑問が残りました。PAMが私を夢中にさせるのは初めてではありません。だから私は最終的な解決策を見たいです。「armageddon」のような最終ではなく、「solved」のような最終。ありがとう。

ああ、ところで、これはPAMが登場して以来嫌いだというのが私の信念を再び強めました。私が言ったことはありますか？

あなたが試すべきいくつかのこと：

syslogでデバッグメッセージのログを有効にしましたか？

cp /etc/syslog.conf /etc/syslog.conf.original
vi /etc/syslog.conf

次の行を追加します。

*.debug     /var/log/debug.log

で終了し:wq!ます。

touch /var/log/debug.log
service syslog restart

次のように、すべてのモジュールのデバッグを有効にできます。

touch /etc/pam_debug

または、関連する行の最後/etc/pam.d/system-authまたは他の/etc/pam.d/*ファイルに「デバッグ」を追加することで、関心のあるモジュールのデバッグのみを有効にできます。

login   auth    required    pam_unix.so debug

その後、デバッグメッセージがに表示されるようになり/var/log/debug.logます。これがお役に立てば幸いです！

少なくともCentOS 6.4では、/etc/pam_debug使用されません。

pam_warn.soモジュールがインストールされている場合、次の方法でログ出力を取得できます。

auth required pam_warn.so

success required pam_warn.so

このモジュールは、どの時点でも認証プロセスに干渉しないことを保証しますが、syslogを介して意味のあるものを記録します。

更新

コードを調べていくつかのコンパイルを行った後、（1）ソースを介してこのデバッグモードを有効にすることが可能であり、（2）RHELパッチにより機能がほとんど使用できなくなります（少なくともpam_unixモジュール）および（3）とにかくコードをパッチする方が良いでしょう。

これをRHELで機能させるには、Linux-PAM ... src.rpm（1.1バージョンの場合）を取得し、次のように仕様ファイルを変更します。

• で始まる行を見つける

  ％configure \

その後、--enable-debug \を追加します

• 行を削除するか、％patch2で始まる行（前の行より上）をコメントアウトします。

次に、rpmをビルドしてインストールします（強制的に、既存のパッケージを上書きします）。ファイル/var/run/pam-debug.logを作成します。

install -m 622 /dev/null /var/run/pam-debug.log

ファイルが存在しない場合、デバッグ出力はstderrに送信されます。

• 私の意見では、このstderrへの送信は愚かであり、パッチ競合の原因となっています。ファイルlibpam / include / security / _pam_macros.hに移動して、次の4行を置き換えることにより、この動作を変更できます。

  ログファイル= stderr;

と

return;

ビルド時に、到達不能なステートメントに関する警告が表示されますが、無視できます。sedスクリプトでこの変更を行うことができます（そしてパッチの後にRPMの％prepセクションに入れます）...

sed -i 's/logfile = stderr;$/return;/' libpam/include/security/_pam_macros.h

この小さなパッチを実行すると、％patch2が再び正常に機能するようになり、復元できます。

CentOS 6.4でPAMのデバッグログを有効にする方法を見つけようとして、たまたま数時間を費やしました。この質問はDebian向けですが、CentOSでそれを行う方法を書き留めておきます。他の人がすでに持っている時間を費やす必要がないように。

最終的に判明したように、pamCentOSパッケージでデバッグログを有効にするのは簡単です。難しさは、パッケージの再コンパイルを伴うという事実に起因します。そこで、まずここpam-1.1.1-13.el6.src.rpmからSRPM（例）を見つけます。SRPMからパッケージをコンパイルすることを知らない人は、RPMビルド環境をセットアップする手順を参照できます。

主なステップは次のとおりです。specファイルを開き、呼び出しのセクションに追加--enable-debugします。再コンパイル！新しく作成したパッケージを再インストールします。最後に、デバッグログが書き込まれるファイルを作成します。%buildconfigure

$ sudo touch /var/run/pam-debug.log

ファイルを作成しないと、ターミナルで大量のログが飛んでしまい、あまり役に立たない可能性があります。

DebianおよびUbuntu（および他のディストリビューション）には、すべてのpam出力が記録される特別なログファイルがあります。

/var/log/auth.log

私は1日半の間、PAM関連の問題に苦労してきましたが、ついにこのログファイルについて知り、狂気から自分を救いました。

計画どおりに動作しない場合のこのファイルの内容のサンプルを次に示します。

Jul 10 09:31:14 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user_lookup: could not open database `/etc/vsftpd_users.db': No such file or directory
Jul 10 09:36:20 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log

動作時の外観は次のとおりです。

Jul 10 09:47:00 vagrant-ubuntu-trusty-64 sshd[5222]: pam_unix(sshd:session): session closed for user vagrant
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: Accepted publickey for vagrant from 10.0.2.2 port 54652 ssh2: RSA dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: pam_unix(sshd:session): session opened for user vagrant by (uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session closed for user root
Jul 10 09:51:41 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user 'foo' granted access
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)

PAMデバッグロギングを有効にする他の可能性はどれも機能しなかったことに注意してください。

/ etc / securettyにねじ込まれ、tty（多少ランダム）に応じてログインが拒否されたかどうかが決まりました。本当にすてきです、ふー！

少し拡張していただけますか？

securettyのマンページごと：

the file contains the device names of terminal lines (one per line, without leading /dev/) on which root is allowed to login.

説明した動作は、securettyが正常に動作しているように聞こえます（実際にrootとしてログオンしている場合）。

いくつかのsshログインが機能し、一部は機能しませんでした。

ここでも、PAM以外の制限が設けられている可能性があります。そのため、あなたの/etc/ssh/sshd_config外見を理解するのに役立ちます。

特に、あなたの説明から：

• ルートとしてログインしようとして失敗した場合、次の行が存在する可能性がありますsshd_config。PermitRootLogin no
• 一部のユーザー/グループが動作し、他の人でない場合は、理由の一つは、での使用可能性sshd_configのAllowGroupsかAllowUsers。サンプル行は次のようになります。 AllowGroups users admins

もちろん、PAMが問題の一部である可能性は完全にありますが、他の方法で説明できるように、あなたの主な「症状」の音は私には聞こえます。

Asket ...私はあなたの投稿を本当に愛していました:)過去15時間、このようなものと戦っていました...（しかし、30分の休憩があったかもしれません）

どういうわけか、私はあなたがしたすべてのことを行うことでそれを機能させました。つまり、/ etc / pam_debugを持ち、PAMエントリでデバッグします。しかし、私の場合、私が苦しんでいたとしてpam_mysql、私は別のものを入れていたverbose=1後debug、私のPAMエントリに：

mailsystem:~# cat /etc/pam.d/smtp

auth required pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=time

account sufficient pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=times

その「sqllog」は、DBにログを書き込むためのものです。

だから、これはあなたをほんの少し助けるかもしれない。

私たちは皆PAMが嫌いです。がんばろう！