J'ai configuré mes économiseurs d'écran pour verrouiller le bureau après un certain temps; et parfois, par exemple lorsque je quitte mon bureau, je préfère verrouiller l'écran moi-même à l'aide de la fonction "Verrouiller / Changer de compte ..." de la barre de titre.
En essayant de me reconnecter, j'entre mon mot de passe, mais le mot de passe est étiqueté comme "invalide".
Pour contourner ce problème, je dois utiliser la souris pour accéder au menu "Changer d'utilisateur ..." dans la barre de titre, cliquer dessus et attendre que cette autre page de connexion apparaisse, ce qui est assez similaire à la page de verrouillage d'écran. . (Il répertorie également d'autres noms d'utilisateur parmi lesquels choisir)
Là, j'entre le même mot de passe, et il est accepté, je suis connecté, le bureau de l'unité apparaît.
La connexion à la console fonctionne également.
Une idée de comment diagnostiquer et résoudre le problème?
Linux xxx 3.19.0-28-generic # 30-Ubuntu SMP Mon 31 août 15:52:51 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux
unité 7.3.2
Compiz 0.9.12.1
Il ne semble y avoir rien d'intéressant dans kern.log et syslog, mais voici quelque chose de /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
Voici quelques photos des écrans que je dois parcourir:
Ici, j'ai sans succès tapé mon mot de passe habituel. Il ne contient que des caractères ascii.
Changer d'utilisateur ... (choisissez mon propre compte, je n'ai pas besoin de passer à un autre).
Cela marche.
MODIFIÉ: juste avant la fin du délai de prime de +150
J'ai pu résoudre ce problème moi-même (après avoir suivi si toutes les astuces et les liens se sont propagés à travers toutes les ~ 5 réponses jusqu'à présent)
J'ai dû commenter cette ligne dans le fichier /etc/pam.d/lightdm
:
#auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
Je pense que la raison en est que (il y a plusieurs mois, quand j'étais le "seul" avec un accès physique à mon ordinateur), je me suis ajouté au groupe qui peut se connecter sans mot de passe et se connecter automatiquement à lightdn après le démarrage / redémarrage. Puis un jour, j'ai changé cela en "connexion nécessaire après le redémarrage", mais pour une raison quelconque, la configuration sans connexion précédente a été supprimée de manière incorrecte de tous les fichiers de configuration .
Vous pouvez maintenant vous reconnecter :-)
Une note sur la prime / "classement":
Le premier répondeur était le plus proche de la solution en disant quelque chose comme "regardez attentivement ce qui se trouve dans /etc/pam.d". La réponse a également été la plus longue et la plus approfondie. Cependant, j'ai vérifié que toutes les autres réponses étaient utiles, c'est tout ce que je peux faire pour l'instant, je pense.
Réponses:
En théorie, vous pouvez parcourir le contenu de /etc/pam.d et comparer avec la sortie de /var/log/auth.log pour voir ce qui se passe.
Si vous n'êtes pas au courant, chaque fichier dans pam.d est un point d'entrée potentiel pour demander à pam si vous pouvez obtenir l'autorisation. Dans votre cas, lightdm. Les entrées du journal sont assez explicites pour ce qui est de savoir quelles lignes du journal proviennent de quelles lignes du fichier pam.
Selon les documents que j'ai trouvés, vous devriez pouvoir ajouter le «débogage» aux lignes des fichiers pam.d pour obtenir des informations supplémentaires dans le journal.
Dans ma configuration, j'utilise kde et kdm et j'obtiens beaucoup de lignes contenant (kdm: auth) lorsque je verrouille mon écran et tente de le déverrouiller (avec le mauvais mot de passe), mais rien quand il se déverrouille avec succès. Il n'y a pratiquement aucune comparaison entre pam.d / kdm et pam.d / lightdm, ce qui n'a aucun sens pour moi, alors vous pouvez peut-être essayer de permuter les choses pour voir si le problème est dans le module pam lightdm.
La seule autre pensée que j'ai eue est de savoir si vous avez des symboles ou des caractères intéressants dans votre mot de passe. Si la boîte de l'écran de verrouillage de lightdm n'est pas codée correctement, vous pourriez constater qu'elle n'envoie pas ce que vous tapez à l'arrière-plan. Essayez de changer votre mot de passe en quelque chose de basique (comme 1234) pour voir si cela fonctionne, si c'est le cas, puis (changez votre mot de passe évidemment, mais) cela signifie probablement qu'il n'y a rien de mal avec votre configuration pam au moins.
Désolé si cela n'aide pas beaucoup, au-delà de la recherche d'ajout de pam_debug.so à divers fichiers pam (voir http://manpages.ubuntu.com/manpages/hardy/man8/pam_debug.8.html ), pour voir ce qui se passe, Je ne sais pas quoi suggérer d'autre.
la source
L'écran de verrouillage exécute son authentification en tant qu'utilisateur normal, tandis que le changement d'utilisateur et l'écran de connexion s'exécutent en tant que root. Root a des privilèges spéciaux qu'un utilisateur normal n'a pas.
Habituellement, quand j'ai vu ce problème, il s'est avéré que les autorisations sur le fichier / etc / shadow ont été modifiées. Le devrait ressembler à ceci.
Si les perms, le propriétaire ou le groupe sont erronés, c'est votre problème.
la source
-rw-r----- 1 root shadow 1965 Sep 22 08:49 /etc/shadow
... saned:*:15259:0:99999:7::: knb:$6$gUasL0rU$X3J3y/IAu/gKT2Ky2HCGLYigs59CowgYw17/0AK8QMWCsz6NpWDesH.C/....... LatrOQm1l5211gy3Q2pWx.:16702:0:99999:7::: sshd:*:15268:0:99999:7::: postfix:*:15271:0:99999:7: .....
Peut-être que les solutions de connexion au bureau échouent, les travaux de terminal fonctionneront pour vous?
Ils ont supprimé le fichier ~ / .Xauthority.
Ou ici? /unix/64545/suddenly-i-cant-login-with-correct-password-greeter-tty
Semble être le même problème que vous rencontrez. Pour ce second lien, vous pouvez essayer simplement courir la dernière partie des commandes, en ignorant la purge apt-get:
sudo pam-auth-update
.la source
sudo pam-auth-update
- résultat: avertissement + sortie en raison de modifications locales dans/etc/pam.d/
. Il y avait 4/etc/pam.dcommon-*
fichiers. Alors je l'ai faitsudo pam-auth-update --force
. une boîte de dialogue de configuration complexe est apparue, a choisi les valeurs par défaut. il y a maintenant 5 fichiers communs *. Le problème est toujours là.Votre réponse (dans votre modification) n'a pas vraiment résolu mon problème, mais la réponse acceptée et votre façon de résoudre la vôtre dans la modification m'ont amené à faire ce qui suit:
commentant la ligne suivante
#auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
en changeant
auth requisite pam_nologin.so
àauth requisite pam_permit.so
note de côté: pas besoin de redémarrer après avoir changé ces lignes il suffit de taper ceci dans le terminal:
sudo /usr/sbin/pam-auth-update
puis sans rien changer dans le menu, appuyezenter
sur votre clavierla source