Arch Linux

Sudo akzeptiert Benutzer-Passwort nicht mehr

Overkill

Hallo!

Seit gestern passiert (Ganz plötzlich) folgendes (Angemeldet als normaler Benutzer "USER"):

[USER@arch ~]$ sudo pacman -Syu
Passwort:
Sorry, try again.
Passwort:
Sorry, try again.
Passwort:
Sorry, try again.
sudo: 3 incorrect password attempts
[USER@arch ~]$

Ich habe auch schon folgendes probiert:

[USER@arch ~]$ su root
Passwort:
[root@arch USER]# passwd USER
[root@arch USER]# Geben Sie ein neues UNIX-Passwort ein: "test"
[root@arch USER]# Geben Sie das neue UNIX-Passwort erneut ein: "test"
[root@arch USER]# passwd: Passwort erfolgreich geändert
[root@arch USER]# exit
exit
[USER@arch ~]$
[USER@arch ~]$ sudo pacman -Syu
Passwort: test
Sorry, try again.
Passwort:
sudo: 1 incorrect password attempt
[...]

Vollkommen egal welches Passwort USER hat, es wird einfach nicht angenommen. In der /etc/sudoers wurde nichts geändert, das Problem trat ganz plötzlich ohne ersichtlichen Grund auf. Hat wer eine Idee?

oenone

wie sieht deine sudoers aus? gibt es dateien in /etc/sudoers.d/?

toad

Und auf visudo kannste auch gleich einen Blick werfen... sudo wurde doch neulich aktualisiert, da könnte man mal nach einer pacnew datei checken 🙂

Overkill

Danke an euch für die Hinweise.

Das es ein Verzeichnis /etc/sudoers.d gibt, war mir gar nicht bekannt. Allerdings ist dieses leer.
Weiterhin gibt es auch keinerlei pacnew-Dateien und der Syntax ist auch korrekt (Ich habe die /etc/sudoers ja auch ewig nicht mehr bearbeitet).

[root@arch etc]# visudo -c
/etc/sudoers: parsed OK

Bis auf

USER ALL=(ALL) ALL

Defaults:USER timestamp_timeout=0

liegt die /etc/sudoers auch noch in Standardkonfiguration vor (Das ist hier bewusst so simpel gehalten).

Es kam gestern Nachmittag, ganz plötzlich. Ziemlich kurios das Ganze...

GerBra

Überprüfe deine sudoers als root mal mit:

visudo -sc

Sollte OK melden.

Was dein User dürfte + Settings wäre ggf. auch nochmal interessant:

sudo -l

Was steht nach einem solchen versuch denn in der /var/log/auth.log? 3 x falsches PW?

Du kannst sudo ausführlicher loggen lassen. Lege als root die Datei /etc/sudo.conf an, dort eintragen:

Debug sudo /tmp/sudo_dbg.log all@trace,plugin@info

Das trace-File liegt dann in /tmp. Abstellen durch ein # vor der Zeile oder durch Löschen der Datei (gibt es per default nicht).

Ansonsten:
Hast du noch genug Speicherplatz überall? df -h
Zeigt ein: stat /tmp die Zugriffsrechte als (1777/drwxrwxrwt) root:root an?

Overkill

Danke vielmals, also:

[USER@arch ~]$ sudo visudo -sc
Passwort:
/etc/sudoers: parsed OK
[USER@arch ~]$
[USER@arch ~]$ sudo -l
Passwort:
Matching Defaults entries for USER on this host:
timestamp_timeout=0

User USER may run the following commands on this host:
(ALL) ALL
[USER@arch ~]$

Hier das Relevante aus der /var/log/auth.log

