Impossible de se connecter à l'écran de veille verrouillé, il faut se connecter avec "Changer d'utilisateur .."
J'ai configuré mes écrans de veille pour verrouiller le bureau après un certain temps; et parfois, par exemple lorsque je quitte mon bureau, je préfère verrouiller moi-même l'écran à 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é "invalide".
Pour contourner le problème, je dois utiliser la souris pour aller 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 screensaver-lock . (Il répertorie également les autres noms d'utilisateur à 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 sur comment diagnostiquer et résoudre le problème?
Linux xxx 3.19.0-28-generic # 30-Ubuntu SMP Mon août 31 15:52:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
unité 7.3.2
Compiz 0.9.12.1
Il semble n'y avoir aucun intérêt dans kern.log et syslog, mais voici quelque chose dans /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 images des écrans que je dois traverser:
Ici, j'ai tapé sans succès 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.
ÉDITÉ: 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 tous les conseils et les liens répartis dans les ~ 5 réponses jusqu'à présent)
Je devais 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), j'ai ajouté moi-même au groupe qui peut se connecter sans mot de passe , et connexion automatique à lightdn après le démarrage/redémarrage. Puis un jour, j’ai modifié ce retour en "connexion nécessaire après le redémarrage", mais pour une raison quelconque, le précédent no-login La configuration a été supprimée de manière incorrecte de tous les fichiers de configuration .
Maintenant je peux me reconnecter :-)
Une note sur la prime/"classement":
Le premier intervenant se rapprochait le plus de la solution en disant quelque chose du genre "regarde de près le contenu de /etc/pam.d". La réponse était aussi 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 le moment, je pense.
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.
Au cas où vous ne le sauriez pas, chaque fichier de pam.d est un point d’entrée potentiel pour demander à pam si vous pouvez obtenir une autorisation. Dans votre cas, lightdm. Les entrées du journal sont assez explicites pour déterminer quelles lignes du journal proviennent de quelles lignes du fichier pam.
Selon la documentation que j'ai trouvée, vous devriez pouvoir ajouter un "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 je reçois beaucoup de lignes contenant (kdm: auth) lorsque je verrouille mon écran et que je tente de le déverrouiller (avec un mot de passe incorrect), mais rien lorsqu'il se déverrouille correctement. Il n’ya pratiquement aucune comparaison entre pam.d/kdm et pam.d/lightdm, ce qui n’a aucun sens pour moi. Vous pouvez donc peut-être essayer d’échanger des choses pour voir si le problème se trouve dans le module lightdm pam.
La seule autre chose que je pensais 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 lightdm n'est pas correctement codée, vous risquez de ne pas envoyer ce que vous tapez au serveur. Essayez de changer votre mot de passe en quelque chose de basique (comme 1234) pour voir si cela fonctionne. Si cela fonctionne, alors (changez votre mot de passe de manière évidente, mais) cela signifie probablement que votre configuration de pam est au moins satisfaisante.
Désolé si cela n’aide pas beaucoup, au-delà de l’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.
Lockscreen exécute son authentification en tant qu'utilisateur normal, alors que le changement d'utilisateur et l'écran de connexion s'exécutent en tant que root. La racine a des privilèges spéciaux qu'un utilisateur régulier 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 à quelque chose comme ça.
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 2202 Jun 23 12:39 /etc/shadow
Si les permanentes, le propriétaire ou le groupe ont tort, votre problème est là.
Peut-être que les solutions dans la connexion au bureau échoue, le terminal fonctionne fonctionnera pour vous?
Ils ont supprimé le fichier ~/.Xauthority.
Semble être le même problème que vous rencontrez. Pour ce deuxième lien, vous pouvez essayer d’exécuter simplement la dernière partie des commandes, en ignorant la purge d’apt-get: Sudo pam-auth-update.
Votre réponse (dans votre édition) n'a pas vraiment résolu mon problème, mais la réponse acceptée et votre façon de résoudre la votre dans l'édition m'amènent à faire ce qui suit:
commentant la ligne suivante
#auth sufficient pam_succeed_if.so user ingroup nopasswdloginen changeant
auth requisite pam_nologin.soàauth requisite pam_permit.so
remarque: il n'est pas nécessaire de redémarrer après avoir modifié ces lignes, il suffit de taper ceci dans le terminal: Sudo /usr/sbin/pam-auth-update et ensuite, sans rien changer dans le menu, appuyez sur enter sur votre clavier.