[RFC PATCH 0/4] PAM module for ssh-agent user authentication

Domenico Andreoli cavokz at gmail.com
Tue Jul 21 19:12:15 AEST 2020

On Tue, Jul 21, 2020 at 12:46:40AM -0400, Nico Kadel-Garcia wrote:
> On Mon, Jul 20, 2020 at 9:28 PM Domenico Andreoli <cavokz at gmail.com> wrote:
> >
> > Hi,
> >
> > The main (and probably the only) use case of this PAM module is to let
> > sudo authenticate users via their ssh-agent, therefore without having
> > to type any password and without being tempted to use the NOPASSWD sudo
> > option for such convenience.
> Why? In order to keep your original agent accessible, you'd have to
> open up permissions to the socket to the other user without using
> group membership, namely open it to to the world and maybe hiding it
> by obscurity. Why wouldn't you simply put the public SSH key in the
> target account, maybe restricting access to loclahost, and use "ssh -A
> localhost -l targetaccount".

Nice. I never fully realized but the same idea was clearly lurking in
the sub-conscious while I was working at this in these past days.

It was clear to me that for switching to any user except root, ssh -l
would be the easiest way. That's why I did not have any plan for adding
tilde expansion or any other complexity for reaching the auth file.

But still, these held in my conscious:

1. I use sudo mostly to become root
2. PermitRootLogin=no
3. Using 'ssh localhost' adds 'something between'
4. I use sudo -E to feel really at home
5. I use sudo NOPASSWD

Although I'm admin of just my laptop, I always knew that #5 is really bad
and dropping it (and throw U2F/FIDO in the mix) is the main motivation
of the work I've just presented.

In trying your approach I discovered that actually #2 is wrong, nowadays
default is PermitRootLogin=prohibit-password and my sshd_config does
not override it. I don't have any good reason to set it back either.

#3 is also quite moot but dropping it actually helped me to realize #4,
honestly not much less nasty than #5. Now I'll go fixing my 'laptops',
I never adopted #5 on sensitive ones but still #4 needs a proper killing.

What to say? Your solution is clearly superior and highlighted a bad
habit, so I thank you for sharing it.

I've to say I liked the idea of contributing to openssh. I digested
quite a number of linking errors while searching my way to reuse most of
what's aready there and now I've a certain 'feeling' of how things are.

Is there any 'good first issue' I could work on to keep the momentum?


rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

More information about the openssh-unix-dev mailing list