pam-gnupg fails with SDDM (but works for term login)

SpacePlod · 06-03-2022, 09:46 AM

I am trying to get pam-gnupg working with SDDM. This is for use with
password-store. I've followed the instructions on the pam-gnupg page.
The setup works fine for logging in on runlevel 3/login, but fails on runlevel 4/sddm.

I've added the following two lines to both /etc/pam.d/login and /etc/pam.d/sddm:

Code:

auth     optional  pam_gnupg.so store-only
session  optional  pam_gnupg.so

~/.pam-gnupg contains the correct gpg keygrip, and these are my gpg config files:

Code:

$ cat ~/.gnupg/gpg-agent.conf
allow-preset-passphrase
default-cache-ttl 86400
max-cache-ttl 86400

Code:

$ cat ~/.gnupg/gpg.conf
use-agent

As I mentioned, this setup works great for runlevel 3, but fails on
SDDM. The only log message I could find is in /var/log/secure:

Code:

sddm-helper: gkr-pam: couldn't unlock the login keyring.

But it's not very helpful. Any ideas?

0XBF · 06-03-2022, 10:09 AM

With a disclaimer like that, I'm not about to build and test this pam module. A couple pointers after reading over the README.md though:

Quote:

configure takes an option --with-moduledir to set the installation path of the PAM module. It defaults to /lib/security, but your distribution might use a different path.

Slackware 64 uses /lib64/security for all the pam modules, I dont know how you built but just making sure its noticed.

Quote:

sddm-helper: gkr-pam: couldn't unlock the login keyring.

This is just the gnome-keyring module. It shouldn't have anything to do with this new module.

Quote:

Debug output

Both the auth and the session module take a debug option to enable some basic debug logging to syslog / journal.

Lots of pam modules do this. Turning on 'debug' will probably get the module to report in the log what is going on. Then you will at least know where to look next. Try something like:

Code:

auth     optional  pam_gnupg.so store-only debug
session  optional  pam_gnupg.so debug

And check both /var/log/secure, and possibly /var/log/syslog for the relevant debug output

SpacePlod · 06-03-2022, 10:43 AM

Quote:

Originally Posted by 0XBF

With a disclaimer like that, I'm not about to build and test this pam module. A couple pointers after reading over the README.md though:

Right now this is all being done in a clean install QEMU VM. Production use will be limited and offline, but the warning is noted.

Quote:

Originally Posted by 0XBF

Slackware 64 uses /lib64/security for all the pam modules, I dont know how you built but just making sure its noticed.

Built from SBo. The script passes the correct module directory.

Quote:

Originally Posted by 0XBF

Lots of pam modules do this. Turning on 'debug' will probably get the module to report in the log what is going on. Then you will at least know where to look next.

Well...that's interesting. Turning on debug resulted in this output in /var/log/secure (nothing relevant in syslog):

Code:

Jun  3 11:27:43 darkstar sddm-helper: pam_gnupg(sddm:auth): stored passphrase
Jun  3 11:27:43 darkstar sddm-helper: pam_gnupg(sddm:setcred): store-only set, skipping
Jun  3 11:27:43 darkstar sddm-helper: pam_gnupg(sddm:session): presetting passphrase succeeded, cleaning up
Jun  3 11:27:43 darkstar sddm-helper: pam_gnupg(sddm:setcred): store-only set, skipping

This seems to indicate it's working (with my weak pam-fu), although I still need to use my passphrase to unlock 'pass'. Logging in on run level three does not require that. Also, logging in using runlevel three results in NO entries in /var/log/secure for pam-gnupg...it just works. Something's off here.

Thanks for the useful pointers!

0XBF · 06-03-2022, 11:27 AM

Quote:

Originally Posted by SpacePlod

This seems to indicate it's working (with my weak pam-fu), although I still need to use my passphrase to unlock 'pass'. Logging in on run level three does not require that. Also, logging in using runlevel three results in NO entries in /var/log/secure for pam-gnupg...it just works. Something's off here.

Did you also add 'debug' to the same pam_gnupg.so lines in /etc/pam.d/login ?
They should provide similar debug output if they are both set up with debug, and that might give a useful comparison.

Also, did you make sure that the session line comes after pam_elogind.so in the pam configs? They mention it must come after pam_systemd, which would equate to the elogind module.

One other thing, you are not trying this with sddm-autologin, correct? The readme states that it will not work that way, and needs a typed password to utilize.

SpacePlod · 06-03-2022, 12:00 PM

