Включите отладку 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

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

logfile = stderr;

с участием

return;

При сборке вы получите предупреждения о недостижимых операторах, но их можно игнорировать. Вы можете внести это изменение в сценарий sed (и поместить его в раздел% prepare 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 у меня не сработала.

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

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