Включить отладку 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 с тех пор, как он появился. Я упоминал, что я делаю?
7 ответов
Несколько вещей для вас, чтобы попробовать:
Вы включили запись отладочных сообщений в системный журнал?
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, так как он снова должен работать правильно.
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. Удачи!