SUMMARY The first password attempt is rejected when I resume my system from sleep after it was put to sleep from the lock screen even though my password appears to be correct when I make it visible using the show password function. I am always able to log in on the second attempt. My system is unlocked as expected, i.e. without a rejected attempt, when I put my system to sleep using the application menu launcher's sleep icon or when unlocking without sleeping. STEPS TO REPRODUCE 1. Wait for screen to lock automatically after a period of inactivity or lock with Meta-L key combination 2. Put system to sleep using the Sleep icon on the lock screen 3. Wake system and enter correct password to unlock OBSERVED RESULT My password is rejected the first time it is entered, the login screen shakes and an 'Unlocking failed' message is shown. I am able to login only when I enter my password a second time. EXPECTED RESULT The desktop should be unlocked the first time a correct password is entered. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 40 - 6.9.10-200.fc40.x86_64 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION I think this may have started when I upgraded my system from Fedora 39 to Fedora 40, but my journal logs only go back 3 months so I can't be sure, the oldest record from journalctl output I can find is from shortly after I upgraded: May 01 06:32:09 Just4pLeisure kscreenlocker_greet[276611]: pam_unix(kde:auth): unexpected response from failed conversation function May 01 06:32:09 Just4pLeisure kscreenlocker_greet[276611]: pam_unix(kde:auth): conversation failed May 01 06:32:09 Just4pLeisure kscreenlocker_greet[276611]: pam_unix(kde:auth): auth could not identify password for [sophie] The issue persists to this day despite numerous updates to Plasma, Frameworks and Qt: Jul 27 17:39:35 Just4pLeisure kscreenlocker_greet[21299]: pam_unix(kde:auth): unexpected response from failed conversation function Jul 27 17:39:35 Just4pLeisure kscreenlocker_greet[21299]: pam_unix(kde:auth): conversation failed Jul 27 17:39:35 Just4pLeisure kscreenlocker_greet[21299]: pam_unix(kde:auth): auth could not identify password for [sophie] Lee Head has submitted a complete journalctl log here :https://github.com/sddm/sddm/issues/1941#issuecomment-2156369683 Fabian Vogt (Vogtinator) suspects sleeping from the lock screen somehow triggers a broken PAM conversation: https://github.com/sddm/sddm/issues/1941#issuecomment-2254224974 I can supply log files as required and would love to try to debug this, although I may need a bit of guidance...
> Fabian Vogt (Vogtinator) suspects sleeping from the lock screen somehow triggers a broken PAM conversation: https://github.com/sddm/sddm/issues/1941#issuecomment-2254224974 The difference is that for me unlocking after waking up works fine despite the broken PAM conversation. If the broken PAM conversation is the cause, this should avoid it: diff --git a/greeter/greeterapp.cpp b/greeter/greeterapp.cpp index eb088cc..6c016cb 100644 --- a/greeter/greeterapp.cpp +++ b/greeter/greeterapp.cpp @@ -527,7 +527,6 @@ void UnlockApp::suspendToRam() m_ignoreRequests = true; m_resetRequestIgnoreTimer->start(); - m_authenticators->cancel(); PowerManagement::instance()->suspend(); } Probably not a proper fix though, at least the noninteractive authenticators running in the background should probably be stopped before suspending. Currently that's not guaranteed either though, it's all async.
Can confirm
(In reply to Fabian Vogt from comment #1) > If the broken PAM conversation is the cause, this should avoid it: > > diff --git a/greeter/greeterapp.cpp b/greeter/greeterapp.cpp > index eb088cc..6c016cb 100644 > --- a/greeter/greeterapp.cpp > +++ b/greeter/greeterapp.cpp > @@ -527,7 +527,6 @@ void UnlockApp::suspendToRam() > > m_ignoreRequests = true; > m_resetRequestIgnoreTimer->start(); > - m_authenticators->cancel(); > > PowerManagement::instance()->suspend(); > } Thank you Fabian, I have compiled kscreenlocker_greet with your patch and it resolves the rejected password issue for me :-) > Probably not a proper fix though, at least the noninteractive authenticators > running in the background should probably be stopped before suspending. > Currently that's not guaranteed either though, it's all async. I understand at a very abstract level why you are concerned that this is a rough workaround but don't understand in any of the detail. With enough the time I'd love to learn one day as I've raised a few bug reports now and have graduated to the level of 'can compile with supplied patches' :-D. Until I achieve my next badge (or 3) I'll have to leave a proper, or at least acceptable, fix to you as professionals. In the mean time I'll watch this bug report and test any developments too.
(In reply to Sophie Dexter from comment #3) > (In reply to Fabian Vogt from comment #1) > > If the broken PAM conversation is the cause, this should avoid it: > > > > diff --git a/greeter/greeterapp.cpp b/greeter/greeterapp.cpp > > index eb088cc..6c016cb 100644 > > --- a/greeter/greeterapp.cpp > > +++ b/greeter/greeterapp.cpp > > @@ -527,7 +527,6 @@ void UnlockApp::suspendToRam() > > > > m_ignoreRequests = true; > > m_resetRequestIgnoreTimer->start(); > > - m_authenticators->cancel(); > > > > PowerManagement::instance()->suspend(); > > } > Thank you Fabian, I have compiled kscreenlocker_greet with your patch and it > resolves the rejected password issue for me :-) Great! Without this patch it should just start another PAM session after waking up, when the UI becomes visible again. For some reason that does not work. Maybe it's some kind of rate limit that gets tripped even beyond suspend/release. In that case it would make sense to stop only the noninteractive authenticators. Not sure how to find out though. Another option could be that the authenticator isn't actually started properly again after wakeup, as there is no fitting error message in the log. It would be useful if you could run QT_LOGGING_RULES=kscreenlocker_greet.debug=true /usr/libexec/kscreenlocker_greet --testing -platform xcb and reproduce the issue. It's possible that the log contains some sensitive information, so please read through it before uploading. > > Probably not a proper fix though, at least the noninteractive authenticators > > running in the background should probably be stopped before suspending. > > Currently that's not guaranteed either though, it's all async. > I understand at a very abstract level why you are concerned that this is a > rough workaround but don't understand in any of the detail. I don't know all details either - PAM is complex and very temperamental. > With enough the > time I'd love to learn one day as I've raised a few bug reports now and have > graduated to the level of 'can compile with supplied patches' :-D. Until I > achieve my next badge (or 3) I'll have to leave a proper, or at least > acceptable, fix to you as professionals. In the mean time I'll watch this > bug report and test any developments too.
(In reply to Fabian Vogt from comment #4) > It would be useful if you could run > > QT_LOGGING_RULES=kscreenlocker_greet.debug=true > /usr/libexec/kscreenlocker_greet --testing -platform xcb > > and reproduce the issue. Hmm, running that is proving to be tricky since this only occurs immediately after waking my system from sleep and I don't know how to do what you ask. I've tried running from a different TTY but I am greeted with: >> kscreenlocker_greet: Greeter is starting up. >> qt.qpa.xcb: could not connect to display >> qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin. >> qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. >> This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. >> >> Available platform plugins are: wayland-egl, wayland, eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, xcb. Exporting DISPLAY=0 beforehand doesn't help. Thinking perhaps this is due to Fedora 40 being Wayland only I then tried wayland and wayland-egl instead of xcb. For reference, this is the output from running with --testing -platform wayland-egl (output is similar with -platform wayland option): >> kscreenlocker_greet: Greeter is starting up. >> qt.qpa.wayland: qtvirtualkeyboard currently is not supported at client-side, use QT_IM_MODULE=qtvirtualkeyboard at compositor-side. >> kscreenlocker_greet: [PAM worker kde-smartcard] start: successfully started >> kscreenlocker_greet: Greeter is running in testing mode >> kscreenlocker_greet: Testing mode enabled: true >> kscreenlocker_greet: [PAM worker kde] start: successfully started >> kscreenlocker_greet: [PAM worker kde-fingerprint] start: successfully started >> kf.guiaddons: No modifierkeyinfo backend for platform "wayland-egl" >> org.kde.plasma.keyboardindicator: Unknown key Qt::Key_CapsLock >> kf.guiaddons: No modifierkeyinfo backend for platform "wayland-egl" >> org.kde.plasma.keyboardindicator: Unknown key Qt::Key_CapsLock >> kf.guiaddons: No modifierkeyinfo backend for platform "wayland-egl" >> org.kde.plasma.keyboardindicator: Unknown key Qt::Key_CapsLock >> Locked at 1722345401 >> kscreenlocker_greet: PamAuthenticators: starting authenticators >> kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating >> kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Starting authentication >> kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication >> kscreenlocker_greet: [PAM worker kde-smartcard] Message: Info message: auth=authinfo_unavail >> kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Starting authentication >> kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info) >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard true >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint true >> kscreenlocker_greet: PamAuthenticators: Info message from non-interactive authenticator kde-smartcard >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false >> kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: >> kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response >> kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde >> kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info) >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false >> kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator >> kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop >> kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business >> kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 0 (Success) >> kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business >> kscreenlocker_greet: PamAuthenticators: Success from interactive authenticator kde >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked Unfortunately though the 'kscreenlocker_greet --testing...' instance is only visible after I've unlocked my system and my first password attempt is rejected when actually unlocking. This is even though I run kscreenlocker --tesiting from a different, text only, TTY after waking my system. Because of this I haven't been able to reproduce so far with 'kscreenlocker_greet --testing...' as I only see the broken conversation reports etc. after waking my system from sleep, but I cannot run the test until I've unlocked - a chicken and egg conundrum I am yet to crack... I suspect I've missed something obvious and there is a way to run this immediately after waking my system from sleep to test kscreenlocker but I cannot fathom what, is there a way to simulate system sleeping and/or make the PAM conversation fail instead?
(In reply to Sophie Dexter from comment #5) > (In reply to Fabian Vogt from comment #4) > > It would be useful if you could run > > > > QT_LOGGING_RULES=kscreenlocker_greet.debug=true > > /usr/libexec/kscreenlocker_greet --testing -platform xcb > > > > and reproduce the issue. > > Hmm, running that is proving to be tricky since this only occurs immediately > after waking my system from sleep and I don't know how to do what you ask. > I've tried running from a different TTY but I am greeted with: You should be able to run the command and try the sleep button. > ... > I suspect I've missed something obvious and there is a way to run this > immediately after waking my system from sleep to test kscreenlocker but I > cannot fathom what, is there a way to simulate system sleeping and/or make > the PAM conversation fail instead? It's also possible to "fake" the suspend by removing the call to PowerManagement::instance()->suspend(); instead of m_authenticators->cancel();
(In reply to Fabian Vogt from comment #6) > You should be able to run the command and try the sleep button. Ha! That was _embarassingly_ obvious :o) Unfortunately it wasn't much help however. I se the testing lockscreen on waking my system which accepted my password first time, followed by the 'real' lockscreen which rejected my password before accepting... Qt logging messages were similar to before. But faking suspend with > It's also possible to "fake" the suspend by removing the call to > PowerManagement::instance()->suspend(); instead of > m_authenticators->cancel(); shows more promise and I see my password being rejected with lockscreen testing. I've tried to annotate logged output, three messages in particular seem to indicate trouble: >> kscreenlocker_greet: Greeter is starting up. >> kscreenlocker_greet: [PAM worker kde-smartcard] start: successfully started >> kscreenlocker_greet: Greeter is running in testing mode >> kscreenlocker_greet: Testing mode enabled: true >> kscreenlocker_greet: [PAM worker kde-fingerprint] start: successfully started >> kscreenlocker_greet: [PAM worker kde] start: successfully started >> Locked at 1722370491 >> kscreenlocker_greet: PamAuthenticators: starting authenticators >> kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating >> kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication >> kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Starting authentication >> kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Starting authentication >> kscreenlocker_greet: [PAM worker kde-smartcard] Message: Info message: auth=authinfo_unavail >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint true >> kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info) >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard true >> kscreenlocker_greet: PamAuthenticators: Info message from non-interactive authenticator kde-smartcard >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false >> kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info) >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false >> kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false This relates to Password box before pressing (faked) sleep icon >> kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: >> kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response >> kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde These three messages could be telling >> kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator >> kscreenlocker_greet: [PAM worker kde] Received cancellation, exiting with PAM_CONV_ERR >> kscreenlocker_greet: [PAM worker kde] Nested event loop's exit code was not zero, bailing This relates to the failing first password attempt after (faked) resume >> kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: >> kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response >> kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde >> kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator >> kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop >> kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business >> kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 7 (Authentication failure) >> kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business >> kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde >> kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Authenticating to PamAuthenticators::Idle >> kscreenlocker_greet: PamAuthenticators: starting authenticators >> kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating >> kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication This relates to the 2nd password attempt which succeeds >> kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: >> kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response >> kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde >> kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator >> kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop >> kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business >> kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 0 (Success) >> kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business >> kscreenlocker_greet: PamAuthenticators: Success from interactive authenticator kde >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked >> Unlocked
Ok, that confirms it's indeed the PAM module refusing to authenticate. Question is why. You could try creating /etc/pam_debug or adding debug to the pam_unix line in the kde pam module. Not sure where the debug output ends up though, might be in the journal or somewhere in /var/log/...
Created attachment 172221 [details] Messages reported by 'kscreenlocker_greet -testing'
Created attachment 172222 [details] PAM debug messages during kscreenlocker_greet --testing
(In reply to Fabian Vogt from comment #8) > Ok, that confirms it's indeed the PAM module refusing to authenticate. > Question is why. > > You could try creating /etc/pam_debug or adding debug to the pam_unix line > in the kde pam module. Not sure where the debug output ends up though, might > be in the journal or somewhere in /var/log/... It took all of the above and a bit more, combining information from these two sources, debug messages appear in /var/log/debug.log (maybe not everything is needed): https://www.ibm.com/docs/en/aix/7.3?topic=modules-enabling-pam-debug https://help.duo.com/s/article/5095?language=en_US /etc/pam.d/kde file doesn't include an entry for pam_unix.so but references password-auth which has multiple entries and I added 'debug' to each entry. Unfortunately I don't really know how to decipher these dubug messages :-(
(In reply to Sophie Dexter from comment #11) > (In reply to Fabian Vogt from comment #8) > > Ok, that confirms it's indeed the PAM module refusing to authenticate. > > Question is why. > > > > You could try creating /etc/pam_debug or adding debug to the pam_unix line > > in the kde pam module. Not sure where the debug output ends up though, might > > be in the journal or somewhere in /var/log/... > It took all of the above and a bit more, combining information from these > two sources, debug messages appear in /var/log/debug.log (maybe not > everything is needed): > https://www.ibm.com/docs/en/aix/7.3?topic=modules-enabling-pam-debug > https://help.duo.com/s/article/5095?language=en_US > > /etc/pam.d/kde file doesn't include an entry for pam_unix.so but references > password-auth which has multiple entries and I added 'debug' to each entry. > > Unfortunately I don't really know how to decipher these dubug messages :-( I don't see any new info in either of those logs unfortunately. What's the full content of both kde and password-auth PAM configs?
Created attachment 172304 [details] /etc/pam.d/kde file
Created attachment 172305 [details] /etc/authselect/password-auth - sssd version
Created attachment 172306 [details] /etc/authselect/password-auth - local version
(In reply to Fabian Vogt from comment #12) > I don't see any new info in either of those logs unfortunately. What's the > full content of both kde and password-auth PAM configs? Files in attachments with 2 versions of 'password-auth' file, one for the 'sssd' profile, the other for the 'local' profile. I read Fedora Magazine's article on Fedora 40 migrating to the new 'local' profile and noticed the default local profile does not include fingerprint readers which piqued my interest since the logs mention both fingerprint and smartcard readers, but I don't have either. Long story short, I switched to authselect's local profile and the problem almost goes away... With the local profile I see the locks screen shake when I press the sleep button and my system then sleeps without any further action on my part. My password is accepted at the first attempt when I wake my system as it should be. I do however still see broken PAM conversation errors in journalctl indicating this is not a true fix. If you are using authselect's local profile it may explain why you haven't noticed your password being rejected. I'd still like to track down the cause and help fix whatever the issue is :-)
(In reply to Sophie Dexter from comment #16) Just to add, fingerprint readers do not seem to be the issue since en/disabling their use through authselect makes no difference
(In reply to Sophie Dexter from comment #16) > (In reply to Fabian Vogt from comment #12) > > I don't see any new info in either of those logs unfortunately. What's the > > full content of both kde and password-auth PAM configs? > > Files in attachments with 2 versions of 'password-auth' file, one for the > 'sssd' profile, the other for the 'local' profile. > > I read Fedora Magazine's article on Fedora 40 migrating to the new 'local' > profile and noticed the default local profile does not include fingerprint > readers which piqued my interest since the logs mention both fingerprint and > smartcard readers, but I don't have either. > > Long story short, I switched to authselect's local profile and the problem > almost goes away... With the local profile I see the locks screen shake when > I press the sleep button and my system then sleeps without any further > action on my part. My password is accepted at the first attempt when I wake > my system as it should be. Perfect! That means the cause is most likely pam_sss. > I do however still see broken PAM conversation errors in journalctl > indicating this is not a true fix. That's expected, the code sends PAM_CONV_ERR when suspending. That's what the diff in comment #1 commented out. > If you are using authselect's local > profile it may explain why you haven't noticed your password being rejected. > > I'd still like to track down the cause and help fix whatever the issue is :-) Me too. Can you please try this (with the working local config as base): "auth sufficient pam_sss.so forward_pass" after pam_unix (this should bring the issue back) and then "auth sufficient pam_sss.so use_first_pass" instead? I wonder whether that avoids the issue as well. Please keep a local root shell open when editing PAM config. If this works, the PAM_CONV_ERR return does not fully quit the PAM stack and it just gets stuck at pam_sss. The fix would be to return PAM_CONV_ERR until pam_authenticate returns failure.
(In reply to Fabian Vogt from comment #18) > Can you please try this (with the working local config as base): > > "auth sufficient pam_sss.so > forward_pass" > > after pam_unix (this should bring the issue back) and then Yes it did! > > "auth sufficient pam_sss.so > use_first_pass" > > instead? I wonder whether that avoids the issue as well. Please keep a local > root shell open when editing PAM config. and, yes it did :-) I used 'sudo vi /etc/authselect/password-auth' when editing, unsure what I was supposed to do/see with the root shell though,? > If this works, the PAM_CONV_ERR return does not fully quit the PAM stack and > it just gets stuck at pam_sss. > The fix would be to return PAM_CONV_ERR until pam_authenticate returns > failure. Great!, umm, how :?:
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
(In reply to Sophie Dexter from comment #19) > (In reply to Fabian Vogt from comment #18) > > Can you please try this (with the working local config as base): > > > > "auth sufficient pam_sss.so > > forward_pass" > > > > after pam_unix (this should bring the issue back) and then > Yes it did! > > > > "auth sufficient pam_sss.so > > use_first_pass" > > > > instead? I wonder whether that avoids the issue as well. Please keep a local > > root shell open when editing PAM config. > and, yes it did :-) > I used 'sudo vi /etc/authselect/password-auth' when editing, unsure what I > was supposed to do/see with the root shell though,? The (extra) open root shell would have enabled you to use it to fix the PAM configuration in case you made a mistake, making you unable to login. > > If this works, the PAM_CONV_ERR return does not fully quit the PAM stack and > > it just gets stuck at pam_sss. > > The fix would be to return PAM_CONV_ERR until pam_authenticate returns > > failure. > Great!, umm, how :?: I don't think that's for you or me to fix: this PAM config change fixed the issue for me as well (it's probably not the right fix, but it works for now), and I don't see what more info you can give.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/240
(In reply to Sophie Dexter from comment #19) > (In reply to Fabian Vogt from comment #18) > > Can you please try this (with the working local config as base): > > > > "auth sufficient pam_sss.so > > forward_pass" > > > > after pam_unix (this should bring the issue back) and then > Yes it did! > > > > "auth sufficient pam_sss.so > > use_first_pass" > > > > instead? I wonder whether that avoids the issue as well. Please keep a local > > root shell open when editing PAM config. > and, yes it did :-) > I used 'sudo vi /etc/authselect/password-auth' when editing, unsure what I > was supposed to do/see with the root shell though,? > > If this works, the PAM_CONV_ERR return does not fully quit the PAM stack and > > it just gets stuck at pam_sss. > > The fix would be to return PAM_CONV_ERR until pam_authenticate returns > > failure. > Great!, umm, how :?: Like this: https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/240 Can you please check whether this MR fixes the issue for you? (In reply to Rob Sterenborg from comment #21) > (In reply to Sophie Dexter from comment #19) > > (In reply to Fabian Vogt from comment #18) > > > instead? I wonder whether that avoids the issue as well. Please keep a local > > > root shell open when editing PAM config. > > and, yes it did :-) > > I used 'sudo vi /etc/authselect/password-auth' when editing, unsure what I > > was supposed to do/see with the root shell though,? > > The (extra) open root shell would have enabled you to use it to fix the PAM > configuration in case you made a mistake, making you unable to login. Exactly that! password-auth is likely used by all authentication methods (tty + graphical login, ssh), so if there's a typo or other issue you'd lock yourself out of your system.
(In reply to Fabian Vogt from comment #23) > (In reply to Sophie Dexter from comment #19) > > (In reply to Fabian Vogt from comment #18) > > > I used 'sudo vi /etc/authselect/password-auth' when editing, unsure what I > > > was supposed to do/see with the root shell though,? > > > > The (extra) open root shell would have enabled you to use it to fix the PAM > > configuration in case you made a mistake, making you unable to login. > > Exactly that! password-auth is likely used by all authentication methods > (tty + graphical login, ssh), so if there's a typo or other issue you'd lock > yourself out of your system. Understood! - I did have a TTY3 session logged in with my normal user account but I now realise that may not have been enough if I needed root access but had 'broken' my PAM configuration. Thank you both for explaining :-) (In reply to Fabian Vogt from comment #23) > (In reply to Sophie Dexter from comment #19) > > (In reply to Fabian Vogt from comment #18) > > > The fix would be to return PAM_CONV_ERR until pam_authenticate returns > > > failure. > > Great!, umm, how :?: > > Like this: https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/240 > Can you please check whether this MR fixes the issue for you? > Unfortunately not really, but behaviour is different: The lock screen almost works with authselect 'local' profile with the peculiarity that the lock screen shakes and informs 'Unlocking Failed' then sleeps after that message's timeout expires. However, with authselect's 'sssd' profile I have to press the sleep button twice before my system will sleep. I see the screen shake and an 'Unlocking Failed' message each time I press sleep. The better news is that unlocking works at the first attempt with either profile. the plot thickens...
(In reply to Sophie Dexter from comment #24) > However, with authselect's 'sssd' profile I have to press the sleep button > twice before my system will sleep. I see the screen shake and an 'Unlocking > Failed' message each time I press sleep. > Update - behaviour with authselect's sssd profile is variable - I initially thought that I had to press the sleep button twice but I was impatient as my system does always seem to sleep after the first press sometimes immediately after the lockscreen shakes and protests 'Unlocking Failed' but sometimes not for a few 10s of seconds if I wait...
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
I still encounter this one on Fedora 42 KDE Edition (Plasma 6.4.4, Frameworks 6.17.0, Qt 6.9.1). I'm assuming its the same issue since the symptoms are the exact same and I'm also on Fedora (same as OP). It doesn't seem like the bug was fixed and I'm able to reproduce with the given steps, so I'm going to re-open this.
Confirming on several different machines on Plasma 6.4.5 on Fedora 42
(In reply to Alex from comment #28) > I still encounter this one on Fedora 42 KDE Edition (Plasma 6.4.4, > Frameworks 6.17.0, Qt 6.9.1). I'm assuming its the same issue since the > symptoms are the exact same and I'm also on Fedora (same as OP). > > It doesn't seem like the bug was fixed and I'm able to reproduce with the > given steps, so I'm going to re-open this. I have several F42 KDE Edition installs. Currently, none of them exhibit this problem which I too experienced in the past, and is what led me to this bug. I still don't know exactly why it happened, and why it doesn't happen with the installs that I currently have. This is annoying, because it means it can start happening again at any time.
I am also encountering this error. I am able to reproduce it with the steps posted by Sophie, as well as whenever my computer sleeps by any other method. Operating System: Fedora Linux 43 KDE Plasma Version: 6.5.3 KDE Frameworks Version: 6.20.0 Qt Version: 6.10.1 Kernel Version: 6.17.8-300.fc43.x86_64 (64-bit) Graphics Platform: Wayland
Can reproduce with: Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.9.3 In my case it manifested in a way that whenever I exit suspend initiated by closing the laptop lid (never checked with other means of entering suspend), I immediately get a shaking screen and a "Login failed" message even without pressing anything. I read through this discussion, and it seems like the issue is in interaction between KScreenLocker, PAM and SSSD. Since I don't use SSSD at all, I just removed all the SSSD-related packages from the system, and I don't observe the issue any more.
I can confirm this bug as well. Drives me up the wall, since I thought I was always mistyping it somehow. But it’s not me!! I used the macro function of my keyboard to verify that it’s definitely not a mistyped password. And it’s shocking that this still exists after 1.5 years, given how angering this is. Operating System: Gentoo GNU/Linux 2026-02-12 KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.18.8-gentoo-dist (64-bit) Graphics Platform: X11 21.1.21 PAM Version: 1.7.2
Still an issue in 6.7.0 : Let your screen go to sleep, type in password, first entry rejected. : Operating System: EndeavourOS KDE Plasma Version: 6.7.0 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 Kernel Version: 7.0.12-arch1-1 (64-bit) Graphics Platform: Wayland
I hit this issue (or at least a related issue) on Arch with a plain pam_unix stack (no SSSD, no fingerprint/smartcard hardware). The visible symptom on my end is the lock screen showing a failed attempt on wake, without me ever having typed anything. But as far as I can tell its the same root cause event from here: m_authenticator->cancel() on suspend leading to a PAM_CONV_ERR. It looks like pre-6.7, this could only happen when you hit the sleep/suspend button on the lock screen, sending the cancel. But as of the 6.7.0 release (specifically 9e622c8676fa), some of the "suspend from lid close" logic was merged into the same sleep/suspend button logic, so closing the lid while the password prompt is up sends the PAM cancel, which gets mis-classified as a failed password attempt, causing the failed login attempt and delay before another password attempt. This, I believe, makes this bad behavior *much* more common; on some laptops just being jostled around can cause lid open and close events in rapid succession, triggering the bug on the first real wake. MR 240 doesn't appear to actually fix the issue, because in my case PAM_CONV_ERR *is* already being returned, but the problem is that it doesn't get handled any differently than a password failure, hence the password failure. The fix should be to add a special path for cancelled authentication attempts as opposed to failed ones.
Here's the MR that fixes it for me, I think it'll fix it for everyone else on here? Basically just makes it so sleeping the computer while on the lock screen doesn't send a "cancel auth" message, which gets misinterpreted as an "auth failed" message, and instead just leaves the auth attempt open for when it wakes up. https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/340
On Fedora 44 + Plasma 6.7.2 + Wayland, after resume from suspend, Unlocking failed is shown automatically before any keyboard or mouse input. The journal contains pam_unix(kde:auth): conversation failed and auth could not identify password. This happens every time. My computer is Lenovo Thinkbook 14+ 2025 Ultra9-285H.
(In reply to walnut from comment #37) > On Fedora 44 + Plasma 6.7.2 + Wayland, after resume from suspend, Unlocking > failed is shown automatically before any keyboard or mouse input. The > journal contains pam_unix(kde:auth): conversation failed and auth could not > identify password. This happens every time. My computer is Lenovo Thinkbook > 14+ 2025 Ultra9-285H. Same, on Gentoo (OpenRC) / plasma-6.7.2 / Wayland session. "Unlocking failed", earthquake and timeout, immediately when screen activates after sleep. Thinkpad X270. Homedir on LUKS mounted using pam_mount, all other pam config as distro defaults. Will see about some debug output when I have a bit of time to do so.
Can confirm the same with EndeavourOS, and can confirm my fingerprint reader was configured prior to updating KDE. Operating System: EndeavourOS KDE Plasma Version: 6.7.3 KDE Frameworks Version: 6.28.0 Qt Version: 6.11.1 Kernel Version: 6.18.38-3-lts (64-bit) Graphics Platform: Wayland System Version: ThinkPad L13 Yoga Gen 4
*** This bug has been marked as a duplicate of bug 481808 ***
## Summary I am experiencing what appears to be the same KScreenLocker/PAM suspend-resume issue described in this bug. When my system is locked and then suspended, KScreenLocker reports a failed authentication immediately after resume, even though I have not entered my password at all. The lock screen shakes and displays **"Unlocking failed"** automatically. ### Steps to reproduce 1. Lock the system using `Meta+L`. 2. Leave the system locked until it goes to sleep/suspend automatically. 3. Wake the system using the power button on the keyboard. 4. Observe the lock screen before entering any password. ### Observed behavior Immediately after waking: * The lock screen shakes as if an incorrect password was entered. * **"Unlocking failed"** is displayed. * No password has been entered. * After this automatic failure, entering the correct password works normally. I can also reproduce the issue when using the **Sleep** button directly from the lock screen. ### Expected behavior After resuming from suspend, the lock screen should simply wait for my password. It should not report a failed authentication when no authentication attempt was made. ### System information * Fedora Linux 44 * KDE Plasma 6.7.4 * KDE Frameworks: [please add output] * KScreenLocker: `6.7.4-1.fc44` * Qt: [please add output] * Kernel: [please add output] * Graphics platform: Wayland * PAM: `1.7.2-2.fc44` * Architecture: x86_64 ### Additional information This is not simply an incorrect-password issue. The failure occurs automatically immediately after resume, before I enter anything. If I lock the system and unlock it without suspending, the password is accepted normally. The problem is specifically associated with suspend/resume while the system is locked. I found an existing KDE bug discussing very similar behavior, including `PAM_CONV_ERR` and cancellation of the PAM authentication conversation when suspending from the lock screen. The discussion also references MR 340 as a possible fix. I am reporting this because the issue still appears to be reproducible on Fedora 44 with KScreenLocker 6.7.4.