PAM: Błąd uwierzytelnienia z prawidłowym hasłem

Komenda

pamtester -v auth pknopf authenticate
pamtester: invoking pam_start(auth, pknopf, ...)
pamtester: performing operation - authenticate
Password:
pamtester: Authentication failure

dziennik

Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: check pass; user unknown
Feb 06 13:22:17 PAULS-ARCH unix_chkpwd[31998]: password check failed for user (pknopf)
Feb 06 13:22:17 PAULS-ARCH pamtester[31997]: pam_unix(auth:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost=  user=pknopf

W obecnej postaci każdy ekran blokady uniemożliwia mi „odblokowanie” (ekran blokady KDE i3lockitp.).

Jeśli zacznę i3lockjako sudo, mogę następnie poprawnie wpisać hasło roota, aby odblokować ekran. Jednak jeśli uruchomię go jako normalny użytkownik i nie będę mógł użyć zwykłego użytkownika ani hasła roota, aby odblokować.

Oto moja konfiguracja PAM dla i3lock.

#
# PAM configuration file for the i3lock screen locker. By default, it includes
# the 'system-auth' configuration file (see /etc/pam.d/login)
#
auth include system-auth

Prowadzenie ls -l /etc/passwd /etc/shadow /etc/grouppokazów

-rw-r--r-- 1 root root 803 Feb 6 14:16 /etc/group
-rw-r--r-- 1 root root 1005 Feb 6 14:16 /etc/passwd
-rw------- 1 root root 713 Feb 6 14:16 /etc/shadow

To jest nowa instalacja Arch, więc nie sądzę, że konfiguracja jest zbyt niepewna. Czego powinienem szukać, aby to debugować?

Prowadzenie ls -l /sbin/unix_chkpwdpokazów

-rwxr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd

pam

— Paul Knopf
źródło

Nie masz konta użytkownika pknopfw swoim /etc/passwditp, a to może się zalogować?

— roaima,

Moje konto znajduje się w / etc / passwd.

— Paul Knopf,

Mogę „pamtester auth pknopf uwierzytelnić” z (działającym jako) użytkownikiem root, ale nie z użytkownikiem pknopf.

— Paul Knopf

Proszę o wynik ls -l /sbin/unix_chkpwddodany do pytania.

— roaima,

Zaktualizowano pytanie, aby uwzględnić wynik.

— Paul Knopf,

Odpowiedzi:

Wygląda na to, że instalacja systemu jest zepsuta. Z jakiegoś powodu plik /sbin/unix_chkpwdutracił bity uprawnień, których spodziewałbym się zobaczyć.

Napraw uprawnienia, uruchamiając następujące polecenie jako root:

chmod u+s /sbin/unix_chkpwd

I sprawdź, czy uprawnienia są teraz następujące (patrz sbit w uprawnieniach użytkownika):

-rwsr-xr-x 1 root root 31392 Jun  9  2016 /sbin/unix_chkpwd

W mojej dystrybucji Raspbian uprawnienia są ustawione nieco inaczej (i bardziej restrykcyjnie). Jeśli zmiana opisana powyżej nie działa, ostrożnie zmień uprawnienia do tych dwóch plików i sprawdź, czy to pomoże (nazwa grupy nie ma większego znaczenia, o ile jest taka sama w obu przypadkach):

-rw-r----- 1 root shadow  1354 Dec  6 13:02 /etc/shadow
-rwxr-sr-x 1 root shadow 30424 Mar 27  2017 /sbin/unix_chkpwd

— roaima
źródło

To jako mój problem. Było to wynikiem pozbawienia Dockera tego bitu uprawnień. github.com/moby/moby/issues/36239

— Paul Knopf

Na maszynie Debiana w moim przypadku musiałem dodać użytkownika exim4 do shadowgrupy.

usermod -a -G shadow Debian-exim

PAM: W systemach Debian moduły PAM działają jako ten sam użytkownik co program wywołujący, więc nie mogą zrobić niczego, czego sam nie mógłbyś zrobić, aw szczególności nie mogą uzyskać dostępu do / etc / shadow, chyba że użytkownik jest w cieniu grupy. - Jeśli chcesz użyć / etc / shadow dla Exim's SMTP AUTH, będziesz musiał uruchomić exim jako grupowy cień. Tylko exim4-daemon-heavy jest powiązany z libpam. Zamiast tego zalecamy użycie saslauthd.

http://lira.no-ip.org:8080/doc/exim4-base/README.Debian.html

— Daniel Sokołowski
źródło