Увімкніть налагодження PAM в Syslog

Я ненавиджу PAM з моменту появи.

Як увімкнути налагодження PAM в Debian Squeeze на рівні адміністратора?

Я перевірив кожен ресурс, який мені вдалося знайти. Google, керівництво, будь-яке інше. Єдине, чого я ще не пробував (я просто не наважуюся, чи згадував я, що ненавиджу PAM?) - це заглиблення у джерело бібліотеки PAM.

Я намагався гугл шукати рішення, нічого. Що я знайшов поки:

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, нічого, абсолютна тиша.

Шукаючи рішення, я навіть перейшов до посилань на Пам, що є АЗС тут, у Німеччині. Що ж, так, можливо, у всіх цих мільярдах хітів може ховатися підказки, але застрелити мене я був би мертвим, перш ніж я виявлю.

Відпочинок FYI:

Яка проблема була у мене?

Після оновлення до Debian Squeeze щось стало дивно (ну, ей, колись це було, е-е, що було правильно над Etch .. ах, так, Вуді). Тож це, мабуть, не винна Дебіана, просто довгий накручений настрій. У мене одразу склалося враження, що вона має щось робити з PAM, але я справді не знала, що відбувається. Я був повністю в темряві, залишився один, безпорадний як дитина, YKWIM. Деякі ssh логіни працювали, деякі ні. Це було якось смішно. Ні підказки ssh -v, ні підказки /var/log/*, нічого. Просто "auth успішно" або "auth fail", іноді один і той самий користувач входив паралельно з одним сеансом, а з іншим - невдало. І нічого, чого ви насправді не можете отримати.

Після копання поїздів з інших варіантів я зміг це з'ясувати. Існує nullokі nullok_secure, спеціальний Debian. Щось із накрученим /etc/securettyі залежним від tty(що дещо випадковим) логіном було відхилено чи ні. ДІЙСНО НІЖЕ, феу!

Виправити було легко, і все знову добре.

Однак це не дало мені питання, як налагодити такий безлад у майбутньому. Це вже не перший раз, коли PAM ганяє мене. Тому я хотів би бачити остаточне рішення. Фінал, як у "вирішеному", не остаточний, як в "Армагеддоні". Спасибі.

А, BTW, це знову зміцнило мою віру в те, що добре ненавидіти PAM з моменту появи. Я згадав, що я роблю?

Ще кілька речей, які ви спробуєте:

Ви ввімкнули вхід журналу налагоджених повідомлень у syslog?

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

і т.д. Цей модуль гарантує, що він не буде перешкоджати процесу автентифікації в будь-який момент, але він записує змістовні речі через syslog.

Оновлення

Вивчивши код і зробивши деяку компіляцію, я виявив, що (1) можна ввімкнути цей режим налагодження через джерело, і (2) патч RHEL робить цю функцію майже непридатною (принаймні модуль pam_unix) і (3) це мабуть, краще все-таки латати код.

Щоб це працювало для RHEL, ви можете отримати Linux-PAM ... src.rpm (для будь-якої версії 1.1) та змінити файл специфікації таким чином:

• Знайдіть рядок, що починається з

  % налаштування \

і після цього додайте --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 (а може бути, інші дистрибутиви) мають спеціальний файл журналу, в який записується весь вихід пам 'ятки:

/var/log/auth.log

Я боровся з проблемою, пов’язаною з пам’яткою, півтора дня, нарешті дізнався про цей файл журналу і врятував себе від божевілля.

Ось зразок вмісту цього файлу, коли справи йдуть не так, як планували.

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.

Поведінка, яку ви описуєте, дуже схоже на те, що безпека працює нормально (припускаючи, що ви дійсно ввійшли як 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_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. Удачі!