Quote:

Originally Posted by 0XBF

Did you also add 'debug' to the same pam_gnupg.so lines in /etc/pam.d/login ?
They should provide similar debug output if they are both set up with debug, and that might give a useful comparison.

Yes - I have now. If I login on runlevel 3 I get almost the exact same log entries (but 'pass' works without a passphrase):

Code:

Jun  3 12:52:36 darkstar login: pam_gnupg(login:auth): stored passphrase
Jun  3 12:52:36 darkstar login: pam_gnupg(login:setcred): store-only set, skipping
Jun  3 12:52:36 darkstar login: pam_gnupg(login:session): presetting passphrase succeeded, cleaning up
Jun  3 12:52:36 darkstar login: pam_gnupg(login:setcred): store-only set, skipping

Quote:

Originally Posted by 0XBF

Also, did you make sure that the session line comes after pam_elogind.so in the pam configs? They mention it must come after pam_systemd, which would equate to the elogind module.

The lines for pam-gnupg are added at the very end of each file. But that's good to know...I ignored that part of the readme, not making the connection between systemd and elogind.

Quote:

Originally Posted by 0XBF

One other thing, you are not trying this with sddm-autologin, correct? The readme states that it will not work that way, and needs a typed password to utilize.

No. The modules are loaded in /etc/pam.d/sddm (not -autologin or -greeter).

Contents of /etc/pam.d/sddm:

Code:

#%PAM-1.0

auth       substack     system-auth

# Uncomment this line to restrict login to users with a UID greater
# than 999 (in other words, don't allow login for root):
#auth       required     pam_succeed_if.so        uid >= 1000 quiet

-auth      optional     pam_gnome_keyring.so
-auth      optional     pam_kwallet5.so
auth       include      postlogin

account    include      system-auth

password   substack     system-auth
-password  optional     pam_gnome_keyring.so     use_authtok
-password  optional     pam_kwallet5.so          use_authtok

session    optional     pam_keyinit.so           force revoke
session    substack     system-auth
session    required     pam_loginuid.so
-session   optional     pam_ck_connector.so      nox11
-session   optional     pam_elogind.so
-session   optional     pam_gnome_keyring.so     auto_start
-session   optional     pam_kwallet5.so          auto_start
session    include      postlogin

auth       optional      pam_gnupg.so            store-only debug
session    optional      pam_gnupg.so            debug

And thanks again.

0XBF · 06-03-2022, 02:09 PM

I had a VM I was setting up over the last few days, so I tried that pam-gnupg package on it with password-store. I can confirm that it doesnt work in 'sddm' or 'xdm', just the 'login' method of authentication. With the suggested config, the messages are exactly the same. The only difference is that with sddm or xdm, I see polkit starting an authentication agent right after in /var/log/secure, where that doesnt happen for a tty login. I dont know if its related or not.

I also tried without the 'store-only' option set in the xdm or sddm configuration for pam, which does report the errors:

Code:

pam_gnupg_helper: child terminated with exit code 1
pam_gnupg(xdm:setcred): helper terminated with exit code 1
pam_gnupg(xdm:setcred): presetting failed, retaining passphrase

I couldn't get it to work otherwise so I dont think I'll be much more help here. Heading out of town in a couple hours anyway, so I wont be able to keep troubleshooting on this. Good luck.

SpacePlod · 06-03-2022, 02:33 PM

Quote:

Originally Posted by 0XBF

...
I couldn't get it to work otherwise so I dont think I'll be much more help here. Heading out of town in a couple hours anyway, so I wont be able to keep troubleshooting on this. Good luck.

Thanks. At least I know it's not just me. I'll keep at it for awhile. You've been an immense help and I appreciate your time. Safe travels.

0XBF · 06-07-2022, 07:12 PM

Any chance you were using xfce to test pam-gnupg in runlevel 4?

I was running xfce from sddm when I was testing pam-gnupg last time. When I start xfce from sddm, the gpg-agent is not started. I'm guessing that in this case then the password doesnt get handed off from pam to anything, so invoking 'pass' the first time in an xfce session brings up the dialog box to unlock it.

I tested the same /etc/pam.d/sddm config for Plasma (X11) today. When starting plasma, the gpg-agent starts properly, the password is handed off, and invoking pass has it properly unlocked. You can see that gpg-agent is one of the first processes started at login:

Code:

