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?
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ę.
/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.
/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.
passwd -d usera następnie spróbuj ssh do pudełka w ten sposóbuser. Wyjściowe „nieudane hasło” w syslog w ogóle nie ma nic wspólnego z debugowaniem PAM, więc PAM milczy.