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.