After I lock or put my computer in sleep mode, I go back to kscreenlocker with the login page. When I type my password and press connect, I get a message saying my password was not correct. I have tried pressing the num lock, or caps lock : for both, kscreenlock tells me that it is enabled when it is but I still cannot log in. My assumption is that it might have something to do with the keyboard layout. I am french and am using an AZERTY keyboard. Maybe kscreenlock bring back a QWERTY layout when waking up... It's been a few months now that I have this issue. I was expecting to see it fixed with an update but as this is still going on I though I'd better do a bug report.
> I was expecting to see it fixed with an update but as this is still going on I though I'd better do a bug report. This issue has not been reported yet. In future better directly report the bug, don't wait for "magic" to happen. For this specific issue: check on the bottom left corner which keyboard layout is used. Maybe even try to switch it. There is not much more I can provide as hint. With Plasma 5.9 there will be a new button on the lock screen input field which allows to trigger the clear text. If the issue is not fixed by switching the layout I suggest to wait till 5.9 is available in Arch and then check what is actually typed.
Thanks, I'll be reporting bugs more quickly in the future. I just checked and unfortunately I do not have a selection icon on the lock screen for changing the keyboard layout. I'll wait for Plasma 5.9 then and come back with the results then.
Same here, except my keyboard layout is IE. I had SDDM , and thought that bug was SDDM related, therefore switched to Lightdm. Even after "apt-get purge sddm" I found plenty lefover files.And my lockscreen is still old SDDm theme. But what I do, is start a new session (after failed login), where I get lightdm themed screenlock, then after typing password I'm brought back to old session. Other way is from tty1 issue : loginctl unlock-sessions Its Debian Stretch, amd64, intel graphic. I'm noob , but I wish I could help here, and if any logs would help, please let me know. Thanks
ok, so I manage to find some logs related to this: /var/log/auth.log 9 14:13:12 DebianStretchPC unix_chkpwd[6242]: check pass; user unknown Mar 9 14:13:12 DebianStretchPC unix_chkpwd[6243]: check pass; user unknown Mar 9 14:13:12 DebianStretchPC unix_chkpwd[6243]: password check failed for user (kiesha) Mar 9 14:13:12 DebianStretchPC kcheckpass[6241]: pam_unix(kde:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost= user=kiesha Mar 9 14:13:12 DebianStretchPC kcheckpass[6241]: Authentication failure for kiesha (invoked by uid 1000) Mar 9 14:13:18 DebianStretchPC lightdm: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0) Mar 9 14:13:18 DebianStretchPC systemd-logind[494]: New session c10 of user lightdm. Mar 9 14:13:27 DebianStretchPC lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm Mar 9 14:13:30 DebianStretchPC sudo: kiesha : TTY=pts/1 ; PWD=/home/kiesha ; USER=root ; COMMAND=/usr/bin/tail -n 70 /var/log/auth.log Mar 9 14:13:30 DebianStretchPC sudo: pam_unix(sudo:session): session opened for user root by kiesha(uid=0)
It was my own fault, after messing with /etc/shadow and /etc/gshadow, I had them in a wrong group. chgrp shadow /etc/shadow and /etc/gshadow fixed it.
> I'll wait for Plasma 5.9 then and come back with the results then. any news?
I am currently running KDE 5.9.4. When I try to log in after locking my PC from KDE, I can effectively now see the characters I'm typping thanks to the eye icon. The characters I am typing are effectively the ones entered in the password box. There seems to be no keyboard layout issue. Unfortunately I am still unable to log back into my computer even with the correct password entered in the password text box.
Please try to invoke the application "kcheckpass" directly on the command line. It takes your password and should return 0 if it authenticated you. Please note that kcheckpass is in a weird location. Best check where your distribution installs it to
When I run kcheckpass (in /usr/lib in Arch) from Konsole while logged in I have an "Authentication failure" error message and a return code of 1.
(In reply to nono31393 from comment #9) > When I run kcheckpass (in /usr/lib in Arch) from Konsole while logged in I > have an "Authentication failure" error message and a return code of 1. This means the communication with the auth backends is broken. Have you reconfigured PAM in some way?
No I haven't. Or at least not willingly. I don't remember ever touching anything called PAM. I have however had a few issues a few months ago with SDDM and successively installed and uninstalled other display manager like lightDM. Could that have any effect on PAM ?
I'm confident this is the same bug as #339452, but that one is much older. I can confirm everything that's been reported here. From the log entries: Aug 27 18:32:23 [unix_chkpwd] password check failed for user (foobar) Aug 27 18:32:23 [kcheckpass] pam_unix(kde:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost= user=foobar Aug 27 18:32:23 [kcheckpass] Authentication failure for foobar (invoked by uid 1000) Aug 27 18:32:32 [unix_chkpwd] check pass; user unknown ...right down to the unhelpful "Only binary protocol supported" message when invoking /usr/lib64/libexec/kcheckpass directly from the commandline. My system runs gentoo, no systemd, kde 17.08.0 / plasma 5.10.4 I would be very grateful to hear how I can unlock from commandline when this happens, because for obvious reasons 'loginctl unlock-sessions' doesn't work here (no systemd, hence no loginctl) What logs or tests do you require from me to get more info? utux
Ah! Good news from/for me at least. On my system, somehow /sbin/unix_chkpwd ended up as root:root 0711. I checked on two other systems, they both had root:root 4711. After I changed the rights the screensaver could unlock again. No idea how that file ended up losing its SUID bit but I would suspect that that is more gentoo's fault than that Kde catches any blame for it. If you hit this bug, please check your /sbin/unix_chkpwd mode and ownership and compare it to that of a known-good install for your distro. utux Status: worksforme
I have this issue too. I have a Sabayon 64 bit fully up to date, on an i7 + nVidia GTX 560Ti card with 390.42 driver version and kernel 4.16, KDE Plasma is version 5.49.
This fixed it for me: chmod +s /sbin/unix_chkpwd
sudo chmod +s /sbin/unix_chkpwd fixed it for me too. This bug somehow happened to my computer during a dist-upgrade from Ubuntu 18.04 to 18.10.
I spoke too soon. I left the laptop for a couple hours and it suspended; the keyboard was unresponsive (to KDE) when I returned. Alt sysrq reisub worked, but I couldn't restart X or switch to different TTYs.
*** This bug has been marked as a duplicate of bug 339452 ***