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

Я ненавижу PAM, так как он появился.

Как включить отладку PAM в Debian Squeeze на уровне администратора?

Я проверил все ресурсы, которые мне удалось найти. Google, manpages, что угодно. Единственное, что я еще не попробовал (я просто не осмелился упомянуть, что я ненавижу 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, ничего, абсолютная тишина.

В поисках решения я даже перешел по ссылкам на Пэм, которые находятся в Германии. Ну, да, возможно, во всех этих миллиардах хитов может быть скрыта зацепка, но пристрелите меня, я умру, пока не обнаружу.

Отдых для вас:

Какая проблема у меня была?

После обновления до Debian Squeeze что-то стало странным (ну, эй, когда-то это было что-то вроде того, что было над Etch ... ах, да, Вуди). Так что, вероятно, это не вина Debian, просто долгожданная испорченная установка. У меня сразу возникло впечатление, что это связано с PAM, но я действительно не знал, что происходит. Я был полностью в темноте, остался один, беспомощный, как ребенок, YKWIM. Некоторые логины ssh работали, некоторые нет. Это было довольно забавно. Никаких подсказок ssh -v, никаких подсказок /var/log/*, ничего. Просто «аутентификация завершилась успешно» или «аутентификация завершилась неудачей», иногда один и тот же пользователь, входящий в систему, параллельно преуспевал в одном сеансе и одновременно в другом. И ничего, что вы действительно можете получить.

После раскопок поездов других вариантов я смог выяснить. Существует nullokи nullok_secureспециальная версия Debian. Что-то напортачило /etc/securettyи в зависимости от tty(что несколько случайно) входа было отклонено или нет. ДЕЙСТВИТЕЛЬНО Ницца, фу!

Исправить было легко, и теперь все снова хорошо.

Однако это оставило меня с вопросом, как отладить такой беспорядок в будущем. Это не первый раз, когда PAM сводит меня с ума. Поэтому я хотел бы увидеть окончательное решение. Финал, как в «решено», а не финал, как в «Армагеддоне». Спасибо.

Ах, кстати, это снова укрепило мою веру в то, что хорошо ненавидеть PAM с тех пор, как он появился. Я упоминал, что я делаю?

Несколько вещей для вас, чтобы попробовать:

Вы включили запись отладочных сообщений в системный журнал?

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

ИЛИ вы можете включить отладку только для интересующих вас модулей, добавив «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

и т.д. Этот модуль гарантирует, что он не будет вмешиваться в процесс аутентификации в любой момент, но он регистрирует значимые вещи через системный журнал.

Обновить

Изучив код и выполнив некоторую компиляцию, я обнаружил, что (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, так как он снова должен работать правильно.

Мне довелось потратить несколько часов, пытаясь выяснить, как включить журналы отладки в 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

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

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

Аскет ... Мне очень понравился твой пост :) Я боролся с такими вещами в течение последних 15 часов ... (хотя, возможно, у меня был 30-минутный перерыв)

Каким-то образом я получил это, выполнив все то, что вы сделали, что означает, что у меня есть / etc / pam_debug и отладка записей pam. НО, как и в моем случае, с которым я боролся pam_mysql, мне пришлось поставить еще один 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. Удачи!