Ich habe meine Bildschirmschoner so konfiguriert, dass der Desktop nach einiger Zeit gesperrt wird. und manchmal, z. B. wenn ich meinen Schreibtisch verlasse, ziehe ich es vor, den Bildschirm selbst mit der Titelleiste "Konto sperren / wechseln ..." zu sperren.

Beim erneuten Anmelden gebe ich mein Passwort ein, das jedoch als "ungültig" gekennzeichnet ist.

Um dieses Problem zu umgehen, muss ich mit der Maus zum Menü "Benutzer wechseln ..." in der Titelleiste wechseln, darauf klicken und warten, bis die andere Anmeldeseite angezeigt wird, die der Seite zum Sperren des Bildschirmschoners sehr ähnlich ist . (Es werden auch andere Benutzernamen aufgelistet, aus denen Sie auswählen können.)

Dort gebe ich das gleiche Passwort ein und es wird akzeptiert, ich bin angemeldet, Unity Desktop erscheint.

Die Anmeldung an der Konsole funktioniert ebenfalls.

Irgendeine Idee, wie man das Problem diagnostiziert und löst?

Linux xxx 3.19.0-28-generic # 30-Ubuntu SMP Mo Aug 31 15:52:51 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

Einheit 7.3.2

Compiz 0.9.12.1

In kern.log und syslog scheint nichts von Interesse zu sein, aber hier ist etwas aus /var/log/auth.log

    Sep 17 17:20:29 xxx lightdm: pam_kwallet(lightdm-greeter:setcred): pam_sm_setcred
Sep 17 17:20:29 xxx lightdm: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Sep 17 17:20:29 xxx systemd-logind[843]: New session c13 of user lightdm.
Sep 17 17:20:29 xxx lightdm: pam_ck_connector(lightdm-greeter:session): nox11 mode, ignoring PAM_TTY :2
Sep 17 17:20:29 xxx lightdm: pam_kwallet(lightdm-greeter:session): pam_sm_open_session
Sep 17 17:20:29 xxx lightdm: pam_kwallet(lightdm-greeter:session): pam_kwallet: open_session called without kwallet_key
Sep 17 17:20:30 xxx lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "knb"
Sep 17 17:20:33 xxx CRON[37168]: pam_unix(cron:session): session closed for user munin
Sep 17 17:21:10 xxx lightdm: pam_kwallet(lightdm:auth): pam_sm_authenticate
Sep 17 17:21:10 xxx lightdm: pam_kwallet(lightdm:setcred): pam_sm_setcred
Sep 17 17:21:10 xxx lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Sep 17 17:21:10 xxx lightdm: pam_kwallet(lightdm-greeter:session): pam_sm_close_session
Sep 17 17:21:10 xxx lightdm: pam_kwallet(lightdm-greeter:setcred): pam_sm_setcred

Hier sind einige Bilder der Bildschirme, die ich durchlaufen muss:

Hier habe ich mein reguläres Passwort erfolglos eingegeben. Es enthält nur ASCII-Zeichen.

Benutzer wechseln ... (Wählen Sie mein eigenes Konto, ich muss nicht zu einem anderen wechseln).

Das funktioniert.

BEARBEITET: kurz vor Ablauf der +150 Kopfgeldfrist

Ich konnte dieses Problem selbst lösen (nachdem ich alle Hinweise und Links befolgt hatte, die in allen ~ 5 Antworten bis jetzt verteilt waren)

Ich musste diese Zeile in der Datei auskommentieren /etc/pam.d/lightdm:

#auth sufficient pam_succeed_if.so user ingroup nopasswdlogin

Ich denke, der Grund war, dass ich mich (vor vielen Monaten, als ich der "einzige" mit physischem Zugriff auf meinen Computer war) der Gruppe hinzugefügt habe, die sich ohne Passwort anmelden und sich nach dem Booten / Neustart automatisch bei lightdn anmelden kann . Dann habe ich dies eines Tages wieder in "Anmeldung nach Neustart erforderlich" geändert, aber aus irgendeinem Grund wurde die vorherige Konfiguration ohne Anmeldung nicht ordnungsgemäß aus allen Konfigurationsdateien entfernt .

Jetzt kann ich mich wieder anmelden :-)

Ein Hinweis zur Prämie / "Einstufung":

Der erste Antwortende war der Lösung am nächsten, indem er etwas sagte wie "Schau dir genau an, was in /etc/pam.d ist". Die Antwort war auch die längste und gründlichste. Allerdings habe ich alle anderen Antworten als wertvoll eingestuft, das ist alles, was ich jetzt tun kann, denke ich.

