打开PAM调试到Syslog

我讨厌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（debug对PAM项选项在/etc/pam.d/）。

不，不起作用。 没有PAM输出，什么也没有，绝对无声。

在寻找解决方案时，我什至关注了指向Pam（德国加油站）的链接。好吧，是的，也许在所有这些数十亿次点击中可能都隐藏了一个线索，但是开枪射击我会在我被发现之前就死了。

其余就是仅供参考：

我有什么问题？

升级到Debian Squeeze后，有些事情变得很奇怪（嗯，曾经是，呃，刻蚀是正确的..啊，是的，伍迪）。所以这可能不是Debian的错，只是一个长期存在的问题。我立即感觉到它必须与PAM一起使用，但是我真的不知道发生了什么。YKWIM，我完全处于黑暗中，独自一人，无助，婴儿。有些ssh登录有效，有些则无效。真是有趣。没有任何线索ssh -v，没有任何线索/var/log/*。只是“身份验证成功”或“身份验证失败”，有时同一用户同时并行登录一个会话成功，而另一个会话同时失败。而且您什么都无法掌握。

在挖掘其他选项的火车后，我得以找到答案。有nullokand nullok_secure，是Debian的特殊功能。某些东西搞砸了/etc/securetty，具体取决于tty（有些随机）登录是否被拒绝。真不错，！

修复很容易，现在一切都很好。

但这给我留下了一个问题，即将来如何调试这种混乱情况。这不是PAM第一次让我发疯。因此，我希望看到最终的解决方案。最终如“已解决”中所述，而不是最终如“世界末日”中所示。谢谢。

啊，顺便说一句，这再次加强了我的信念，即自从出现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/*文件或其他文件中相关行的末尾添加“ debug”来仅对感兴趣的模块启用调试：

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版本）并按如下所示更改spec文件：

• 查找以以下内容开头的行

  ％配置 \

然后添加--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构建环境的步骤。

这是主要步骤。打开规格文件并添加--enable-debug到调用中的%build部分configure。重新编译！重新安装新创建的软件包。最后，创建将在其中写入调试日志的文件。

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

如果您不创建文件，那么很多日志将在终端上飞过，这可能不是很有用。

Debian和Ubuntu（可能还有其他发行版）有一个特殊的日志文件，所有pam输出都记录到该文件中：

/var/log/auth.log

我一直在与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外观的见解。

值得注意的是，根据您的描述：

• 如果您尝试以root用户身份登录并失败，则可能是因为该行出现在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”仅用于在数据库中写入日志。

所以也许这对您有一点帮助。

我们都讨厌PAM。祝好运！