PAM not working under ArchLinux (using LightDM)

[cpixl]

I enabled the envoy service with:

systemctl enable envoy@gpg-agent.socket

... added these to my /etc/pam.d/login:

auth      optional    pam_envoy.so
session   optional    pam_envoy.so    gpg-agent

... and added envoy id_rsa to my .zshrc, but it still doesn't work... there's something else I should configure to make it work? or is it a bug?

[vodik]

Can you check if you have the same stuff as in this issue in your log? See #36.

Sorry, I don't mean to be an inactive maintainer. I'm stuggling with moving houses at the moment and don't have my development machine or internet worked out yet.

[vodik]

Any more details on this bug?

[cpixl]

Sorry for the long delay, I was really busy these days...

Well, to tell the truth... there's no error on the logs, nothing related to the PAM module.

Just to be sure... is the /etc/pam.d/login file the right one? Because I have these in the same directory too:
/etc/pam.d/system-login
/etc/pam.d/system-local-login
/etc/pam.d/system-remote-login

Also, my /etc/pam.d/login contains the following:

#%PAM-1.0

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
auth       optional     pam_envoy.so
account    include      system-local-login
session    include      system-local-login
session    optional     pam_envoy.so            gpg-agent

Does the order matter in any way? I really don't know much about how PAM config works.

Just to give more details, my .zshrc config looks like this now:

[...]
export GPG_ENV="$HOME/.gpg-agent-info"
envoy id_rsa
source <(envoy -p)
[...]

[ramonmaruko]

I think you have to put the pam options in the file defined as pam-service in /etc/lightdm/lightdm.conf. In my case, I've had to put it in /etc/pam.d/lightdm.

[vodik]

@Dan-Silva yeah, it matters where you're logging in from. /etc/pam.d/login, iirc, only covers logging in at a tty. I had to put things in again in /etc/pam.d/sshd for ssh shells.

[cpixl]

Well, to keep things simple I'm logging through a TTY now (just to get it working). It looks like the SSH doesn't work (it still asks me for the passphrase through a pinentry) and the GPG key is always invalid, e.g. when I try the following command:

echo "1234" | gpg -o /dev/null --local-user 'dan' -as - && echo "The correct passphrase was entered for this key"

It returns the following (without asking me the passphrase):

gpg: signing failed: Operation cancelled
gpg: signing failed: Operation cancelled

Again, I see no logs on the journal.

[cpixl]

And an interesting fact is that when putting the config in /etc/pam.d/lightdm, the SSH give me the following:

Agent admitted failure to sign using the key.
Permission denied (publickey).

... and GPG just pops up an pinentry! Just as if the behaviours were switched. Bizarre.

[vodik]

Is the ssh keyring from gpg encrypted (has a password)?

[cpixl]

Yes, with the same password I use on login.

[vodik]

I think @ramonmaruko may have solved this mystery. See #40. I'll tackle this as soon as I get a chance.

[cpixl]

I updated it but I'm still having the same issues. And didn't find anything new on syslog :/

[ramonmaruko]

Agent admitted failure to sign using the key.
Permission denied (publickey).

I had encountered that error before while trying to to use an SSH key, and I "fixed" it by issuing gpg-connect-agent updatestartuptty /bye before doing ssh example.com

[vodik]

Right, story time!

Agent admitted failure to sign using the key.
Permission denied (publickey).