Theoretisch können Sie den Inhalt von /etc/pam.d durchgehen und mit der Ausgabe von /var/log/auth.log vergleichen, um zu sehen, was los ist.

Falls Sie sich nicht bewusst sind, ist jede Datei in pam.d ein potenzieller Einstiegspunkt, um pam zu fragen, ob Sie Autorität erhalten können. In deinem Fall lightdm. Die Protokolleinträge sind ziemlich selbsterklärend, um herauszufinden, welche Zeilen im Protokoll von welchen Zeilen in der Pam-Datei stammen.

Laut den Dokumenten, die ich gefunden habe, sollten Sie in der Lage sein, Zeilen in pam.d-Dateien 'debug' hinzuzufügen, um zusätzliche Informationen im Protokoll zu erhalten.

In meinem Setup verwende ich kde und kdm und erhalte viele Zeilen mit (kdm: auth), wenn ich meinen Bildschirm sperre und versuche, ihn zu entsperren (mit dem falschen Passwort), aber nichts, wenn er erfolgreich entsperrt wird. Das ist so gut wie kein Vergleich zwischen pam.d / kdm und pam.d / lightdm, was für mich keinen Sinn macht. Vielleicht können Sie also versuchen, Dinge auszutauschen, um zu sehen, ob das Problem im lightdm pam-Modul liegt.

Der einzige andere Gedanke, den ich hatte, ist, ob Ihr Passwort interessante Symbole oder Zeichen enthält. Wenn das lightdm-Sperrbildschirmfeld nicht richtig codiert ist, sendet es möglicherweise nicht das, was Sie eingeben, an das Back-End. Versuchen Sie, Ihr Passwort in etwas Grundlegendes (wie 1234) zu ändern, um zu sehen, ob es funktioniert. Wenn dies der Fall ist (ändern Sie Ihr Passwort natürlich wieder, aber), bedeutet dies wahrscheinlich, dass zumindest an Ihrer Pam-Konfiguration nichts falsch ist.

Es tut uns leid, wenn dies nicht viel hilft, abgesehen davon, dass Sie pam_debug.so zu verschiedenen Pam-Dateien hinzufügen (siehe http://manpages.ubuntu.com/manpages/hardy/man8/pam_debug.8.html ), um zu sehen, was passiert. Ich bin mir nicht sicher, was ich sonst noch vorschlagen soll.

Der Sperrbildschirm führt seine Authentifizierung als regulärer Benutzer aus, während der Benutzerwechsel und der Anmeldebildschirm als Root ausgeführt werden. Root hat spezielle Berechtigungen, die ein normaler Benutzer nicht hat.

Wenn ich dieses Problem gesehen habe, hat sich normalerweise herausgestellt, dass die Berechtigungen für die Datei / etc / shadow geändert wurden. Das sollte ungefähr so ​​aussehen.

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 2202 Jun 23 12:39 /etc/shadow

Wenn die Dauerwellen, der Eigentümer oder die Gruppe falsch sind, ist das genau dort Ihr Problem.

Vielleicht schlagen die Lösungen in der Desktop-Anmeldung fehl, Terminal funktioniert für Sie?

Sie haben die ~ / .Xauthority-Datei entfernt.

Oder hier? /unix/64545/suddenly-i-cant-login-with-correct-password-greeter-tty

Scheint das gleiche Problem zu sein, das Sie haben. Für diesen zweiten Link möchten Sie möglicherweise einfach den letzten Teil der Befehle ausführen und dabei die Bereinigung von apt-get ignorieren : sudo pam-auth-update.

Ihre Antwort (in Ihrer Bearbeitung) hat mein Problem nicht wirklich gelöst, aber die akzeptierte Antwort und Ihre Art, Ihre Antwort in der Bearbeitung zu lösen, haben mich dazu veranlasst, Folgendes zu tun:

• Kommentar der folgenden Zeile

  #auth sufficient pam_succeed_if.so user ingroup nopasswdlogin

• Ändern

  auth requisite pam_nologin.so zu auth requisite pam_permit.so

Randnotiz: Nach dem Ändern dieser Zeilen muss kein Neustart durchgeführt werden. Geben Sie dies einfach in das Terminal ein. Drücken Sie sudo /usr/sbin/pam-auth-updatedann, ohne etwas im Menü zu ändern, enterauf Ihre Tastatur