Włącz debugowanie PAM do Syslog

Nienawidzę PAM, odkąd się pojawił.

Jak włączyć debugowanie PAM w Debian Squeeze na poziomie administratora?

Sprawdziłem każdy zasób, który udało mi się znaleźć. Google, strony, cokolwiek. Jedyną rzeczą, której jeszcze nie próbowałem (po prostu nie mam odwagi, czy wspominałem, że nienawidzę PAM?), Jest kopanie w źródle biblioteki PAM.

Próbowałem znaleźć w Google rozwiązanie, nic. Co znalazłem do tej pory:

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) i http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugopcja na wpisy PAM w /etc/pam.d/).

Nie, nie działa. Brak wyjścia PAM, nic, absolutna cisza.

Szukając rozwiązania, skorzystałem nawet z linków do Pam, czyli stacji benzynowych w Niemczech. Cóż, tak, być może we wszystkich tych miliardach trafień może kryć się wskazówka, ale zastrzel mnie, że byłbym martwy, zanim się dowiem.

Reszta to FYI:

Jaki miałem problem?

Po przejściu na Debian Squeeze coś stało się dziwne (cóż, hej, kiedyś było to, co było tuż nad Etch .. ach, tak, Woody). Więc prawdopodobnie nie jest to wina Debiana, tylko długa, zepsuta konfiguracja. Od razu miałem wrażenie, że ma coś wspólnego z PAM, ale tak naprawdę nie wiedziałem, co się dzieje. Byłem całkowicie w ciemności, pozostawiony sam sobie, bezradny jak dziecko, YKWIM. Niektóre logowania ssh działały, inne nie. To było trochę zabawne. Żadnych wskazówek ssh -v, żadnych wskazówek /var/log/*, nic. Po prostu „autoryzacja powiodła się” lub „autoryzacja nie powiodła się”, czasami ten sam użytkownik logował się równolegle z jedną sesją i nie udało się z drugą, w tym samym czasie. I nic, czego tak naprawdę nie możesz zdobyć.

Po wykopaniu ładunków z innych opcji udało mi się dowiedzieć. Jest nulloki nullok_secure, Debian special. Coś wkręciło się /etc/securettyi w zależności od tty(co jest dość losowe) login został odrzucony lub nie. NAPRAWDĘ ŁADNE, uff!

Poprawka była łatwa i znów wszystko jest w porządku.

Pozostało mi jednak pytanie, jak w przyszłości debugować taki bałagan . To nie pierwszy raz PAM doprowadza mnie do szału. Chciałbym więc zobaczyć ostateczne rozwiązanie. Ostateczny jak w „rozwiązany”, nie ostateczny jak w „armageddon”. Dzięki.

Ach, BTW, to ponownie wzmocniło moje przekonanie, że dobrze jest nienawidzić PAM, odkąd się pojawiło. Czy wspomniałem, że tak?

Kilka rzeczy do wypróbowania:

Czy włączyłeś rejestrowanie komunikatów debugowania w syslog?

cp /etc/syslog.conf /etc/syslog.conf.original
vi /etc/syslog.conf

Dodaj następujący wiersz:

*.debug     /var/log/debug.log

Wyjdź z :wq!.

touch /var/log/debug.log
service syslog restart

Możesz włączyć debugowanie dla wszystkich modułów tak:

touch /etc/pam_debug

LUB możesz włączyć debugowanie tylko dla modułów, którymi jesteś zainteresowany, dodając „debugowanie” na końcu odpowiednich wierszy /etc/pam.d/system-authlub innych /etc/pam.d/*plików:

login   auth    required    pam_unix.so debug

Następnie komunikaty debugowania powinny zacząć się pojawiać w /var/log/debug.log. Mam nadzieję, że to ci pomoże!

Przynajmniej w CentOS 6.4 /etc/pam_debugNIE jest używany.

Jeśli moduł pam_warn.so jest zainstalowany, możesz uzyskać dane wyjściowe logowania w ten sposób:

auth required pam_warn.so

success required pam_warn.so

itp. Moduł ten zapewnia, że ​​nie będzie zakłócał procesu uwierzytelniania w żadnym momencie, ale rejestruje znaczące rzeczy za pośrednictwem syslog.

Aktualizacja

Po zbadaniu kodu i przeprowadzeniu kompilacji odkryłem, że (1) można włączyć ten tryb debugowania przez źródło, i (2) łatka RHEL sprawia, że ​​funkcja jest prawie bezużyteczna (przynajmniej moduł pam_unix) i (3) jest to prawdopodobnie lepiej i tak załatać kod.

Aby to działało dla RHEL, możesz pobrać Linux-PAM ... src.rpm (dla dowolnej wersji 1.1) i zmienić plik spec w następujący sposób:

• Znajdź linię zaczynającą się od

  % konfiguracji \

a następnie dodaj --enable-debug \

• Usuń linię lub skomentuj linię (powyżej poprzedniej), która zaczyna się od% patch2

Następnie skompiluj rpm i zainstaluj (siłą, aby zastąpić istniejące pakiety). Teraz utwórz plik /var/run/pam-debug.log:

install -m 622 /dev/null /var/run/pam-debug.log

Jeśli plik nie istnieje, dane wyjściowe debugowania zostaną wysłane do stderr.

• To wysyłanie do stderr jest, moim zdaniem, głupie i powoduje konflikt łatek. Możesz zmienić to zachowanie, przechodząc do pliku libpam / include / security / _pam_macros.h i zastępując 4 linie

  plik dziennika = stderr;

z

return;

Po kompilacji otrzymasz ostrzeżenia o niedostępnych instrukcjach, ale można je zignorować. Możesz wprowadzić tę zmianę w skrypcie sed (i umieścić ją w sekcji% prep RPM po łatkach) ...

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

JEŚLI zrobisz tę małą łatkę, możesz przywrócić% patch2, ponieważ powinna ona znowu działać poprawnie.

Właśnie spędziłem kilka godzin, próbując dowiedzieć się, jak włączyć dzienniki debugowania w PAM na CentOS 6.4. Chociaż to pytanie dotyczy Debiana, nadal będę pisać, jak to zrobić na CentOS, w nadziei, że inni ludzie nie będą musieli poświęcać czasu, który już mam.

Jak się ostatecznie okazało, włączenie dzienników debugowania w pampakiecie CentOS jest proste. Trudność wynika z faktu, że polega ona na ponownej kompilacji pakietu. Więc najpierw znajdź SRPM (np. pam-1.1.1-13.el6.src.rpm) Stąd . Osoby, które nie wiedzą o kompilowaniu pakietów z SRPM, mogą zapoznać się z krokami konfigurowania środowiska kompilacji RPM .

Oto główny krok. Otwórz plik specyfikacji i dodaj --enable-debugdo %buildsekcji w configurewywołaniu. Przekompiluj! Ponownie zainstaluj nowo utworzony pakiet. Na koniec utwórz plik, w którym zostaną zapisane dzienniki debugowania.

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

Jeśli nie utworzysz tego pliku, na terminalu pojawi się wiele dzienników, co może nie być bardzo przydatne.

Debian i Ubuntu (i może inne dystrybucje) mają specjalny plik dziennika, do którego logowane są wszystkie dane wyjściowe pam:

/var/log/auth.log

Od półtora dnia zmagam się z problemem związanym z pam, w końcu dowiedziałam się o tym pliku dziennika i uratowałam się od szaleństwa.

Oto próbka zawartości tego pliku, gdy wszystko nie idzie zgodnie z planem.

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

Oto jak to wygląda, gdy działa:

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)

Zauważ, że żadna inna możliwość włączenia rejestrowania debugowania pam nie działała dla mnie.

Coś wkręciło się w / etc / securetty iw zależności od tty (co jest dość losowe) login został odrzucony lub nie. NAPRAWDĘ ŁADNE, uff!

Czy mógłbyś trochę to rozwinąć?

Za stronę zabezpieczonego pomostu :

the file contains the device names of terminal lines (one per line, without leading /dev/) on which root is allowed to login.

Opisane przez ciebie zachowanie brzmi podobnie do tego, że Securetty działa normalnie (zakładając, że faktycznie logujesz się jako root).

Niektóre logowania ssh działały, inne nie.

Również w tym przypadku mogą obowiązywać ograniczenia inne niż PAM, więc może pomóc w uzyskaniu wglądu w to, /etc/ssh/sshd_configjak wygląda twój .

W szczególności z twojego opisu:

• jeśli próbujesz zalogować się jako root, ale kończy się to niepowodzeniem, może to wynikać z obecności tej linii w sshd_config:PermitRootLogin no
• jeśli niektórzy użytkownicy / grupy pracy, a inni nie, jednym z powodów może być stosowanie w sshd_configod AllowGroupslub AllowUsers. Przykładowa linia może wyglądać następująco: AllowGroups users admins

Oczywiście jest całkowicie możliwe, że PAM jest częścią problemu, ale twoje główne „objawy” brzmią dla mnie, jakby można je było wyjaśnić innymi sposobami.

Asket ... Naprawdę podobał mi się twój post :) Walczyłem z takimi rzeczami przez ostatnie 15 godzin ... (chociaż mogłem mieć 30 min przerwy)

W jakiś sposób udało mi się to zrobić, wykonując wszystkie czynności, które zrobiłeś, co oznacza, że ​​mam plik / etc / pam_debug i debuguję wpisy pam. Ale jak w moim przypadku miałem problemy ze pam_mysqlmusiałem postawić kolejny verbose=1po debugmoich wpisach 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

Ten „sqllog” służy tylko do zapisywania dzienników w bazie danych.

Może to ci trochę pomoże.

Wszyscy nienawidzimy PAM. Powodzenia!