Is an error that comes up whenever your ssh keyring is locked, gpg-agent tries to unlock it, but fails to prompt you. It prompts you by launching the appropriate pinentry program (curses, gtk-2 or qt4). In order to do this, gpg-agent needs to know either which X session to pop up on or which tty (seed it with /dev/pts/x or /dev/tty) and typically these stuff comes directly from the environment which launched gpg-agent (reading DISPLAY/TERM/GPG_TTY env variables, checking what the tty of the launching process was if GPG_TTY wasn't set, etc).

However I don't have this information when starting gpg-agent. It can't read it from the envionment systemd launches envoyd in (not that it would be correct anyways) and I can't really pre-seed defaults because they will be wrong. I can't do this correctly inside the pam module either since at that time, the only piece of information I'd have is the tty. pam runs before X so I'll never capture DISPLAY.

So you actually must do a gpg-connect-agent updatestartuptty /bye. envoy actually has a native version implemented: gpg_update_tty. This is so if you run envoy; ssh ... the pinentry will always work as expected, popping up as expected.

This is actually why I devised the envoy-exec command. What it does:

1. Launch the agent (envoy -p)
2. Inject the needed environment automatically
3. Issue UPDATESTATUPTTY
4. Launch your command.

So I recommend either alias ssh='envoy-exec ssh' or you can use the symlink magic support (haven't quite decided if this is really a sane thing to do, but its there and I use it).

$ ll ~/.local/bin
lrwxrwxrwx 1 simon users   19 Sep  4  2014 ssh -> /usr/bin/envoy-exec*

So the ssh ... binary acts transparently as if envoy-exec -- ssh .... This way the pinentry always works, popping up graphically when I'm inside X on the right tty when I'm using ssh (if you do the UPDATESTATUPTTY step manually, having the pinentry launch in the wrong place is very easy problem to get yourself into. Worse yet, hard killing the pinentry because it launched itself on the wrong tty essentially corrupts that tty. Its not very fun stuff).

This explanation probably help you guys understand why I get caught with my pants down with a broken the pam module - I don't use it. The pam module, imho, is only useful for two cases which I don't do:

• You prefer to use ssh-agent over gpg-agent
• You unlock your gpg-agent's ssh keyring at login and keep it unlocked

The second you need to rely on the pinentry showing up, the pam module is going to be nothing but headaches and weird behaviour unless you understand how the pinentry system works.

If it wasn't for UPDATESTATUPTTY I simply couldn't support gpg-agent. In my humble opinion, its a terrible system and part of the reason I've stopped hacking on envoy for now. When session bus stuff stabilizes, I would love to overhaul all this pinentry stuff (write my own minimal agent if I have to) that does this a little saner (broadcast for a pinentry already running over dbus).

[vodik]

Any updates or can I chalk this one up to configuration problems (or was envoy abandoned in the end?). I understand navigating the ins and outs of gpg-agent annoying... I was actually surprised I was able to support it at all).

[cpixl]

Well, actually my desired behaviour is to unlock the keyring on login by using my password, so I guess it's reasonable for me to still try using the PAM module.

In the end I just ended up aliasing my gpg, ssh and git commands with envoy-exec to fix the "permission denied" problem, but... it prompts me the password on first time, as if I wasn't using the PAM module.

I'm really sorry that I'm not able to provide so much information. The log doesn't contain any useful information other than what I already provided here, and my configs didn't change so much... I'm thinking about touching the source code, but I probably won't be able to do anything for the next weeks.

Anyway, my problem persists with the latest version.

[vodik]

If the pam module isn't unlocking the session at all, that's a bug and something I'll investigate into.

That said, unlocking like this, I think, might need some gpg-agent configuration to keep it from expiring your password. I should get myself more familiar with this code. You're not the first to have problems and my ability to support them is limited since I don't use it: I don't reuse my password and I want it to timeout.

Time to create some test keys when I get home.

[untitaker]

I get the exact same behavior, the PAM module is not working at all (I have to provide the passphrase on first use), though I put the instructions into the same file where pam_ssh works (system-auth).

[vodik]

@untitaker sorry for the delay.

1. Is your password the same as your key's password?
2. gpg-agent or ssh-agent?

[untitaker]

@untitaker sorry for the delay.

No worries, remember I'm not entitled to anything.

Is your password the same as your key's password?

Yes.

gpg-agent or ssh-agent?

GPG has that problem. SSH unlocks fine.

[vodik]

Wait, are we talking about ssh keys gpg keys? And is allow-preset-passphrase in your gpg-agent config?

SSH unlocks fine

envoy's pam can't handle ssh, is this in comparison to pam_ssh?

[untitaker]

We're talking about the unlocking of GPG keys. I'll try out envoy sometime again, I didn't know that envoy doesn't unlock SSH keys (probably my reading comprehension failed me) and now I'm just as confused as you are.

On 22 May 2015 17:28:50 CEST, Simon Gomizelj notifications@github.com wrote:

Wait, are we talking about ssh keys gpg keys? And is
allow-preset-passphrase in your gpg-agent config?

SSH unlocks fine

envoy's pam can't handle ssh, is this in comparison to pam_ssh?

---

Reply to this email directly or view it on GitHub:
#37 (comment)

[vodik]

This issue is just gotten a little overloaded and I indeed confused myself.

We're talking about the unlocking of GPG keys

This is something I don't support right now. The presetting support in envoy for gpg-agent is specifically only for the ssh keys it manages. Envoy started off as an ssh helper and grown, but to support unlocking gpg keys I first have to tackle #30. I don't know how to enumerate them.

I didn't know that envoy doesn't unlock SSH keys

Thats what its built for. I confused myself by thinking about ssh-agent instead of gpg-agent (pam_ssh is for ssh-agent). If you're using ssh-agent, pam_envoy for unlocking doesn't work.

[vodik]

Alright, because there are a few different people jumping on here with different issues, I'm going to close and lock this issue. If:

• You are trying to unlock gpg-agent's ssh keyring and can't with the pam module, thats a legit issue. Please open a new issue though because there's just a lot of noise here. I will fix that.
• You are trying to unlock gpg-agent's gpg keys. I will work on this. I'll probably approach this by letting you specify the keygrips to preset. Follow issue Presetting support for gpg keys other than the ssh keyring #30 because this is already an open issue. Hopefully I'll be able to support this soon.
• You are trying to unlock ssh-agent ssh key. This is not supported and won't be supported.