PAM: Authentifizierungsfehler mit gültigem Kennwort

Befehl

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

journctl

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

So wie es jetzt aussieht, verhindert jeder Sperrbildschirm, dass ich "entsperre" (KDE-Sperrbildschirm i3lockusw.).

Wenn ich i3lockals beginne sudo, kann ich das Root- Passwort richtig eingeben, um den Bildschirm zu entsperren. Wenn ich es jedoch als normaler Benutzer ausführe und zum Entsperren kein normales Benutzer- oder Root-Passwort verwenden kann.

Hier ist meine PAM-Konfiguration für 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

Laufende ls -l /etc/passwd /etc/shadow /etc/groupShows

-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

Dies ist eine Neuinstallation von Arch, daher denke ich nicht, dass die Konfiguration zu wackelig ist. Worauf sollte ich achten, um dies zu debuggen?

Laufende ls -l /sbin/unix_chkpwdShows

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

pam

— Paul Knopf
quelle

Sie haben ein Benutzerkonto pknopfin Ihrem /etc/passwdusw. und es kann sich anmelden?

— Roaima

Mein Konto befindet sich in / etc / passwd.

— Paul Knopf

Ich kann "pamtester auth pknopf authenticate" mit (als) Root-Benutzer ausführen, aber nicht mit pknopf-Benutzer.

— Paul Knopf

Ergebnis ls -l /sbin/unix_chkpwdIhrer Frage hinzugefügt, bitte.

— Roaima

Die Frage wurde aktualisiert, um die Ausgabe einzuschließen.

— Paul Knopf

Antworten:

Ihre Systeminstallation scheint fehlerhaft zu sein. Aus irgendeinem Grund hat die Datei /sbin/unix_chkpwddie erwarteten Berechtigungsbits verloren.

Korrigieren Sie die Berechtigungen, indem Sie den folgenden Befehl als root ausführen:

chmod u+s /sbin/unix_chkpwd

Überprüfen Sie nun, ob die Berechtigungen wie folgt lauten (siehe das sBit in den Benutzerberechtigungen):

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

In meiner Raspbian-Distribution sind die Berechtigungen etwas anders (und restriktiver) festgelegt. Wenn die oben beschriebene Änderung nicht funktioniert, ändern Sie die Berechtigungen für diese beiden Dateien sorgfältig und prüfen Sie, ob dies hilfreich ist (der Gruppenname spielt keine große Rolle, solange er in beiden Fällen gleich ist):

-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
quelle

Dies ist mein Problem. Es war ein Ergebnis davon, dass Docker dieses Privileg-Bit entfernt hat. github.com/moby/moby/issues/36239

— Paul Knopf

Auf einem Debian-Computer musste ich in meinem Fall der shadowGruppe exim4-Benutzer hinzufügen .

usermod -a -G shadow Debian-exim

PAM: Auf Debian-Systemen werden die PAM-Module als derselbe Benutzer wie das aufrufende Programm ausgeführt, sodass sie nichts tun können, was Sie nicht selbst tun können, und insbesondere nicht auf / etc / shadow zugreifen können, es sei denn, der Benutzer befindet sich im Gruppenschatten. - Wenn Sie / etc / shadow für Exims SMTP AUTH verwenden möchten, müssen Sie exim als Gruppenschatten ausführen. Nur exim4-daemon-heavy ist mit libpam verknüpft. Wir empfehlen stattdessen die Verwendung von saslauthd.

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

— Daniel Sokolowski
quelle