Включить отладку PAM в Syslog

По крайней мере, на 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) и изменить файл спецификации следующим образом:

• Найдите строку, начинающуюся с

  %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 строки

  logfile = stderr;

с

return;

При сборке вы получите предупреждения о недостижимых утверждениях, но их можно игнорировать. Вы можете внести это изменение в сценарий sed (и поместить его в раздел%prep RPM после исправлений)...

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

Если вы сделаете этот маленький патч, вы можете восстановить%patch2, так как он снова должен работать правильно.

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 не работала для меня.

Мне довелось потратить несколько часов, пытаясь выяснить, как включить журналы отладки в PAM на CentOS 6.4. Хотя этот вопрос для Debian, я все же напишу, как это сделать в CentOS, в надежде, что другие люди не должны тратить время, которое у меня уже есть.

Как в конечном итоге оказалось, включение журналов отладки в pam Пакет CentOS прост. Сложность связана с тем, что он включает в себя перекомпиляцию пакета. Итак, сначала найдите SRPM (например, pam-1.1.1-13.el6.src.rpm) отсюда Люди, которые не знают о компиляции пакетов из SRPM, могут обратиться к инструкциям по настройке среды сборки RPM.

Вот главный шаг. Откройте файл спецификации и добавьте --enable-debug к %build раздел в configure призывание. Перекомпилируйте! Переустановите вновь созданный пакет. Наконец, создайте файл, в который будут записываться журналы отладки.

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

Если вы не создадите файл, на терминале будет пролетать множество журналов, что может быть не очень полезно.

В основном эта информация присутствует в других ответах, но в основном скрыта в строках текста.

Один из вариантов – пройтиdebugв модуль, что делает его более подробным, но не намного.

Если вам нужна дополнительная информация, вам нужно создатьpamс--enable-debug. Либо путем сборки из исходного кода (autoreconf && ./configure --enable-debug ... && make install) или из исходного пакета (deb, rpm, ...), который зависит от ОС. В результате, если у него достаточно разрешений, он создает/var/run/pam-debug.logи пишет туда. В противном случае он выводит на stderr . Возможно, вы захотите создать/var/log/pam-debug.logзаранее, чтобы у него было достаточно прав.

О/etc/pam_debug, у меня это не сработало.

Что-то напортачило с /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 является частью проблемы, но ваши основные "симптомы" звучат для меня так, будто их можно объяснить другими способами.

Аскет... Мне очень понравился твой пост:) Я боролся с такими вещами в течение последних 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. Удачи!