bob@darkstar:~$ pgrep -au bob
2940 gpg-agent --homedir /home/bob/.gnupg --use-standard-socket --daemon
2942 dbus-run-session /usr/bin/startplasma-x11
2952 dbus-daemon --nofork --print-address 4 --session
2953 /usr/bin/startplasma-x11
... etc.

This is the same behaviour as when logging in at a tty in runlevel 3 via the /etc/pam.d/login config.

So it would seem that pam-gnupg works when started from /etc/pam.d/sddm when using plasma, but not when xfce is selected. Not really sure why that would be the case however.

SpacePlod · 06-07-2022, 08:59 PM

Quote:

Originally Posted by 0XBF

Any chance you were using xfce to test pam-gnupg in runlevel 4?

Yes. That is exactly correct. For kicks, I just switched to blackbox. It worked there as well. And WindowMaker.

Quote:

Originally Posted by 0XBF

So it would seem that pam-gnupg works when started from /etc/pam.d/sddm when using plasma, but not when xfce is selected. Not really sure why that would be the case however.

The issue thus far seems to be with XFCE. I'm going to install i3 tomorrow and give that a shot (it's what will be running on the production box).

I appreciate the testing. This gives me a lead to follow at least. Thanks.

SpacePlod · 06-09-2022, 10:12 AM

Quick update: pam-gnupg also fails with SDDM/i3.

So right now (runlevel4/sddm) it works with KDE/Plasma, Blackbox, WindowMaker. Fails with XFCE and i3.

0XBF · 06-09-2022, 11:24 AM

I managed to find out what is going on with xfce4; it starts its own gpg-agent, which seems to replace the one started by pam-gnupg as soon as xfce4 starts. See this link for reference: https://docs.xfce.org/xfce/xfce4-ses...and_gpg_agents

What I did to fix it was start an xfce4 session. Then in a terminal run the following to disable xfce4 from starting its own gpg-agent:

Code:

xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled -n -t bool -s false

After logging out, xfce4 now starts and the gpg-agent started by pam-gnupg remains active so pass stays unlocked after login in xfce4.

I've never tried i3 so I'm not sure what's going on there. Maybe check if it does something similar where it starts its own gpg-agent?

SpacePlod · 06-09-2022, 12:20 PM

Quote:

Originally Posted by 0XBF

I managed to find out what is going on with xfce4; it starts its own gpg-agent, which seems to replace the one started by pam-gnupg as soon as xfce4 starts. See this link for reference: https://docs.xfce.org/xfce/xfce4-ses...and_gpg_agents

That is interesting (and it worked on my VM with XFCE - i3 is still a no go). I wonder why runlevel 3 works correctly with pam-gnupg/XFCE but not runlevel 4.

I'm going to try something like keychain on i3 to see if that works.

As always, thanks again.

0XBF · 06-09-2022, 03:34 PM

Quote:

Originally Posted by SpacePlod

I wonder why runlevel 3 works correctly with pam-gnupg/XFCE but not runlevel 4.

It doesnt work in xfce4 started from runlevel 3 in my VM. Its only unlocked after login, up to the point where you start xfce4.

What I see is immediately after login on a tty, the gpg-agent is started and all is good. However, as soon as you run 'startx' to start the xfce4 session, xfce4's gpg-agent is started, and the original one started from pam-gnupg is stopped. Using 'pass' immediately after the xfce4 session starts will popup with the gpg2 dialog box to unlock it, since its not the same agent that was unlocked from pam. This is what made me suspect xfce4 starts its own agent in the first place and got me looking into that documentation about it.

Just to summarize, login at a tty in runlevel 3, then immediately run 'pgrep -au <your user name>', you should see gpg-agent in the first few processes with a line like:

Code:

gpg-agent --homedir /home/<username>/.gnupg --use-standard-socket --daemon

This is the gpg-agent started and unlocked with pam.

Then after starting xfce4, run 'pgrep -au <your user name>' again. There will be a lot more processes now, but that initial gpg-agent will be gone, and another one with a higher pid is in the processes started when xfce4 starts up, shortly after xfce4-session. This one is not unlocked, so it will popup with a dialog box. After making that fix, the original gpg-agent remains the xfce4 started agent no longer replaces it.

You might be able to check i3 with a similar method, starting it from runlevel3

Tonus · 06-09-2022, 11:47 PM

Quote:

Originally Posted by SpacePlod

I'm going to try something like keychain on i3 to see if that works.

You might have already found it, i3 and keychain :
https://bbs.archlinux.org/viewtopic.php?id=203055

Would be great to have a small summary when you get it sorted