490924 2024-07-28 13:30:44 +0000 The first password attempt is rejected after system wakes from sleep. 2026-08-10 17:52:31 +0000 1 1 10 Unmaintained kscreenlocker general unspecified Fedora RPMs Linux RESOLVED DUPLICATE 481808 https://github.com/sddm/sddm/issues/1941 NOR normal --- 1 sophie.dexter74 plasma-bugs-null alberto_bugzilla alex.sanchezstern alex765 brokencanoe fabian firecatdan+kde germano.massullo kde.bugs kde kde mihirmishra nate navid.zamani+kde olib141 pepko94 qwertyuiop8350 sam sergeyprotserovca xaver.hugl 0 oldest_to_newest 2340779 0 sophie.dexter74 2024-07-28 13:30:44 +0000 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... 2340920 1 fabian 2024-07-29 07:47:47 +0000 > 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. 2340985 2 xaver.hugl 2024-07-29 13:30:42 +0000 Can confirm 2341052 3 sophie.dexter74 2024-07-29 16:35:58 +0000 (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. 2341073 4 fabian 2024-07-29 17:41:55 +0000 (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. 2341317 5 sophie.dexter74 2024-07-30 14:15:36 +0000 (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? 2341335 6 fabian 2024-07-30 15:44:34 +0000 (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(); 2341490 7 sophie.dexter74 2024-07-30 22:10:47 +0000 (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 2341560 8 fabian 2024-07-31 07:39:16 +0000 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/... 2342553 9 172221 sophie.dexter74 2024-08-02 16:40:25 +0000 Created attachment 172221 Messages reported by 'kscreenlocker_greet -testing' 2342554 10 172222 sophie.dexter74 2024-08-02 16:41:36 +0000 Created attachment 172222 PAM debug messages during kscreenlocker_greet --testing 2342556 11 sophie.dexter74 2024-08-02 16:43:06 +0000 (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 :-( 2343013 12 fabian 2024-08-04 18:28:40 +0000 (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? 2343166 13 172304 sophie.dexter74 2024-08-05 13:42:31 +0000 Created attachment 172304 /etc/pam.d/kde file 2343167 14 172305 sophie.dexter74 2024-08-05 13:44:12 +0000 Created attachment 172305 /etc/authselect/password-auth - sssd version 2343168 15 172306 sophie.dexter74 2024-08-05 13:45:28 +0000 Created attachment 172306 /etc/authselect/password-auth - local version 2343175 16 sophie.dexter74 2024-08-05 14:03:07 +0000 (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 :-) 2343176 17 sophie.dexter74 2024-08-05 14:05:43 +0000 (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 2343241 18 fabian 2024-08-05 17:37:26 +0000 (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. 2343387 19 sophie.dexter74 2024-08-05 21:39:50 +0000 (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 :?: 2346938 20 bug-janitor 2024-08-20 03:47:31 +0000 🐛🧹 ⚠️ 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! 2346957 21 kde 2024-08-20 06:01:26 +0000 (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. 2348481 22 bug-janitor 2024-08-25 09:38:28 +0000 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/240 2348482 23 fabian 2024-08-25 09:41:38 +0000 (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. 2348645 24 sophie.dexter74 2024-08-25 21:26:09 +0000 (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... 2348749 25 sophie.dexter74 2024-08-26 09:02:11 +0000 (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... 2352698 26 bug-janitor 2024-09-10 03:46:57 +0000 🐛🧹 ⚠️ 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! 2359630 27 bug-janitor 2024-09-25 03:47:14 +0000 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. 2453703 28 alex765 2025-09-10 09:47:13 +0000 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. 2460397 29 germano.massullo 2025-10-08 13:38:02 +0000 Confirming on several different machines on Plasma 6.4.5 on Fedora 42 2460877 30 kde 2025-10-10 09:24:19 +0000 (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. 2473695 31 tgreen894 2025-11-30 17:03:01 +0000 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 2478750 32 sergeyprotserovca 2025-12-22 15:51:40 +0000 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. 2495747 33 navid.zamani+kde 2026-02-18 13:26:23 +0000 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 2524843 34 brokencanoe 2026-06-19 19:35:23 +0000 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 2528514 35 alex.sanchezstern 2026-06-30 23:54:31 +0000 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. 2528939 36 alex.sanchezstern 2026-07-02 21:51:14 +0000 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 2530194 37 qwertyuiop8350 2026-07-08 16:53:47 +0000 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. 2531523 38 kde.bugs 2026-07-14 08:52:36 +0000 (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. 2532535 39 firecatdan+kde 2026-07-17 21:27:36 +0000 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 2533239 40 olib141 2026-07-21 10:38:01 +0000 *** This bug has been marked as a duplicate of bug 481808 *** 2537936 41 mihirmishra 2026-08-10 17:52:31 +0000 ## 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. 172221 2024-08-02 16:40:25 +0000 2024-08-02 16:40:25 +0000 Messages reported by 'kscreenlocker_greet -testing' kscreenlocker_test.log text/plain 4543 sophie.dexter74 a3NjcmVlbmxvY2tlcl9ncmVldDogR3JlZXRlciBpcyBzdGFydGluZyB1cC4Ka3NjcmVlbmxvY2tl cl9ncmVldDogW1BBTSB3b3JrZXIga2RlLWZpbmdlcnByaW50XSBzdGFydDogc3VjY2Vzc2Z1bGx5 IHN0YXJ0ZWQKa3NjcmVlbmxvY2tlcl9ncmVldDogR3JlZXRlciBpcyBydW5uaW5nIGluIHRlc3Rp bmcgbW9kZQprc2NyZWVubG9ja2VyX2dyZWV0OiBUZXN0aW5nIG1vZGUgZW5hYmxlZDogdHJ1ZQpr c2NyZWVubG9ja2VyX2dyZWV0OiBbUEFNIHdvcmtlciBrZGUtc21hcnRjYXJkXSBzdGFydDogc3Vj Y2Vzc2Z1bGx5IHN0YXJ0ZWQKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3b3JrZXIga2RlXSBz dGFydDogc3VjY2Vzc2Z1bGx5IHN0YXJ0ZWQKTG9ja2VkIGF0IDE3MjI2MTQ5MjMKa3NjcmVlbmxv Y2tlcl9ncmVldDogUGFtQXV0aGVudGljYXRvcnM6IHN0YXJ0aW5nIGF1dGhlbnRpY2F0b3JzCmtz Y3JlZW5sb2NrZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBzdGF0ZSBjaGFuZ2luZyBmcm9t IFBhbUF1dGhlbnRpY2F0b3JzOjpJZGxlIHRvIFBhbUF1dGhlbnRpY2F0b3JzOjpBdXRoZW50aWNh dGluZwprc2NyZWVubG9ja2VyX2dyZWV0OiBbUEFNIHdvcmtlciBrZGUtZmluZ2VycHJpbnRdIEF1 dGhlbnRpY2F0ZTogU3RhcnRpbmcgYXV0aGVudGljYXRpb24Ka3NjcmVlbmxvY2tlcl9ncmVldDog W1BBTSB3b3JrZXIga2RlXSBBdXRoZW50aWNhdGU6IFN0YXJ0aW5nIGF1dGhlbnRpY2F0aW9uCmtz Y3JlZW5sb2NrZXJfZ3JlZXQ6IFtQQU0gd29ya2VyIGtkZS1zbWFydGNhcmRdIEF1dGhlbnRpY2F0 ZTogU3RhcnRpbmcgYXV0aGVudGljYXRpb24Ka3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3b3Jr ZXIga2RlLXNtYXJ0Y2FyZF0gTWVzc2FnZTogSW5mbyBtZXNzYWdlOiBhdXRoPWF1dGhpbmZvX3Vu YXZhaWwKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3b3JrZXIga2RlLXNtYXJ0Y2FyZF0gQXV0 aGVudGljYXRlOiBBdXRoZW50aWNhdGlvbiBkb25lLCByZXN1bHQgY29kZTogOSAoQXV0aGVudGlj YXRpb24gc2VydmljZSBjYW5ub3QgcmV0cmlldmUgYXV0aGVudGljYXRpb24gaW5mbykKa3NjcmVl bmxvY2tlcl9ncmVldDogUGFtQXV0aGVudGljYXRvcnM6IEF2YWlsYWJpbGl0eSBjaGFuZ2VkIGZv ciBub24taW50ZXJhY3RpdmUgYXV0aGVudGljYXRvciBrZGUtZmluZ2VycHJpbnQgdHJ1ZQprc2Ny ZWVubG9ja2VyX2dyZWV0OiBQYW1BdXRoZW50aWNhdG9yczogQXZhaWxhYmlsaXR5IGNoYW5nZWQg Zm9yIG5vbi1pbnRlcmFjdGl2ZSBhdXRoZW50aWNhdG9yIGtkZS1zbWFydGNhcmQgdHJ1ZQprc2Ny ZWVubG9ja2VyX2dyZWV0OiBQYW1BdXRoZW50aWNhdG9yczogSW5mbyBtZXNzYWdlIGZyb20gbm9u LWludGVyYWN0aXZlIGF1dGhlbnRpY2F0b3Iga2RlLXNtYXJ0Y2FyZAprc2NyZWVubG9ja2VyX2dy ZWV0OiBQYW1BdXRoZW50aWNhdG9yczogQXZhaWxhYmlsaXR5IGNoYW5nZWQgZm9yIG5vbi1pbnRl cmFjdGl2ZSBhdXRoZW50aWNhdG9yIGtkZS1zbWFydGNhcmQgZmFsc2UKa3NjcmVlbmxvY2tlcl9n cmVldDogUGFtQXV0aGVudGljYXRvcnM6IEF2YWlsYWJpbGl0eSBjaGFuZ2VkIGZvciBub24taW50 ZXJhY3RpdmUgYXV0aGVudGljYXRvciBrZGUtc21hcnRjYXJkIGZhbHNlCmtzY3JlZW5sb2NrZXJf Z3JlZXQ6IFtQQU0gd29ya2VyIGtkZV0gTWVzc2FnZTogRWNoby1vZmYgcHJvbXB0OiBQYXNzd29y ZDogCmtzY3JlZW5sb2NrZXJfZ3JlZXQ6IFtQQU0gd29ya2VyIGtkZV0gU3RhcnRpbmcgbmVzdGVk IGV2ZW50IGxvb3AgdG8gYXdhaXQgcmVzcG9uc2UKa3NjcmVlbmxvY2tlcl9ncmVldDogUGFtQXV0 aGVudGljYXRvcnM6IFNlY3JldCBwcm9tcHQgZnJvbSBpbnRlcmFjdGl2ZSBhdXRoZW50aWNhdG9y IGtkZQprc2NyZWVubG9ja2VyX2dyZWV0OiBbUEFNIHdvcmtlciBrZGUtZmluZ2VycHJpbnRdIEF1 dGhlbnRpY2F0ZTogQXV0aGVudGljYXRpb24gZG9uZSwgcmVzdWx0IGNvZGU6IDkgKEF1dGhlbnRp Y2F0aW9uIHNlcnZpY2UgY2Fubm90IHJldHJpZXZlIGF1dGhlbnRpY2F0aW9uIGluZm8pCmtzY3Jl ZW5sb2NrZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBBdmFpbGFiaWxpdHkgY2hhbmdlZCBm b3Igbm9uLWludGVyYWN0aXZlIGF1dGhlbnRpY2F0b3Iga2RlLWZpbmdlcnByaW50IGZhbHNlCmtz Y3JlZW5sb2NrZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBBdmFpbGFiaWxpdHkgY2hhbmdl ZCBmb3Igbm9uLWludGVyYWN0aXZlIGF1dGhlbnRpY2F0b3Iga2RlLWZpbmdlcnByaW50IGZhbHNl CmtzY3JlZW5sb2NrZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBjYW5jZWxsaW5nIGludGVy YWN0aXZlIGF1dGhlbnRpY2F0b3IKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3b3JrZXIga2Rl XSBSZWNlaXZlZCBjYW5jZWxsYXRpb24sIGV4aXRpbmcgd2l0aCBQQU1fQ09OVl9FUlIKa3NjcmVl bmxvY2tlcl9ncmVldDogW1BBTSB3b3JrZXIga2RlXSBOZXN0ZWQgZXZlbnQgbG9vcCdzIGV4aXQg Y29kZSB3YXMgbm90IHplcm8sIGJhaWxpbmcKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3b3Jr ZXIga2RlXSBNZXNzYWdlOiBFY2hvLW9mZiBwcm9tcHQ6IFBhc3N3b3JkOiAKa3NjcmVlbmxvY2tl cl9ncmVldDogW1BBTSB3b3JrZXIga2RlXSBTdGFydGluZyBuZXN0ZWQgZXZlbnQgbG9vcCB0byBh d2FpdCByZXNwb25zZQprc2NyZWVubG9ja2VyX2dyZWV0OiBQYW1BdXRoZW50aWNhdG9yczogU2Vj cmV0IHByb21wdCBmcm9tIGludGVyYWN0aXZlIGF1dGhlbnRpY2F0b3Iga2RlCmtzY3JlZW5sb2Nr ZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiByZXNwb25kaW5nIHRvIGludGVyYWN0aXZlIGF1 dGhlbnRpY2F0b3IKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3b3JrZXIga2RlXSBSZWNlaXZl ZCByZXNwb25zZSwgZXhpdGluZyBuZXN0ZWQgZXZlbnQgbG9vcAprc2NyZWVubG9ja2VyX2dyZWV0 OiBbUEFNIHdvcmtlciBrZGVdIEF1dGhlbnRpY2F0ZTogQXV0aGVudGljYXRpb24gZG9uZSwgcmVz dWx0IGNvZGU6IDcgKEF1dGhlbnRpY2F0aW9uIGZhaWx1cmUpCmtzY3JlZW5sb2NrZXJfZ3JlZXQ6 IFBhbUF1dGhlbnRpY2F0b3JzOiBJbnRlcmFjdGl2ZSBhdXRoZW50aWNhdG9yIGtkZSBjaGFuZ2Vk IGJ1c2luZXNzCmtzY3JlZW5sb2NrZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBJbnRlcmFj dGl2ZSBhdXRoZW50aWNhdG9yIGtkZSBjaGFuZ2VkIGJ1c2luZXNzCmtzY3JlZW5sb2NrZXJfZ3Jl ZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBGYWlsdXJlIGZyb20gaW50ZXJhY3RpdmUgYXV0aGVudGlj YXRvciBrZGUKa3NjcmVlbmxvY2tlcl9ncmVldDogUGFtQXV0aGVudGljYXRvcnM6IHN0YXRlIGNo YW5naW5nIGZyb20gUGFtQXV0aGVudGljYXRvcnM6OkF1dGhlbnRpY2F0aW5nIHRvIFBhbUF1dGhl bnRpY2F0b3JzOjpJZGxlCmtzY3JlZW5sb2NrZXJfZ3JlZXQ6IFBhbUF1dGhlbnRpY2F0b3JzOiBz dGFydGluZyBhdXRoZW50aWNhdG9ycwprc2NyZWVubG9ja2VyX2dyZWV0OiBQYW1BdXRoZW50aWNh dG9yczogc3RhdGUgY2hhbmdpbmcgZnJvbSBQYW1BdXRoZW50aWNhdG9yczo6SWRsZSB0byBQYW1B dXRoZW50aWNhdG9yczo6QXV0aGVudGljYXRpbmcKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BBTSB3 b3JrZXIga2RlXSBBdXRoZW50aWNhdGU6IFN0YXJ0aW5nIGF1dGhlbnRpY2F0aW9uCmtzY3JlZW5s b2NrZXJfZ3JlZXQ6IFtQQU0gd29ya2VyIGtkZV0gTWVzc2FnZTogRWNoby1vZmYgcHJvbXB0OiBQ YXNzd29yZDogCmtzY3JlZW5sb2NrZXJfZ3JlZXQ6IFtQQU0gd29ya2VyIGtkZV0gU3RhcnRpbmcg bmVzdGVkIGV2ZW50IGxvb3AgdG8gYXdhaXQgcmVzcG9uc2UKa3NjcmVlbmxvY2tlcl9ncmVldDog UGFtQXV0aGVudGljYXRvcnM6IFNlY3JldCBwcm9tcHQgZnJvbSBpbnRlcmFjdGl2ZSBhdXRoZW50 aWNhdG9yIGtkZQprc2NyZWVubG9ja2VyX2dyZWV0OiBQYW1BdXRoZW50aWNhdG9yczogcmVzcG9u ZGluZyB0byBpbnRlcmFjdGl2ZSBhdXRoZW50aWNhdG9yCmtzY3JlZW5sb2NrZXJfZ3JlZXQ6IFtQ QU0gd29ya2VyIGtkZV0gUmVjZWl2ZWQgcmVzcG9uc2UsIGV4aXRpbmcgbmVzdGVkIGV2ZW50IGxv b3AKa3NjcmVlbmxvY2tlcl9ncmVldDogUGFtQXV0aGVudGljYXRvcnM6IEludGVyYWN0aXZlIGF1 dGhlbnRpY2F0b3Iga2RlIGNoYW5nZWQgYnVzaW5lc3MKa3NjcmVlbmxvY2tlcl9ncmVldDogW1BB TSB3b3JrZXIga2RlXSBBdXRoZW50aWNhdGU6IEF1dGhlbnRpY2F0aW9uIGRvbmUsIHJlc3VsdCBj b2RlOiAwIChTdWNjZXNzKQprc2NyZWVubG9ja2VyX2dyZWV0OiBQYW1BdXRoZW50aWNhdG9yczog SW50ZXJhY3RpdmUgYXV0aGVudGljYXRvciBrZGUgY2hhbmdlZCBidXNpbmVzcwprc2NyZWVubG9j a2VyX2dyZWV0OiBQYW1BdXRoZW50aWNhdG9yczogU3VjY2VzcyBmcm9tIGludGVyYWN0aXZlIGF1 dGhlbnRpY2F0b3Iga2RlClVubG9ja2VkClVubG9ja2VkClVubG9ja2VkClVubG9ja2VkClVubG9j a2VkClVubG9ja2VkClVubG9ja2VkClVubG9ja2VkClVubG9ja2VkCg== 172222 2024-08-02 16:41:36 +0000 2024-08-02 16:41:36 +0000 PAM debug messages during kscreenlocker_greet --testing debug.log text/plain 13457 sophie.dexter74 QXVnICAyIDE3OjA4OjM4IEp1c3Q0cExlaXN1cmUgYXVkaXRbNzM5MzFdOiBVU0VSX0FDQ1QgcGlk PTczOTMxIHVpZD0xMDAwIGF1aWQ9MTAwMCBzZXM9MyBzdWJqPXVuY29uZmluZWRfdTp1bmNvbmZp bmVkX3I6dW5jb25maW5lZF90OnMwLXMwOmMwLmMxMDIzIG1zZz0nb3A9UEFNOmFjY291bnRpbmcg Z3JhbnRvcnM9cGFtX3VuaXgscGFtX2xvY2FsdXNlciBhY2N0PSJzb3BoaWUiIGV4ZT0iL3Vzci9i aW4vc3VkbyIgaG9zdG5hbWU9PyBhZGRyPT8gdGVybWluYWw9L2Rldi9wdHMvNyByZXM9c3VjY2Vz cycKQXVnICAyIDE3OjA4OjM4IEp1c3Q0cExlaXN1cmUgc3Vkb1s3MzkzMV06ICBzb3BoaWUgOiBU VFk9cHRzLzcgOyBQV0Q9L2hvbWUvc29waGllL0RvY3VtZW50cy9CdWdfcmVwb3J0cy9rZGUvNDkw OTI0LWZpcnN0LXBhc3N3b3JkLXJlamVjdGVkIDsgVVNFUj1yb290IDsgQ09NTUFORD0vdXNyL2Jp bi90cnVuY2F0ZSAtcyAwIC92YXIvbG9nL2RlYnVnLmxvZwpBdWcgIDIgMTc6MDg6MzggSnVzdDRw TGVpc3VyZSBhdWRpdFs3MzkzMV06IFVTRVJfQ01EIHBpZD03MzkzMSB1aWQ9MTAwMCBhdWlkPTEw MDAgc2VzPTMgc3Viaj11bmNvbmZpbmVkX3U6dW5jb25maW5lZF9yOnVuY29uZmluZWRfdDpzMC1z MDpjMC5jMTAyMyBtc2c9J2N3ZD0iL2hvbWUvc29waGllL0RvY3VtZW50cy9CdWdfcmVwb3J0cy9r ZGUvNDkwOTI0LWZpcnN0LXBhc3N3b3JkLXJlamVjdGVkIiBjbWQ9NzQ3Mjc1NkU2MzYxNzQ2NTIw MkQ3MzIwMzAyMDJGNzY2MTcyMkY2QzZGNjcyRjY0NjU2Mjc1NjcyRTZDNkY2NyBleGU9Ii91c3Iv YmluL3N1ZG8iIHRlcm1pbmFsPXB0cy83IHJlcz1zdWNjZXNzJwpBdWcgIDIgMTc6MDg6MzggSnVz dDRwTGVpc3VyZSBhdWRpdFs3MzkzMV06IENSRURfUkVGUiBwaWQ9NzM5MzEgdWlkPTEwMDAgYXVp ZD0xMDAwIHNlcz0zIHN1Ymo9dW5jb25maW5lZF91OnVuY29uZmluZWRfcjp1bmNvbmZpbmVkX3Q6 czAtczA6YzAuYzEwMjMgbXNnPSdvcD1QQU06c2V0Y3JlZCBncmFudG9ycz1wYW1fZW52LHBhbV9m cHJpbnRkIGFjY3Q9InJvb3QiIGV4ZT0iL3Vzci9iaW4vc3VkbyIgaG9zdG5hbWU9PyBhZGRyPT8g dGVybWluYWw9L2Rldi9wdHMvNyByZXM9c3VjY2VzcycKQXVnICAyIDE3OjA4OjM4IEp1c3Q0cExl aXN1cmUgc3Vkb1s3MzkzMV06IHBhbV91bml4KHN1ZG86c2Vzc2lvbik6IHNlc3Npb24gb3BlbmVk IGZvciB1c2VyIHJvb3QodWlkPTApIGJ5IHNvcGhpZSh1aWQ9MTAwMCkKQXVnICAyIDE3OjA4OjM4 IEp1c3Q0cExlaXN1cmUgYXVkaXRbNzM5MzFdOiBVU0VSX1NUQVJUIHBpZD03MzkzMSB1aWQ9MTAw MCBhdWlkPTEwMDAgc2VzPTMgc3Viaj11bmNvbmZpbmVkX3U6dW5jb25maW5lZF9yOnVuY29uZmlu ZWRfdDpzMC1zMDpjMC5jMTAyMyBtc2c9J29wPVBBTTpzZXNzaW9uX29wZW4gZ3JhbnRvcnM9cGFt X2tleWluaXQscGFtX2xpbWl0cyxwYW1fa2V5aW5pdCxwYW1fbGltaXRzLHBhbV9zeXN0ZW1kLHBh bV91bml4IGFjY3Q9InJvb3QiIGV4ZT0iL3Vzci9iaW4vc3VkbyIgaG9zdG5hbWU9PyBhZGRyPT8g dGVybWluYWw9L2Rldi9wdHMvNyByZXM9c3VjY2VzcycKQXVnICAyIDE3OjA4OjM4IEp1c3Q0cExl aXN1cmUgc3Vkb1s3MzkzMV06IHBhbV91bml4KHN1ZG86c2Vzc2lvbik6IHNlc3Npb24gY2xvc2Vk IGZvciB1c2VyIHJvb3QKQXVnICAyIDE3OjA4OjM4IEp1c3Q0cExlaXN1cmUgYXVkaXRbNzM5MzFd OiBVU0VSX0VORCBwaWQ9NzM5MzEgdWlkPTEwMDAgYXVpZD0xMDAwIHNlcz0zIHN1Ymo9dW5jb25m aW5lZF91OnVuY29uZmluZWRfcjp1bmNvbmZpbmVkX3Q6czAtczA6YzAuYzEwMjMgbXNnPSdvcD1Q QU06c2Vzc2lvbl9jbG9zZSBncmFudG9ycz1wYW1fa2V5aW5pdCxwYW1fbGltaXRzLHBhbV9rZXlp bml0LHBhbV9saW1pdHMscGFtX3N5c3RlbWQscGFtX3VuaXggYWNjdD0icm9vdCIgZXhlPSIvdXNy L2Jpbi9zdWRvIiBob3N0bmFtZT0/IGFkZHI9PyB0ZXJtaW5hbD0vZGV2L3B0cy83IHJlcz1zdWNj ZXNzJwpBdWcgIDIgMTc6MDg6MzggSnVzdDRwTGVpc3VyZSBhdWRpdFs3MzkzMV06IENSRURfRElT UCBwaWQ9NzM5MzEgdWlkPTEwMDAgYXVpZD0xMDAwIHNlcz0zIHN1Ymo9dW5jb25maW5lZF91OnVu Y29uZmluZWRfcjp1bmNvbmZpbmVkX3Q6czAtczA6YzAuYzEwMjMgbXNnPSdvcD1QQU06c2V0Y3Jl ZCBncmFudG9ycz1wYW1fZW52LHBhbV9mcHJpbnRkIGFjY3Q9InJvb3QiIGV4ZT0iL3Vzci9iaW4v c3VkbyIgaG9zdG5hbWU9PyBhZGRyPT8gdGVybWluYWw9L2Rldi9wdHMvNyByZXM9c3VjY2VzcycK QXVnICAyIDE3OjA4OjQzIEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29t cF8xLjMuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0MyBKdXN0NHBMZWlz dXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBza2lw cGluZwpBdWcgIDIgMTc6MDg6NDMgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxl ciBjb21wXzEuMC4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQzIEp1c3Q0 cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVhZHks IHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2No ZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQg SnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4wIGlzIG5vdCBy ZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJt XSBzY2hlZHVsZXIgY29tcF8xLjAuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzow ODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4yLjEgaXMg bm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6 IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAy IDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMu MCBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtl cm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4wLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpB dWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21w XzEuMi4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1 cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMSBpcyBub3QgcmVhZHksIHNraXBw aW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVy IGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRw TGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMC4xIGlzIG5vdCByZWFkeSwg c2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hl ZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBK dXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90IHJl YWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1d IHNjaGVkdWxlciBjb21wXzEuMy4wIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4 OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAuMSBpcyBu b3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDog W2RybV0gc2NoZWR1bGVyIGNvbXBfMS4yLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIg MTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4x IGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2Vy bmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMCBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1 ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBf MS4wLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3Vy ZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMi4xIGlzIG5vdCByZWFkeSwgc2tpcHBp bmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIg Y29tcF8xLjMuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBM ZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBz a2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVk dWxlciBjb21wXzEuMC4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1 c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVh ZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0g c2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6 NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4wIGlzIG5v dCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBb ZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAx NzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4yLjEg aXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJu ZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVn ICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8x LjMuMCBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJl IGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4wLjEgaXMgbm90IHJlYWR5LCBza2lwcGlu ZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBj b21wXzEuMi4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExl aXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMSBpcyBub3QgcmVhZHksIHNr aXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1 bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVz dDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMC4xIGlzIG5vdCByZWFk eSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBz Y2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0 NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90 IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtk cm1dIHNjaGVkdWxlciBjb21wXzEuMy4wIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3 OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAuMSBp cyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5l bDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4yLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcg IDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEu My4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUg a2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMCBpcyBub3QgcmVhZHksIHNraXBwaW5n CkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNv bXBfMS4wLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVp c3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMi4xIGlzIG5vdCByZWFkeSwgc2tp cHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVs ZXIgY29tcF8xLjMuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0 NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5 LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNj aGVkdWxlciBjb21wXzEuMC4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0 IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3Qg cmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2Ry bV0gc2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6 MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4wIGlz IG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVs OiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAg MiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4y LjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBr ZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcK QXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29t cF8xLjMuMCBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlz dXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4wLjEgaXMgbm90IHJlYWR5LCBza2lw cGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxl ciBjb21wXzEuMi4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0 cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMSBpcyBub3QgcmVhZHks IHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2No ZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQg SnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMC4xIGlzIG5vdCBy ZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJt XSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzow ODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMg bm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6 IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4wIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAy IDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAu MSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtl cm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4yLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpB dWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21w XzEuMy4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1 cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMCBpcyBub3QgcmVhZHksIHNraXBw aW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVy IGNvbXBfMS4wLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRw TGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMi4xIGlzIG5vdCByZWFkeSwg c2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hl ZHVsZXIgY29tcF8xLjMuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBK dXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJl YWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1d IHNjaGVkdWxlciBjb21wXzEuMC4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4 OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBu b3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDog W2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIg MTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4w IGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2Vy bmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1 ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBf MS4yLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3Vy ZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4xIGlzIG5vdCByZWFkeSwgc2tpcHBp bmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIg Y29tcF8xLjMuMCBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBM ZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4wLjEgaXMgbm90IHJlYWR5LCBz a2lwcGluZwpBdWcgIDIgMTc6MDg6NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVk dWxlciBjb21wXzEuMi4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1 c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMSBpcyBub3QgcmVh ZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NCBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0g c2NoZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6 NDQgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMC4xIGlzIG5v dCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ0IEp1c3Q0cExlaXN1cmUga2VybmVsOiBb ZHJtXSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAx NzowODo0NSBKdXN0NHBMZWlzdXJlIGtzY3JlZW5sb2NrZXJfZ3JlZXRbNzM5NDRdOiBwYW1fdW5p eChrZGU6YXV0aCk6IHVzZXJuYW1lIFtzb3BoaWVdIG9idGFpbmVkCkF1ZyAgMiAxNzowODo0NSBK dXN0NHBMZWlzdXJlIGF1ZGl0OiBCUEYgcHJvZy1pZD05NSBvcD1MT0FECkF1ZyAgMiAxNzowODo0 NSBKdXN0NHBMZWlzdXJlIHN5c3RlbWRbMV06IFN0YXJ0aW5nIGZwcmludGQuc2VydmljZSAtIEZp bmdlcnByaW50IEF1dGhlbnRpY2F0aW9uIERhZW1vbi4uLgpBdWcgIDIgMTc6MDg6NDUgSnVzdDRw TGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4xIGlzIG5vdCByZWFkeSwg c2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ1IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hl ZHVsZXIgY29tcF8xLjMuMCBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NSBK dXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4wLjEgaXMgbm90IHJl YWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDUgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1d IHNjaGVkdWxlciBjb21wXzEuMi4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4 OjQ1IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMSBpcyBu b3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NSBKdXN0NHBMZWlzdXJlIGtlcm5lbDog W2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjAgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIg MTc6MDg6NDUgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMC4x IGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ1IEp1c3Q0cExlaXN1cmUga2Vy bmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjIuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1 ZyAgMiAxNzowODo0NSBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBf MS4zLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDUgSnVzdDRwTGVpc3Vy ZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMy4wIGlzIG5vdCByZWFkeSwgc2tpcHBp bmcKQXVnICAyIDE3OjA4OjQ1IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIg Y29tcF8xLjAuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NSBKdXN0NHBM ZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4yLjEgaXMgbm90IHJlYWR5LCBz a2lwcGluZwpBdWcgIDIgMTc6MDg6NDUgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVk dWxlciBjb21wXzEuMy4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ1IEp1 c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMCBpcyBub3QgcmVh ZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NSBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0g c2NoZWR1bGVyIGNvbXBfMS4wLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6 NDUgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMi4xIGlzIG5v dCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ1IEp1c3Q0cExlaXN1cmUga2VybmVsOiBb ZHJtXSBzY2hlZHVsZXIgY29tcF8xLjMuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAx NzowODo0NSBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjAg aXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDUgSnVzdDRwTGVpc3VyZSBrZXJu ZWw6IFtkcm1dIHNjaGVkdWxlciBjb21wXzEuMC4xIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVn ICAyIDE3OjA4OjQ1IEp1c3Q0cExlaXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8x LjIuMSBpcyBub3QgcmVhZHksIHNraXBwaW5nCkF1ZyAgMiAxNzowODo0NSBKdXN0NHBMZWlzdXJl IGtlcm5lbDogW2RybV0gc2NoZWR1bGVyIGNvbXBfMS4zLjEgaXMgbm90IHJlYWR5LCBza2lwcGlu ZwpBdWcgIDIgMTc6MDg6NDUgSnVzdDRwTGVpc3VyZSBrZXJuZWw6IFtkcm1dIHNjaGVkdWxlciBj b21wXzEuMy4wIGlzIG5vdCByZWFkeSwgc2tpcHBpbmcKQXVnICAyIDE3OjA4OjQ1IEp1c3Q0cExl aXN1cmUga2VybmVsOiBbZHJtXSBzY2hlZHVsZXIgY29tcF8xLjAuMSBpcyBub3QgcmVhZHksIHNr aXBwaW5nCkF1ZyAgMiAxNzowODo0NSBKdXN0NHBMZWlzdXJlIGtlcm5lbDogW2RybV0gc2NoZWR1 bGVyIGNvbXBfMS4yLjEgaXMgbm90IHJlYWR5LCBza2lwcGluZwpBdWcgIDIgMTc6MDg6NDUgSnVz dDRwTGVpc3VyZSBzeXN0ZW1kWzFdOiBTdGFydGVkIGZwcmludGQuc2VydmljZSAtIEZpbmdlcnBy aW50IEF1dGhlbnRpY2F0aW9uIERhZW1vbi4KQXVnICAyIDE3OjA4OjQ1IEp1c3Q0cExlaXN1cmUg YXVkaXRbMV06IFNFUlZJQ0VfU1RBUlQgcGlkPTEgdWlkPTAgYXVpZD00Mjk0OTY3Mjk1IHNlcz00 Mjk0OTY3Mjk1IHN1Ymo9c3lzdGVtX3U6c3lzdGVtX3I6aW5pdF90OnMwIG1zZz0ndW5pdD1mcHJp bnRkIGNvbW09InN5c3RlbWQiIGV4ZT0iL3Vzci9saWIvc3lzdGVtZC9zeXN0ZW1kIiBob3N0bmFt ZT0/IGFkZHI9PyB0ZXJtaW5hbD0/IHJlcz1zdWNjZXNzJwpBdWcgIDIgMTc6MDg6NDcgSnVzdDRw TGVpc3VyZSBrc2NyZWVubG9ja2VyX2dyZWV0WzczOTQ0XTogcGFtX3VuaXgoa2RlOmF1dGgpOiB1 bmV4cGVjdGVkIHJlc3BvbnNlIGZyb20gZmFpbGVkIGNvbnZlcnNhdGlvbiBmdW5jdGlvbgpBdWcg IDIgMTc6MDg6NDcgSnVzdDRwTGVpc3VyZSBrc2NyZWVubG9ja2VyX2dyZWV0WzczOTQ0XTogcGFt X3VuaXgoa2RlOmF1dGgpOiBjb252ZXJzYXRpb24gZmFpbGVkCkF1ZyAgMiAxNzowODo0NyBKdXN0 NHBMZWlzdXJlIGtzY3JlZW5sb2NrZXJfZ3JlZXRbNzM5NDRdOiBwYW1fdW5peChrZGU6YXV0aCk6 IGF1dGggY291bGQgbm90IGlkZW50aWZ5IHBhc3N3b3JkIGZvciBbc29waGllXQpBdWcgIDIgMTc6 MDg6NTQgSnVzdDRwTGVpc3VyZSBrc2NyZWVubG9ja2VyX2dyZWV0WzczOTQ0XTogcGFtX3VuaXgo a2RlOmF1dGgpOiB1c2VybmFtZSBbc29waGllXSBvYnRhaW5lZApBdWcgIDIgMTc6MDg6NTcgSnVz dDRwTGVpc3VyZSBhdWRpdFs3NDE1MF06IFVTRVJfQVVUSCBwaWQ9NzQxNTAgdWlkPTEwMDAgYXVp ZD0xMDAwIHNlcz0zIHN1Ymo9dW5jb25maW5lZF91OnVuY29uZmluZWRfcjpjaGtwd2RfdDpzMC1z MDpjMC5jMTAyMyBtc2c9J29wPVBBTTp1bml4X2Noa3B3ZCBhY2N0PSJzb3BoaWUiIGV4ZT0iL3Vz ci9zYmluL3VuaXhfY2hrcHdkIiBob3N0bmFtZT0/IGFkZHI9PyB0ZXJtaW5hbD0/IHJlcz1zdWNj ZXNzJwo= 172304 2024-08-05 13:42:31 +0000 2024-08-05 13:42:31 +0000 /etc/pam.d/kde file kde text/plain 508 sophie.dexter74 YXV0aCAgICAgICAgc3Vic3RhY2sgICAgICBwYXNzd29yZC1hdXRoCmF1dGggICAgICAgIGluY2x1 ZGUgICAgICAgcG9zdGxvZ2luCgphY2NvdW50ICAgICByZXF1aXJlZCAgICAgIHBhbV9ub2xvZ2lu LnNvCmFjY291bnQgICAgIGluY2x1ZGUgICAgICAgcGFzc3dvcmQtYXV0aAoKcGFzc3dvcmQgICAg aW5jbHVkZSAgICAgICBwYXNzd29yZC1hdXRoCgpzZXNzaW9uICAgICByZXF1aXJlZCAgICAgIHBh bV9zZWxpbnV4LnNvIGNsb3NlCnNlc3Npb24gICAgIHJlcXVpcmVkICAgICAgcGFtX2xvZ2ludWlk LnNvCnNlc3Npb24gICAgIHJlcXVpcmVkICAgICAgcGFtX3NlbGludXguc28gb3BlbgpzZXNzaW9u ICAgICBvcHRpb25hbCAgICAgIHBhbV9rZXlpbml0LnNvIGZvcmNlIHJldm9rZQpzZXNzaW9uICAg ICByZXF1aXJlZCAgICAgIHBhbV9uYW1lc3BhY2Uuc28Kc2Vzc2lvbiAgICAgaW5jbHVkZSAgICAg ICBwYXNzd29yZC1hdXRoCnNlc3Npb24gICAgIGluY2x1ZGUgICAgICAgcG9zdGxvZ2luCg== 172305 2024-08-05 13:44:12 +0000 2024-08-05 13:44:12 +0000 /etc/authselect/password-auth - sssd version password-auth text/plain 2127 sophie.dexter74 IyBHZW5lcmF0ZWQgYnkgYXV0aHNlbGVjdAojIERvIG5vdCBtb2RpZnkgdGhpcyBmaWxlIG1hbnVh bGx5LCB1c2UgYXV0aHNlbGVjdCBpbnN0ZWFkLiBBbnkgdXNlciBjaGFuZ2VzIHdpbGwgYmUgb3Zl cndyaXR0ZW4uCiMgWW91IGNhbiBzdG9wIGF1dGhzZWxlY3QgZnJvbSBtYW5hZ2luZyB5b3VyIGNv bmZpZ3VyYXRpb24gYnkgY2FsbGluZyAnYXV0aHNlbGVjdCBvcHQtb3V0Jy4KIyBTZWUgYXV0aHNl bGVjdCg4KSBmb3IgbW9yZSBkZXRhaWxzLgoKYXV0aCAgICAgICAgcmVxdWlyZWQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFtX2Vudi5zbwphdXRoICAgICAgICByZXF1aXJl ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYW1fZmFpbGRlbGF5LnNvIGRl bGF5PTIwMDAwMDAKYXV0aCAgICAgICAgW2RlZmF1bHQ9MSBpZ25vcmU9aWdub3JlIHN1Y2Nlc3M9 b2tdICAgICAgICAgcGFtX3VzZXJ0eXBlLnNvIGlzcmVndWxhcgphdXRoICAgICAgICBbZGVmYXVs dD0xIGlnbm9yZT1pZ25vcmUgc3VjY2Vzcz1va10gICAgICAgICBwYW1fbG9jYWx1c2VyLnNvCmF1 dGggICAgICAgIHN1ZmZpY2llbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBh bV91bml4LnNvIG51bGxvawphdXRoICAgICAgICBbZGVmYXVsdD0xIGlnbm9yZT1pZ25vcmUgc3Vj Y2Vzcz1va10gICAgICAgICBwYW1fdXNlcnR5cGUuc28gaXNyZWd1bGFyCmF1dGggICAgICAgIHN1 ZmZpY2llbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV9zc3Muc28gZm9y d2FyZF9wYXNzCmF1dGggICAgICAgIHJlcXVpcmVkICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHBhbV9kZW55LnNvCgphY2NvdW50ICAgICByZXF1aXJlZCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwYW1fdW5peC5zbwphY2NvdW50ICAgICBzdWZmaWNpZW50 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYW1fbG9jYWx1c2VyLnNvCmFjY291 bnQgICAgIHN1ZmZpY2llbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV91 c2VydHlwZS5zbyBpc3N5c3RlbQphY2NvdW50ICAgICBbZGVmYXVsdD1iYWQgc3VjY2Vzcz1vayB1 c2VyX3Vua25vd249aWdub3JlXSBwYW1fc3NzLnNvCmFjY291bnQgICAgIHJlcXVpcmVkICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV9wZXJtaXQuc28KCnBhc3N3b3JkICAg IHJlcXVpc2l0ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV9wd3F1YWxp dHkuc28gbG9jYWxfdXNlcnNfb25seQpwYXNzd29yZCAgICBzdWZmaWNpZW50ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwYW1fdW5peC5zbyB5ZXNjcnlwdCBzaGFkb3cgbnVsbG9r IHVzZV9hdXRodG9rCnBhc3N3b3JkICAgIFtzdWNjZXNzPTEgZGVmYXVsdD1pZ25vcmVdICAgICAg ICAgICAgICAgICAgIHBhbV9sb2NhbHVzZXIuc28KcGFzc3dvcmQgICAgc3VmZmljaWVudCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFtX3Nzcy5zbyB1c2VfYXV0aHRvawpwYXNz d29yZCAgICByZXF1aXJlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYW1f ZGVueS5zbwoKc2Vzc2lvbiAgICAgb3B0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcGFtX2tleWluaXQuc28gcmV2b2tlCnNlc3Npb24gICAgIHJlcXVpcmVkICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV9saW1pdHMuc28KLXNlc3Npb24gICAg b3B0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFtX3N5c3RlbWQu c28Kc2Vzc2lvbiAgICAgW3N1Y2Nlc3M9MSBkZWZhdWx0PWlnbm9yZV0gICAgICAgICAgICAgICAg ICAgcGFtX3N1Y2NlZWRfaWYuc28gc2VydmljZSBpbiBjcm9uZCBxdWlldCB1c2VfdWlkCnNlc3Np b24gICAgIHJlcXVpcmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV91 bml4LnNvCnNlc3Npb24gICAgIG9wdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHBhbV9zc3Muc28K 172306 2024-08-05 13:45:28 +0000 2024-08-05 13:45:28 +0000 /etc/authselect/password-auth - local version password-auth text/plain 1272 sophie.dexter74 IyBHZW5lcmF0ZWQgYnkgYXV0aHNlbGVjdAojIERvIG5vdCBtb2RpZnkgdGhpcyBmaWxlIG1hbnVh bGx5LCB1c2UgYXV0aHNlbGVjdCBpbnN0ZWFkLiBBbnkgdXNlciBjaGFuZ2VzIHdpbGwgYmUgb3Zl cndyaXR0ZW4uCiMgWW91IGNhbiBzdG9wIGF1dGhzZWxlY3QgZnJvbSBtYW5hZ2luZyB5b3VyIGNv bmZpZ3VyYXRpb24gYnkgY2FsbGluZyAnYXV0aHNlbGVjdCBvcHQtb3V0Jy4KIyBTZWUgYXV0aHNl bGVjdCg4KSBmb3IgbW9yZSBkZXRhaWxzLgoKYXV0aCAgICAgICAgcmVxdWlyZWQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFtX2Vudi5zbwphdXRoICAgICAgICByZXF1aXJl ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYW1fZmFpbGRlbGF5LnNvIGRl bGF5PTIwMDAwMDAKYXV0aCAgICAgICAgc3VmZmljaWVudCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcGFtX3VuaXguc28gbnVsbG9rCmF1dGggICAgICAgIHJlcXVpcmVkICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhbV9kZW55LnNvCgphY2NvdW50ICAgICBy ZXF1aXJlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYW1fdW5peC5zbwoK cGFzc3dvcmQgICAgcmVxdWlzaXRlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cGFtX3B3cXVhbGl0eS5zbwpwYXNzd29yZCAgICBzdWZmaWNpZW50ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwYW1fdW5peC5zbyB5ZXNjcnlwdCBzaGFkb3cgbnVsbG9rIHVzZV9h dXRodG9rCnBhc3N3b3JkICAgIHJlcXVpcmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHBhbV9kZW55LnNvCgpzZXNzaW9uICAgICBvcHRpb25hbCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBwYW1fa2V5aW5pdC5zbyByZXZva2UKc2Vzc2lvbiAgICAgcmVx dWlyZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFtX2xpbWl0cy5zbwot c2Vzc2lvbiAgICBvcHRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw YW1fc3lzdGVtZC5zbwpzZXNzaW9uICAgICBbc3VjY2Vzcz0xIGRlZmF1bHQ9aWdub3JlXSAgICAg ICAgICAgICAgICAgICBwYW1fc3VjY2VlZF9pZi5zbyBzZXJ2aWNlIGluIGNyb25kIHF1aWV0IHVz ZV91aWQKc2Vzc2lvbiAgICAgcmVxdWlyZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgcGFtX3VuaXguc28K