我讨厌PAM，因为它来了。
如何在pipe理员级别切换Debian Squeeze中的PAMdebugging？
我检查了我能find的所有资源。 谷歌，手册，无论如何。 我唯一没有尝试过的东西（我根本就不敢，我提到我讨厌PAM吗？）正在挖掘PAM的图书馆资源。
我试图谷歌的解决scheme，什么都没有。 我到目前为止发现的：
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选项/etc/pam.d/ PAM条目）。
不，不行。 没有PAM输出，没有什么，绝对的沉默。
在寻找解决scheme的同时，我甚至还跟随了Pam的链接，这些链接是德国的加油站。 呃，是的，也许在所有这些数十亿次的点击中，可能会隐藏一个线索，但是在我发现之前，开枪我就会死掉。
rest是供参考：
我有什么问题？
升级到Debian之后，挤压一些奇怪的东西（好吧，嘿，它曾经是，呃，什么是Etch ..啊，是的，伍迪）。 所以这可能不是Debian的错，只是一个长期的搞砸的设置。 我立刻有一个印象就是要用PAM做点什么，但是我真的不知道发生了什么事情。 我完全是在黑暗中，独自一人，像婴儿一样无助，YKWIM。 一些sshlogin工作，一些没有。 这很有趣。 在ssh -v中没有线索， /var/log/*没有线索，什么也没有。 只是“auth succeeded”或“auth fail”，有时同一个用户同时login一个会话成功，另一个同时login失败。 没有什么是你真正能够得到的。
挖掘了其他选项列车后，我能够find。 有nullok_secure和nullok_secure ，一个Debian的特殊。 有些东西与/etc/securetty拧，并根据tty （这是有点随机）login被拒绝或不。 真的很好，唷！
修复很简单，现在一切都好了。
然而，这留下了一个问题，未来如何debugging这样一个混乱 。 这不是PAM第一次让我疯狂。 所以我想看看最后的解决scheme。 最终在“解决”，而不是最后的“大决战”。 谢谢。
啊，顺便说一句，这再一次强化了我的信念：自从它出现以来，讨厌PAM是一件好事。 我有没有提到我呢？
有几件事情可供您尝试：
你是否启用syslog日志loggingdebugging信息？
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
您可以启用所有模块的debugging，如下所示：
touch /etc/pam_debug
或者，您可以通过将“debug”添加到/etc/pam.d/system-auth或其他/etc/pam.d/*文件中相关行的末尾来启用仅针对您感兴趣的模块的debugging：
login auth required pam_unix.so debug
然后debugging消息应该开始出现在/var/log/debug.log 。 希望这可以帮助你！
至less在CentOS 6.4上，不使用/etc/pam_debug 。
如果安装了pam_warn.so模块，则可以通过以下方式获得一些日志输出：
auth required pam_warn.so success required pam_warn.so
等等。这个模块确保它不会在任何时候干扰authentication过程，但是它通过sysloglogging有意义的东西。
在检查代码并进行编译之后，我发现（1）可以通过源启用该debugging模式，（2）RHEL修补程序使该function几乎不可用（至less是pam_unix模块），（3）无论如何，修补代码可能更好。
为了使它适用于RHEL，你可以得到Linux-PAM … src.rpm（对于任何1.1版本）并且改变spec文件，如下所示：
find以。开头的行
％configuration \
之后，添加–enable-debug \
然后build立转速和安装（用力，覆盖现有的软件包）。 现在创build文件/var/run/pam-debug.log：
install -m 622 /dev/null /var/run/pam-debug.log
如果文件不存在，debugging输出将被发送到stderr。
在我看来，发送到stderr是愚蠢的，是什么导致补丁冲突。 您可以通过进入文件libpam / include / security / _pam_macros.h并将4行replace为
logfile = stderr;
同
return;
在构build时，您会收到关于无法访问的语句的警告，但可以忽略它们。 您可以在sed脚本中进行此更改（并在修补程序之后将其放入RPM的％prep部分中）…
sed -i 's/logfile = stderr;$/return;/' libpam/include/security/_pam_macros.h
如果你做这个小补丁，你可以恢复％patch2，因为它应该再次正常工作。
我碰巧花了几个小时试图找出如何在CentOS 6.4上启用PAM中的debugging日志。 虽然这个问题是针对Debian的，但我仍然会在CentOS上写下如何去做，希望其他人不必把我已经拥有的时间放在一边。
最终结果是，在pam CentOS软件包中启用debugging日志非常简单。 这个困难源于包含重新编译包的事实。 所以，首先从这里findSRPM（例如pam-1.1.1-13.el6.src.rpm ）。 不知道从SRPM编译软件包的人可以参考设置RPM构build环境的步骤。
这是主要的一步。 打开spec文件并在configure调用的%build部分添加--enable-debug 。 重新编译！ 重新安装新创build的软件包。 最后，创builddebugging日志将被写入的文件。
$ sudo touch /var/run/pam-debug.log
如果你不创build文件，那么很多日志会在terminal上飞，这可能不是很有用。
Debian和Ubuntu（也许还有其他的发行版）有一个特殊的日志文件，所有的pam输出都被logging在这里：
/var/log/auth.log
我在一天半的时间里一直在和一个pam相关的问题苦苦挣扎，终于find了这个日志文件，从疯狂中拯救了自己。
如果事情没有按计划进行，这里有一个这个文件内容的例子。
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)
请注意，启用pamdebugging日志logging的其他任何可能性都不适用于我。
Asket …我真的很喜欢你的post:)在过去的15个小时里，我正在和这样的东西争斗……（我可能有一个30分钟的突破）
不知何故，我通过做所有的事情来实现它，这意味着我有一个/ etc / pam_debug并在pam条目上进行debugging。 但在我的情况下，我正在努力与pam_mysql ，我不得不在pam条目debug后，另一个verbose=1 ：
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。 祝你好运！
有些东西与/ etc / securetty拧，并根据tty（这是有点随意）login被拒绝或不。 真的很好，唷！
你能扩展一下吗？
根据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身份login）。
一些sshlogin工作，一些没有。
这里也可能存在非PAM限制，因此可以帮助您深入了解/etc/ssh/sshd_config外观。
值得注意的是，从你的描述：
sshd_config ： PermitRootLogin no AllowGroups或AllowUsers sshd_config的一个原因。 示例行可能如下所示： AllowGroups users admins 当然，PAM是完全可能的，但是你的主要“症状”听起来像是可以用其他方式解释的。