openssh unix dev - Jul 2020 - [RFC PATCH 0/4] PAM module for ssh-agent user authentication

On Mon, Jul 20, 2020 at 08:24:45PM -0700, Peter Moody
wrote:
> I wrote something a lot like this when I was at uber
> 
>   https://github.com/pmoody-/pam-ussh
> 
> (the uber version is here: https://github.com/uber/pam-ussh)
Needing PAM auth via ssh-agent is not so uncommon and yet using sshd
is not necessarily the first (or best) solution to come to mind.

Having it available as part of openssh would be a useful bridgehead for
educating users towards better solutions, when available, and anyway
practically improve the security of the status quo.

Superior solutions are not very useful if not widely adopted.

Dom

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

> Having it available as part of openssh would be a useful bridgehead for
> educating users towards better solutions, when available, and anyway
> practically improve the security of the status quo.
I think that something like this might be a better fit in the
Linux-Pam repository.

Having done this before, my big worry was always, how does pam trust
the agent? being able to rw to an unix domain socket doesn't mean that
the ssh-agent at the other end is owned by the user calling sudo. It's
an approximation, and sometimes that approximation is (obviously)
fine. But it seems to me that for the general use-case, this is
stapling functionality to the agent that the protocol wasn't designed
to support.

anyway, my $0.02

Cheers,
peter

On 7/21/20 7:01 PM, Peter Moody wrote:
>> Having it available as part of openssh would be a useful bridgehead for
>> educating users towards better solutions, when available, and anyway
>> practically improve the security of the status quo.
> 
> I think that something like this might be a better fit in the
> Linux-Pam repository.
> 
> Having done this before, my big worry was always, how does pam trust
> the agent? being able to rw to an unix domain socket doesn't mean that
> the ssh-agent at the other end is owned by the user calling sudo. It's
> an approximation, and sometimes that approximation is (obviously)
> fine. But it seems to me that for the general use-case, this is
> stapling functionality to the agent that the protocol wasn't designed
> to support.
Agreed.

AFAICS the client also has to enable key agent forwarding. Isn't that a
risk too in case the server is hacked?

Ciao, Michael.

On Tue, Jul 21, 2020 at 10:01:04AM -0700, Peter Moody
wrote:
> > Having it available as part of openssh would be a useful bridgehead
for
> > educating users towards better solutions, when available, and anyway
> > practically improve the security of the status quo.
> 
> I think that something like this might be a better fit in the
> Linux-Pam repository.
> 
> Having done this before, my big worry was always, how does pam trust
> the agent? being able to rw to an unix domain socket doesn't mean that
Trusting the agent is the easy part, if it can sign the challenge.
It's trusting the user who's behind it that is difficult.
> the ssh-agent at the other end is owned by the user calling sudo. It's
Oh! Being sudo setuid, it could happily read whatever SSH_AUTH_SOCK a
malicious user would throw at it. Fantastic.
> an approximation, and sometimes that approximation is (obviously)
> fine. But it seems to me that for the general use-case, this is
> stapling functionality to the agent that the protocol wasn't designed
> to support.
Indeed in the plain ssh scenario, the ssh client runs with the user's
permissions.

In the PAM module context, the safest assumption is that the module
runs as root. How to ensure that a given SSH_AUTH_SOCK is really owned
by the user seeking authentication is totally different story.
> anyway, my $0.02
Quite useful to me. Thanks!

Dom

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