localhost /usr/sbin/crond[871]: PAM _pam_init_handlers: no default config /etc/pam.d/other
localhost /usr/sbin/crond[871]: pam_unix(crond:session): session opened for user root by (uid=0)
localhost /USR/SBIN/CROND[871]: pam_unix(crond:session): session closed for user root
localhost su: PAM _pam_init_handlers: no default config /etc/pam.d/other
localhost su: pam_unix(su:session): session opened for user root by (uid=1000)
localhost su: pam_unix(su:session): session closed for user root
localhost sudo: PAM _pam_init_handlers: no default config /etc/pam.d/other
localhost sudo: PAM no modules loaded for `sudo' service
localhost sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/2 ruser=USER rhost= user=USER
localhost sudo: USER : 3 incorrect password attempts ; TTY=pts/2 ; PWD=/home/USER ; USER=root ; COMMAND=list
localhost su: PAM _pam_init_handlers: no default config /etc/pam.d/other
localhost su: pam_unix(su:session): session opened for user USER by (uid=1000)
localhost sudo: PAM _pam_init_handlers: no default config /etc/pam.d/other
localhost sudo: PAM no modules loaded for `sudo' service
localhost sudo: pam_unix(sudo:auth): conversation failed
localhost sudo: pam_unix(sudo:auth): auth could not identify password for (USER)

Speicherplatz und Zugriffsrechte sind auch in Ordnung. Ich denke nicht, dass der Fehler bei mir (D.h. in meiner Konfiguration) zu suchen ist (Nachtrag: Ja ich weiß, dass ein Downgrade das Problem beseitigt hat, bedeutet logisch nicht, dass das Problem nicht auch auf meiner Machine heimisch sein kann 🙂 ), denn...
Worauf der Auszug aus der /var/log/auth.log schon aufmerksam macht: Ein Downgrade des Pakets testing/pam 1.1.5-4 auf core/pam 1.1.5-3 hat das Problem gelöst.

Mangels freier zeit werde ich vorerst pam auf pacmans ignore-Liste setzen.

oenone

Overkill schriebDanke vielmals, also:
[USER@arch ~]$ sudo visudo -sc
Passwort: 
/etc/sudoers: parsed OK
[USER@arch ~]$

Aha, da funktioniert es also?

Overkill schriebIch denke nicht, dass der Fehler bei mir (D.h. in meiner Konfiguration) zu suchen ist

Wie du selbst herausgefunden hast, lag der Fehler eben doch bei dir... Falls du immer noch anderer Meinung bist, lies bitte das hier genau durch. Besonders den roten Kasten.

GerBra

Ah, testing. Das wäre eine Info wert gewesen…

Trotz alledem fuktioniert bei meinem testing sudo+pam noch wie erwartet. Es gibt soweit ich sehe auch keine Bugreport.

Anhand der Fehlermeldugen aus der auth.log würde ich sagen, daß dein pam 1.1.5-4 entweder nicht richtig installiert war (/etc/pam.d/other ist im pam-Paket, /etc/pam.d/sudo kommt mit dem sudo Paket), oder (das wäre meine Vermutung) du oder irgendetwas (evtl. FS-Error) dir zumindest /etc/pam.d/other gelöscht/verändert hat. Letzeres würde auch deine Aussage "passierte plötzlich, aus heiterem Himmel" bestätigen.

Wenn du also 1.1.5-4 nochmal installierst würde ich sagen: es funktioiert dann wieder.

Overkill

oenone schriebWie du selbst herausgefunden hast, lag der Fehler eben doch bei dir... Falls du immer noch anderer Meinung bist, lies bitte das hier genau durch. Besonders den roten Kasten.

Was willst du mir damit jetzt sagen? Was das testing-repo ist und worum es sich dabei handelt ist mir bestens bewusst. Auf Bugs zu stoßen und deren Ursache zu ermitteln ist ja Sinn der Sache. Letzten Endes kann man jetzt noch nicht sagen, ob testing/pam 1.1.5-4 vielleicht verbugt ist oder der Fehler die Folge einer Misskonfiguration in meinem System ist. Immerhin bin ich nicht der Einzige, der dieses Problem hat:

bugs.archlinux.org/task/30152

thommys

Hatte das Problem auch, aber nach einer neuinstallation von pambase war alles ok.