☰

打开 Syslog 的 PAM 调试

tag-icon • tag-icon syslog pam debug
打开 Syslog 的 PAM 调试

如何在管理员级别打开 Debian Squeeze 中的 PAM 调试？

我检查了所有能找到的资源。Google、手册页等等。唯一我还没试过的（我根本不敢试，我说过我讨厌 PAM 吗？）是深入研究 PAM 的库源。

我尝试用 Google 寻找解决方案，但一无所获。目前我发现：

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 后，有些事情变得很奇怪（嗯，嘿，它曾经是，呃，在 Etch 上是正确的。啊，是的，Woody）。所以这可能不是 Debian 的错，只是一个长期存在的搞砸了的设置。我立刻觉得它与 PAM 有关，但我真的不知道发生了什么。我完全处于黑暗之中，孤身一人，像个婴儿一样无助，YKWIM。一些 ssh 登录有效，一些无效。这有点好笑。没有线索ssh -v，没有线索/var/log/*，什么都没有。只有“身份验证成功”或“身份验证失败”，有时同一个用户同时登录一个会话成功，另一个会话失败。你真的什么也得不到。

在研究了一大堆其他选项后，我终于找到了答案。有nullok和nullok_secure，这是 Debian 的特色。有些东西搞砸了/etc/securetty，并且根据tty（有点随机）登录是否被拒绝。真的很棒，唷！

修复很容易，现在一切恢复正常。

然而这让我产生了一个疑问，如何解决这样的混乱情况将来。这不是 PAM 第一次让我抓狂。所以我想看到最终解决方案。最终是“解决”，而不是“世界末日”。谢谢。

啊，顺便说一句，这再次坚定了我的信念：自从 PAM 出现以来，讨厌它是一件好事。我有没有说过我讨厌它？

答案1

您可以尝试以下几件事：

您是否启用了系统日志中的调试消息记录功能？

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或者，您可以通过在其他文件的相关行末尾添加“debug”来仅为您感兴趣的模块启用调试/etc/pam.d/*：

login   auth    required    pam_unix.so debug

然后调试消息应该开始出现在/var/log/debug.log。希望这对您有所帮助！

答案2

至少在 CentOS 6.4 上/etc/pam_debug未使用。

如果安装了 pam_warn.so 模块，您可以通过以下方式获取一些日志输出：

auth required pam_warn.so

success required pam_warn.so

等等。该模块确保它不会在任何时候干扰身份验证过程，但它会通过系统日志记录有意义的内容。

更新

在检查了代码并进行一些编译之后，我发现（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/安全/_pam_macros.h并替换以下 4 行

    日志文件=stderr；

和

return;

在构建时，您会收到有关无法访问的语句的警告，但可以忽略它们。您可以在 sed 脚本中进行此更改（并在补丁之后将其放在 RPM 的 %prep 部分中）...

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

如果您完成这个小补丁，您可以恢复 %patch2，因为它应该可以再次正常工作。

答案3

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 调试日志记录的其他可能性对我来说均不起作用。

答案4

Asket...我真的很喜欢你的帖子:) 在过去的 15 个小时里，我一直在与这样的事情作斗争......（虽然我可能有 30 分钟的休息时间）

不知怎么的，我按照你的方法做了，让它工作了，这意味着我有一个 /etc/pam_debug 并在 pam 条目上进行调试。但是，就像我遇到的困难一样pam_mysql，我不得不在我的 pam 条目verbose=1后面再放一个debug：

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。祝你好运！

相关内容