Mailing List Archive

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)


On Mon, Jul 20, 2020 at 6:29 PM Domenico Andreoli <cavokz@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.
>
> The principle is originally implemented by an existing module [0][1]
> and many pages that explain how to use it for such purpose can be
> found online.
>
>
> Why then this new implementation?
>
> A few reasons:
> - it's way smaller, more simple and easier to audit
> - it wants to remain as such
> - it reuses everything from openssh-portable; no novel, outdated or
> alternative crypto implementations
> - it's based on openssh-portable so it supports all the algorithms that
> ssh-agent does (eg. ecdsa-sk, ed25519-sk, pkcs#11, ... yuk!)
>
>
> Now, the natural place for this, I think, is right with openssh-portable.
>
> Is there, maybe, by any chance, a way to merge it there?
>
> This is a critical piece of software for those who use it and needs
> to be well guarded. It has super healthy tests, the maintenance effort
> can reimain low and easy.
>
>
> A few things that are missing:
> - man page
> - installation
> - support for multiple keys in the auth file
>
>
> I'm also asking to the Linux PAM people to double-check my usage of PAM.
>
> Regards,
> Domenico
>
> [0] https://github.com/jbeverly/pam_ssh_agent_auth
> [1] https://sourceforge.net/projects/pamsshagentauth/
>
> --
> rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
> ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, Jul 20, 2020 at 9:28 PM Domenico Andreoli <cavokz@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".

> The principle is originally implemented by an existing module [0][1]
> and many pages that explain how to use it for such purpose can be
> found online.
>
>
> Why then this new implementation?
>
> A few reasons:
> - it's way smaller, more simple and easier to audit
> - it wants to remain as such
> - it reuses everything from openssh-portable; no novel, outdated or
> alternative crypto implementations
> - it's based on openssh-portable so it supports all the algorithms that
> ssh-agent does (eg. ecdsa-sk, ed25519-sk, pkcs#11, ... yuk!)

Or you can avoid sudo altogether and keep it quite auditable by using
public key based access for the target accounts.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 21/07/2020 05:46, Nico Kadel-Garcia wrote:
> On Mon, Jul 20, 2020 at 9:28 PM Domenico Andreoli<cavokz@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".
>
I don't think the target user requires access to the agent socket - that
is, it's normal to be able to sudo from user A to user B, without being
able to sudo in turn from user B to user C.  In the case where user B is
a daemon account, it probably has no sudo rights anyway.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@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?

Dom

--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, Jul 21, 2020 at 09:20:50AM +0100, Brian Candler wrote:
> On 21/07/2020 05:46, Nico Kadel-Garcia wrote:
> > On Mon, Jul 20, 2020 at 9:28 PM Domenico Andreoli<cavokz@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".
> >
> I don't think the target user requires access to the agent socket - that is,
> it's normal to be able to sudo from user A to user B, without being able to
> sudo in turn from user B to user C.? In the case where user B is a daemon
> account, it probably has no sudo rights anyway.
>

I use sudo to become root, the socket permissions are not an issue. When
I want to switch to another user, I use 'sudo su -'. Again, no issue
with the permissions.

Thanks to Nico I discovered that if I have sshd, sudo is really not needed.

Said that, I've just realized the my module is still useful in those
situations where you don't have sshd.

Does it add any value providing it for such cases?

Dom

--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, Jul 21, 2020 at 07:38:42PM +0200, Domenico Andreoli wrote:
> 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.

The only way I see to not allow any priviledge escalation is by checking
the owner and permissions of both socket and auth file.

Both need to be writable only to their owner. The socket needs to be
owned by the real user, not the effective one. The auth file needs to
be owned by the target user, the one pointed by PAM_USER, that the user
attempting the authentication intends to become.

Dom

--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@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".

Can sshd cache the credentials as sudo does? Or should I push the button
of my Solo key every single time I want to become root?

> > The principle is originally implemented by an existing module [0][1]
> > and many pages that explain how to use it for such purpose can be
> > found online.
> >
> >
> > Why then this new implementation?
> >
> > A few reasons:
> > - it's way smaller, more simple and easier to audit
> > - it wants to remain as such
> > - it reuses everything from openssh-portable; no novel, outdated or
> > alternative crypto implementations
> > - it's based on openssh-portable so it supports all the algorithms that
> > ssh-agent does (eg. ecdsa-sk, ed25519-sk, pkcs#11, ... yuk!)
>
> Or you can avoid sudo altogether and keep it quite auditable by using
> public key based access for the target accounts.

sudo is not going away any time soon and neither ssh-agent, they need
to coexist in the same toolbox and play well together.

Dom

--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, 2020-07-21 at 03:06 +0200, Domenico Andreoli 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.
>
> The principle is originally implemented by an existing module [0][1]
> and many pages that explain how to use it for such purpose can be
> found online.

I really like this idea of pam_ssh_agent_auth living inside of openssh
repository. We are building these two together in Fedora and RHEL for
ages, mostly for the feature-parity.

Regards,
--
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev