Włącz debugowanie PAM do Syslog

34

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?

Tino
źródło
Oto jak samemu rozwiązać ten problem na Debianie: passwd -d usera następnie spróbuj ssh do pudełka w ten sposób user. Wyjściowe „nieudane hasło” w syslog w ogóle nie ma nic wspólnego z debugowaniem PAM, więc PAM milczy.
Tino
Zapomniałem wspomnieć, że trzeba ustawić PermitEmptyPasswords yesw /etc/ssh/sshd_configoczywiście wtedy PAM Wyjścia coś podobnego pam_unix(sshd:auth): authentication failure, ale nadal nic do kanału debugowania ani żaden moduł PAM nutą która spowodowała awarię.
Tino
Czy debian ma /var/log/auth.logplik? Niedawno odkryłem, że Ubuntu ma to i zapisuje tam wszystkie związane z pam rzeczy. Żadna z odpowiedzi tutaj nie pomogła mi, ale wyszukiwanie /var/log/auth.logpomogło mi rozwiązać problem.
LordOfThePigs
/var/log/auth.logjest syslog. Problemem nie jest logowanie, ale debugowanie. Jeśli na przykład stos PAM zawiedzie wcześnie, nic nie zobaczysz, ponieważ moduły, które są wysyłane, syslogw ogóle nie są wywoływane. Lub coś zawiedzie i coś nie, ale oba logują dokładnie te same linie. Zgadza się, że 95% wszystkich przypadków można rozwiązać, przeglądając zwykłe dzienniki, ale 5% nie, ponieważ po prostu nie ma śladu tego, co naprawdę dzieje się za kulisami.
Tino
4
+1 za nienawiść do PAM. ;)
Zayne S Halsall

Odpowiedzi:

24

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!

sn3ak3rp1mp
źródło
Dobra odpowiedź, ale myślę, że miałem debugowanie syslog. Sprawdzę to.
Tino
Sprawdziłem, przepraszam, twoja odpowiedź nie jest rozwiązaniem. PAM nadal milczy. Być może jest to nullokwyjątkowa cecha polegająca na tym, że w tym module brakuje debugowania. Powiem to w ten sposób: brak debugowania tak kluczowego kodu jest gorszym koszmarem niż prześladowanie go przez Freddy'ego Krugera.
Tino
OK, cóż, myślę, że odpowiedź brzmi poprawnie! To nie wina odpowiedzi PAMjest niemowa. Na razie akceptuję to jako „rozwiązanie”, dopóki się nie PAMskapituluję. Dzięki.
Tino
Nadal nie widzę danych wyjściowych debugowania, ale w każdym razie na Ubuntu 16.04, aby wyświetlić debugowanie syslog, wykonaj: echo '* .debug /var/log/debug.log'> /etc/rsyslog.d/90-debug. conf; systemctl restart rsyslog.service
Noam
Pamiętaj, że potrzebujesz odpowiednich uprawnień i prawa własności do pliku na debug.log - ustaw go tak samo jak syslog. (To proste i łatwe do zapomnienia.)
mgarey
10

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.

Otheus
źródło
Dzięki. Dobra wskazówka. Spróbuję, jeśli kiedykolwiek będę miał problemy. Więc mam nadzieję, że nigdy ...;)
Tino
To działało dla mnie, ale zauważ, że jeśli używasz SELinux, musisz ustawić odpowiednie konteksty na /var/run/pam-debug.log (system_u: object_r: var_log_t przechwycił większość wiadomości). W przeciwnym razie wiele wyników debugowania zostanie zapisanych do standardowego błędu (lub dyskretnie odrzuconych, jeśli załatałeś standardowe zachowanie błędu RedHata).
jgibson
6

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.

pdp
źródło
Mile widziane są również inne smaki Uniksa lub cokolwiek, co odważy się korzystać z PAM;)
Tino
5

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.

LordOfThePigs
źródło
1
Należy pamiętać, że wszystkie wiersze takie jak pam_*faktycznie są PAM. Pozostałe linie są mimo to wyprowadzane przez narzędzia, niezależnie od tego, czy używają PAM, czy nie. Oznacza to: Jeśli PAM zaprzeczy, z jakiegokolwiek powodu, naprawdę trudno jest znaleźć prawdziwą przyczynę, jeśli jest w PAM. Linie inne niż PAM nie są pomocne (ponieważ problem tkwi w PAM), a linie PAM często też nie są pomocne, ponieważ często są zbyt ciche. Przy obecności wielu modułów PAM naprawdę trudno jest zgadnąć, który moduł może być winowajcą, nie mówiąc już o tym, jak włączyć debugowanie, ponieważ jest inaczej dla każdego z nich.
Tino
0

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.

iwaseatenbyagrue
źródło
-1

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!

Alex
źródło
1
Dzięki za podpowiedź, ale niestety to nie pomaga:pam_unix(sshd:auth): unrecognized option [verbose=1]
Tino