Mailing List Archive: SSH certificates - restricting to host groups

SSH certificates - restricting to host groups

b.candler at pobox

Jan 30, 2020, 4:27 AM

Post #1 of 23 (836 views)

Hello,

I am trying to work out the best way to issue SSH certificates in such
way that they only allow access to specific usernames *and* only to
specific groups of host.

As a concrete example: I want Alice to be able to login as "alice" and
"www" to machines in group "webserver" (only). Also, I want Bob to be
able to login as "bob" and "www" to machines in group "webserver" (only).

I have been through the ssh-keygen and sshd_config manpages, and various
blog postings, in particular Facebook's one here:
<https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/>.
However, if I issue certs with

ssh-keygen ... -n alice,www,group-webserver ...

ssh-keygen ... -n bob,www,group-webserver ...

and I include "group-webserver" in AuthorizedPrincipalsFile for alice,
it lets bob login as alice (as per documentation, and also tested).

Now I am thinking I need to do something like this:

ssh-keygen ... -n alice:webserver,www:webserver ...

ssh-keygen ... -n bob:webserver,www:webserver ...

with an AuthorizedPrincipalsCommand such as:

#!/bin/sh
echo "$1:webserver"
echo "$1:anywhere"

Is this the best approach, or am I missing a trick? I'm surprised I
couldn't find someone had already done this and blogged about it.

Thanks,

Brian.

P.S. A minor clarification for the documentation: if
AuthorizedPrincipalsFile does not exist, or is empty, it wasn't
immediately clear to me if ssh falls back to the same as
"AuthorizedPrincipalsFile none", or rejects all access. By
experimentation, it rejects all access, which is very reasonable - but
it might be worth a mention nonetheless.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

michael at stroeder

Jan 30, 2020, 4:53 AM

Post #2 of 23 (836 views)

On 1/30/20 1:27 PM, Brian Candler wrote:
> I am trying to work out the best way to issue SSH certificates in such
> way that they only allow access to specific usernames *and* only to
> specific groups of host.

I also thought about this for a while. The only idea I came up with is
to have separate CAs used as trust anchor for each host group. But it
was not urgent for me because I have an authorization based on host
groups enforced by the user management anyway.

> Now I am thinking I need to do something like this:
> ssh-keygen ... -n alice:webserver,www:webserver ...
> ssh-keygen ... -n bob:webserver,www:webserver ...
> with an AuthorizedPrincipalsCommand such as:
>
> #!/bin/sh
> echo "$1:webserver"
> echo "$1:anywhere"

Haven't though about using a specific AuthorizedPrincipalsCommand script.

But the other big question is the usability of the process for issuing
and using the OpenSSH user certs. What's your idea on this?

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

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 30, 2020, 5:16 AM

Post #3 of 23 (836 views)

On 30/01/2020 12:53, Michael Ströder wrote:
> On 1/30/20 1:27 PM, Brian Candler wrote:
>> I am trying to work out the best way to issue SSH certificates in such
>> way that they only allow access to specific usernames*and* only to
>> specific groups of host.
> I also thought about this for a while. The only idea I came up with is
> to have separate CAs used as trust anchor for each host group.

I did think of that, and discounted it as being too ugly :-)

I also thought about using extensions in the user cert - but I couldn't
see a way to get sshd to require the presence of a particular extension
to permit login.

>
> But the other big question is the usability of the process for issuing
> and using the OpenSSH user certs. What's your idea on this?

I hadn't got to the details of the user side, but AFAICS all it requires
is a list of user:hostgroup principals to include in the cert for a
given user. This could be kept directly as an attribute of the user, or
you could generate it via a level of indirection (user -> group; group
-> list of principals or principal suffixes)

At the host side, I was thinking of authorizing principals based on the
machine's "role" in Netbox, which we use as inventory database:

#!/bin/sh
echo "$1:{{ device_role }}"
echo "$1:all"

Regards,

Brian.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

manoel.domingues.junior at gmail

Jan 30, 2020, 5:31 AM

Post #4 of 23 (836 views)

Hi,

I think that adding an extension to the certificate as it is done for
source-address validation can be one way.

Currently, as it is necessary to support different versions of OpenSSH, we
have developed GSH that uses AuthorizedPrincipalsCommand to validate
whether the certificate was issued to the destination in question. You can
add a script at AuthorizedPrincipalsCommand to validate an extension.

GSH: https://github.com/globocom/gsh

Regards,

Em qui, 30 de jan de 2020 às 10:16, Brian Candler <b.candler@pobox.com>
escreveu:

> On 30/01/2020 12:53, Michael Ströder wrote:
> > On 1/30/20 1:27 PM, Brian Candler wrote:
> >> I am trying to work out the best way to issue SSH certificates in such
> >> way that they only allow access to specific usernames*and* only to
> >> specific groups of host.
> > I also thought about this for a while. The only idea I came up with is
> > to have separate CAs used as trust anchor for each host group.
>
> I did think of that, and discounted it as being too ugly :-)
>
> I also thought about using extensions in the user cert - but I couldn't
> see a way to get sshd to require the presence of a particular extension
> to permit login.
>
> >
> > But the other big question is the usability of the process for issuing
> > and using the OpenSSH user certs. What's your idea on this?
>
> I hadn't got to the details of the user side, but AFAICS all it requires
> is a list of user:hostgroup principals to include in the cert for a
> given user. This could be kept directly as an attribute of the user, or
> you could generate it via a level of indirection (user -> group; group
> -> list of principals or principal suffixes)
>
> At the host side, I was thinking of authorizing principals based on the
> machine's "role" in Netbox, which we use as inventory database:
>
> #!/bin/sh
> echo "$1:{{ device_role }}"
> echo "$1:all"
>
> Regards,
>
> Brian.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
--
Manoel Domingues Junior
https://keybase.io/mdjunior
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: SSH certificates - restricting to host groups [ In reply to ]

mark.christian at intel

Jan 30, 2020, 7:02 AM

Post #5 of 23 (836 views)

On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote:
> As a concrete example: I want Alice to be able to login as "alice"
> and
> "www" to machines in group "webserver" (only). Also, I want Bob to
> be
> able to login as "bob" and "www" to machines in group "webserver"
> (only).

Why can't you have a AuthorizedPrincipalsFile for alice, bob and www on
each of the "web servers", where the contents of the alice file include
the principal name alice, the contents of the bob file contain the bob
principal, and the contents of the www file contain the contents alice
and bob? Wouldn't that allow alice to ssh as alice, and www, and allow
bob to ssh as bob and www to any machines that had this
authorizedPrincipals file configuration?

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

Re: SSH certificates - restricting to host groups [ In reply to ]

michael at stroeder

Jan 30, 2020, 8:05 AM

Post #6 of 23 (836 views)

On 1/30/20 2:16 PM, Brian Candler wrote:
> On 30/01/2020 12:53, Michael Ströder wrote:
>> But the other big question is the usability of the process for issuing
>> and using the OpenSSH user certs. What's your idea on this?
>
> I hadn't got to the details of the user side, but AFAICS all it requires
> is a list of user:hostgroup principals to include in the cert for a
> given user. This could be kept directly as an attribute of the user, or
> you could generate it via a level of indirection (user -> group; group
> -> list of principals or principal suffixes)

Adding authz information to user certs means that you need to renew the
cert if the authz information changes during cert life-time. This can be
annoying for users.

How long should your user certs be valid?

You have to maintain this user-hostgroup relationship somewhere. Is it
possible for your system to query this information?

YMMV.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 30, 2020, 8:23 AM

Post #7 of 23 (830 views)

On 30/01/2020 13:31, Manoel Domingues Junior wrote:
> I think that adding an extension to the certificate as it is done for
> source-address validation can be one way.
>
> Currently, as it is necessary to support different versions of OpenSSH, we
> have developed GSH that uses AuthorizedPrincipalsCommand to validate
> whether the certificate was issued to the destination in question. You can
> add a script at AuthorizedPrincipalsCommand to validate an extension.
>
> GSH:https://github.com/globocom/gsh

I wondered about that, but I couldn't see how
AuthorizedPrincipalsCommand could get access to the extensions. Looking
at the latest OpenBSD manpage, I see that %k token has been added (for
the entire base64-encoded certificate). That will solve the problem
once other distros pick this up; Ubuntu 18.04 doesn't have %k.

Thanks also for the pointer to gsh. I see:

AuthorizedPrincipalsCommand /usr/local/bin/gsh-agent check-permission
--serial-number %s --username %u --api https://gsh-api.example.com
--key-id %i --key-fingerprint %f --certificate %k --certificate-type %t

I would therefore expect that if you're using an older version of SSH
(without %k) that it would have to query the API to find the extensions.
That would make it a critical service, much like LDAP would be.

Regards,

Brian.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 30, 2020, 8:37 AM

Post #8 of 23 (830 views)

On 30/01/2020 15:02, Christian, Mark wrote:
> On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote:
>> As a concrete example: I want Alice to be able to login as "alice"
>> and
>> "www" to machines in group "webserver" (only). Also, I want Bob to
>> be
>> able to login as "bob" and "www" to machines in group "webserver"
>> (only).
> Why can't you have a AuthorizedPrincipalsFile for alice, bob and www on
> each of the "web servers", where the contents of the alice file include
> the principal name alice, the contents of the bob file contain the bob
> principal, and the contents of the www file contain the contents alice
> and bob? Wouldn't that allow alice to ssh as alice, and www, and allow
> bob to ssh as bob and www to any machines that had this
> authorizedPrincipals file configuration?

Yes, that would work, but then it comes back down to configuration
management to push out all authorizations (and more importantly, remove
them when no longer authorized). If you're going to do that, it's not
too far removed from pushing out ~/.ssh/authorized_keys for each user.

I was hoping to avoid the dependency on configuration management by
carrying the authorization in the certs themselves - if that is in the
spirit of the SSH cert mechanism.

On 30/01/2020 16:05, Michael Ströder wrote:
> Adding authz information to user certs means that you need to renew the
> cert if the authz information changes during cert life-time. This can be
> annoying for users.
>
> How long should your user certs be valid?

I think on an initial implementation I'd go with 3-month certs, perhaps
using a PKCS#11 token like a Yubikey. You're right that if we have to
change the authorization for a user, they'd need a new cert.

Eventually it would be nice to move to daily certs with online login
(e.g. cashier, step-ca) in which case anyone who needs a new cert can
get it themselves instantly. The main thing stopping me from doing this
straight away is your other point:

> You have to maintain this user-hostgroup relationship somewhere. Is it
> possible for your system to query this information?

The inventory system tracks hosts rather than users, but I don't see a
big problem putting the user-group relationship into LDAP, even if it
only writes out a flat file periodically.

However, the system which issues the certs needs to be able to do the
mapping from OIDC claims to SSH cert principals. I've just been looking
at step-ca and I don't see a way to do that. I haven't looked at
cashier yet, and I only just learned of gsh.

Regards,

Brian.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

mindrot at hda3

Jan 30, 2020, 8:41 AM

Post #9 of 23 (830 views)

On Thu, Jan 30, 2020 at 7:11 AM Christian, Mark
<mark.christian@intel.com> wrote:
>
> On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote:
> > As a concrete example: I want Alice to be able to login as "alice"
> > and
> > "www" to machines in group "webserver" (only). Also, I want Bob to
> > be
> > able to login as "bob" and "www" to machines in group "webserver"
> > (only).
>
> Why can't you have a AuthorizedPrincipalsFile for alice, bob and www on
> each of the "web servers", where the contents of the alice file include
> the principal name alice, the contents of the bob file contain the bob
> principal, and the contents of the www file contain the contents alice
> and bob? Wouldn't that allow alice to ssh as alice, and www, and allow
> bob to ssh as bob and www to any machines that had this
> authorizedPrincipals file configuration?

this is the right answer. you want to use AuthorizedPrincipalsFile (or
AuthorizedPrincipalsCommand if your authz information needs to change
on a quicker cadence than your config pushes) on the machines.

you'd have something like

$ cat /etc/ssh/sshd_config

<snip>
TrustedUserCAKeys /etc/ssh/TrustedUserCAKeys

Match User www
AuthorizedKeysFile /etc/ssh/empty
AuthorizedPrincipalsFile /etc/ssh/www_authorizedPrincipals
<snip>

$ cat /etc/ssh/www_authorized_principals
alice
bob

and alice and bob just have regular user certificates with 'alice' or
'bob' in the princpals
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 30, 2020, 8:45 AM

Post #10 of 23 (830 views)

On 30/01/2020 16:41, Peter Moody wrote:
> this is the right answer. you want to use AuthorizedPrincipalsFile (or
> AuthorizedPrincipalsCommand if your authz information needs to change
> on a quicker cadence than your config pushes) on the machines.
>
> you'd have something like
>
> $ cat /etc/ssh/sshd_config
>
> <snip>
> TrustedUserCAKeys /etc/ssh/TrustedUserCAKeys
>
> Match User www
> AuthorizedKeysFile /etc/ssh/empty
> AuthorizedPrincipalsFile /etc/ssh/www_authorizedPrincipals
> <snip>
>
> $ cat /etc/ssh/www_authorized_principals
> alice
> bob
>
> and alice and bob just have regular user certificates with 'alice' or
> 'bob' in the princpals

But that doesn't solve the other part of my problem, which is that alice
and bob's certificates should only be usable for logging in to a
specific group of hosts - even as their own username "alice" or "bob".

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

Re: SSH certificates - restricting to host groups [ In reply to ]

mark.christian at intel

Jan 30, 2020, 8:48 AM

Post #11 of 23 (830 views)

On Thu, 2020-01-30 at 16:37 +0000, Brian Candler wrote:
> On 30/01/2020 15:02, Christian, Mark wrote:
>
> > On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote:
> > > As a concrete example: I want Alice to be able to login as
> > > "alice"
> > > and
> > > "www" to machines in group "webserver" (only). Also, I want Bob
> > > to
> > > be
> > > able to login as "bob" and "www" to machines in group "webserver"
> > > (only).
> >
> > Why can't you have a AuthorizedPrincipalsFile for alice, bob and
> > www on
> > each of the "web servers", where the contents of the alice file
> > include
> > the principal name alice, the contents of the bob file contain the
> > bob
> > principal, and the contents of the www file contain the contents
> > alice
> > and bob? Wouldn't that allow alice to ssh as alice, and www, and
> > allow
> > bob to ssh as bob and www to any machines that had this
> > authorizedPrincipals file configuration?
>
> Yes, that would work, but then it comes back down to configuration
> management to push out all authorizations (and more importantly,
> remove them when no longer authorized). If you're going to do that,
> it's not too far removed from pushing out ~/.ssh/authorized_keys for
> each user.
>
>
> I was hoping to avoid the dependency on configuration management by
> carrying the authorization in the certs themselves - if that is in
> the spirit of the SSH cert mechanism.
>

Sign alice and bob's ssh cert with principal's alice,www and bob,www
respectively. Configure sshd_config so that individuals don't require
an authorizedprincipalfile, and use Match within sshd_config for any
"service/faceless" account like www, to force use of an
authorizedprincipalfile. The contents of www's authorizedprincipal
file will simply contain the principal "www" or whatever you
choose. This should limit configuration mgmt dependency.

However, when alice is no longer authorized, and assuming her cert is
still valid, you're going to want to use some configuration mgmt to
manage RevokedKeys, otherwise ensure that alice's cert is valid for a
short period of time.

Mark

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

Re: SSH certificates - restricting to host groups [ In reply to ]

mark.christian at intel

Jan 30, 2020, 8:52 AM

Post #12 of 23 (830 views)

On Thu, 2020-01-30 at 16:45 +0000, Brian Candler wrote:
> On 30/01/2020 16:41, Peter Moody wrote:
> > this is the right answer. you want to use AuthorizedPrincipalsFile
> > (or
> > AuthorizedPrincipalsCommand if your authz information needs to
> > change
> > on a quicker cadence than your config pushes) on the machines.
> >
> > you'd have something like
> >
> > $ cat /etc/ssh/sshd_config
> >
> > <snip>
> > TrustedUserCAKeys /etc/ssh/TrustedUserCAKeys
> >
> > Match User www
> > AuthorizedKeysFile /etc/ssh/empty
> > AuthorizedPrincipalsFile /etc/ssh/www_authorizedPrincipals
> > <snip>
> >
> > $ cat /etc/ssh/www_authorized_principals
> > alice
> > bob
> >
> > and alice and bob just have regular user certificates with 'alice'
> > or
> > 'bob' in the princpals
>
> But that doesn't solve the other part of my problem, which is that
> alice
> and bob's certificates should only be usable for logging in to a
> specific group of hosts - even as their own username "alice" or
> "bob".

AllowGroups, AllowUsers in sshd_config. /etc/security/access.conf or
equivalent. These are the ways to limit access to systems where bob
and alice are not authorized.

Mark

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

Re: SSH certificates - restricting to host groups [ In reply to ]

mindrot at hda3

Jan 30, 2020, 9:02 AM

Post #13 of 23 (830 views)

On Thu, Jan 30, 2020 at 8:45 AM Brian Candler <b.candler@pobox.com> wrote:
>
> On 30/01/2020 16:41, Peter Moody wrote:
> > this is the right answer. you want to use AuthorizedPrincipalsFile (or
> > AuthorizedPrincipalsCommand if your authz information needs to change
> > on a quicker cadence than your config pushes) on the machines.
> >
> > you'd have something like
> >
> > $ cat /etc/ssh/sshd_config
> >
> > <snip>
> > TrustedUserCAKeys /etc/ssh/TrustedUserCAKeys
> >
> > Match User www
> > AuthorizedKeysFile /etc/ssh/empty
> > AuthorizedPrincipalsFile /etc/ssh/www_authorizedPrincipals
> > <snip>
> >
> > $ cat /etc/ssh/www_authorized_principals
> > alice
> > bob
> >
> > and alice and bob just have regular user certificates with 'alice' or
> > 'bob' in the princpals
>
>
> But that doesn't solve the other part of my problem, which is that alice
> and bob's certificates should only be usable for logging in to a
> specific group of hosts - even as their own username "alice" or "bob".

on any machine that has those two snippets above, 'alice' and 'bob'
will be able to log in as 'www'. If user accounts for 'alice' and
'bob' exist on those same machines, 'alice' and 'bob' will be able to
log in as only 'alice' and 'bob' respectively (ie, a certificate with
'alice' can be used to authenticate as the alice user and a
certificate with 'bob' can be used to authenticate as the 'bob' user).

the posix user accounts don't need to exist on a given machine to use
the AuthorizedPrincipalsFile/AuthorizedPrincipalsCommand for logging
in as a shared user. If you're saying that you don't want 'alice' or
'bob' to be able to log into the webserver machines as alice or bob,
then don't create those accounts, but they can still use their
certificates with the AuthorizedPrincipalsFile to get access to www
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 30, 2020, 9:06 AM

Post #14 of 23 (830 views)

On 30/01/2020 16:48, Christian, Mark wrote:
> > However, when alice is no longer authorized, and assuming her cert is
> > still valid, you're going to want to use some configuration mgmt to
> > manage RevokedKeys, otherwise ensure that alice's cert is valid for a
> > short period of time.

Indeed: I was intending to use a cronjob to fetch a CRL, as suggested at

https://github.com/nsheridan/cashier#revoking-certificates

> AllowGroups, AllowUsers in sshd_config. /etc/security/access.conf or
> equivalent. These are the ways to limit access to systems where bob
> and alice are not authorized.

So if I understand you correctly, you're saying "SSH certificates are not intended to be used to carry authorization information".

In general, there is a sound argument for keeping authentication separate from authorization. On the other hand, it does make me wonder why there is support for multiple principals in one SSH certificate.

Regards,

Brian.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

mark.christian at intel

Jan 30, 2020, 9:14 AM

Post #15 of 23 (830 views)

On Thu, 2020-01-30 at 17:06 +0000, Brian Candler wrote:
> On 30/01/2020 16:48, Christian, Mark wrote:
> > > However, when alice is no longer authorized, and assuming her
> > > cert is
> > > still valid, you're going to want to use some configuration mgmt
> > > to
> > > manage RevokedKeys, otherwise ensure that alice's cert is valid
> > > for a
> > > short period of time.
>
> Indeed: I was intending to use a cronjob to fetch a CRL, as suggested
> at
>
> https://github.com/nsheridan/cashier#revoking-certificates
>
>
> > AllowGroups, AllowUsers in sshd_config. /etc/security/access.conf
> > or
> > equivalent. These are the ways to limit access to systems where
> > bob
> > and alice are not authorized.
>
> So if I understand you correctly, you're saying "SSH certificates are
> not intended to be used to carry authorization information".

No, SSH certificates can be a perfectly suitable authorization
solution, but that doesn't mean you shouldn't also use the other
authorization mechanisms at your disposal. You have plenty of options.
Nothing says that your entire authorization scheme must take place
within openssh. Leverage PAM, use access.conf. Get creative.

Mark

>
> In general, there is a sound argument for keeping authentication
> separate from authorization. On the other hand, it does make me
> wonder why there is support for multiple principals in one SSH
> certificate.
>
> Regards,
>
> Brian.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: SSH certificates - restricting to host groups [ In reply to ]

Jan 30, 2020, 3:06 PM

Post #16 of 23 (830 views)

On Thu, 30 Jan 2020, Christian, Mark wrote:

> However, when alice is no longer authorized, and assuming her cert is
> still valid, you're going to want to use some configuration mgmt to
> manage RevokedKeys, otherwise ensure that alice's cert is valid for a
> short period of time.

AFAIK most organisations that use ssh certificates give them short
(~1 day) lifetimes to avoid the risk of lingering authority, but it's
still useful to have a tested revocation path for the odd case where
you actively need to kill a key/cert.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

michael at stroeder

Jan 31, 2020, 6:29 AM

Post #17 of 23 (830 views)

On 1/30/20 5:48 PM, Christian, Mark wrote:
> On Thu, 2020-01-30 at 16:37 +0000, Brian Candler wrote:
>> I was hoping to avoid the dependency on configuration management by
>> carrying the authorization in the certs themselves - if that is in
>> the spirit of the SSH cert mechanism.
>
> Sign alice and bob's ssh cert with principal's alice,www and bob,www
> respectively. Configure sshd_config so that individuals don't require
> an authorizedprincipalfile, and use Match within sshd_config for any
> "service/faceless" account like www, to force use of an
> authorizedprincipalfile. The contents of www's authorizedprincipal
> file will simply contain the principal "www" or whatever you
> choose. This should limit configuration mgmt dependency.

Hmm, personally I'd recommend not to issue user certs for generic user
names (e.g. "www"). While some cert information is logged by sshd it
requires keeping track of all issued certs in searchable data store to
be able to properly map logins to personal user accounts during an audit.

> However, when alice is no longer authorized, and assuming her cert is
> still valid, you're going to want to use some configuration mgmt to
> manage RevokedKeys, otherwise ensure that alice's cert is valid for a
> short period of time.

Again this requires to keep track of issued certs which need revocation
in case the authorization changes. Sounds too complicated to me.

=> Use a decent user management (not config management) for managing
authorization based on user and host groups.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 31, 2020, 6:52 AM

Post #18 of 23 (830 views)

On 31/01/2020 14:29, Michael Ströder wrote:
> Hmm, personally I'd recommend not to issue user certs for generic user
> names (e.g. "www"). While some cert information is logged by sshd it
> requires keeping track of all issued certs in searchable data store to
> be able to properly map logins to personal user accounts during an audit.

I thought that was the point of the certificate "identity" (-I) in
addition to the "principals" (-n). The login shows the certificate
identity:

Jan 30 11:50:49 test1 sshd[4757]: Accepted publickey for alice from
2001_db8::2009 port 56943 ssh2: RSA-CERT ID brian (serial 1) CA RSA
SHA256:fofx2XMj+RqnLlui09aDIuV9fWqPiU54oWStDzYr/p0

In this case, the cert identity was "brian"; cert principals were
"alice" and "www"; ssh login was as user "alice".

It's still a good idea to keep track of all issued certs though, in case
you need to revoke one.

Regards,

Brian.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

michael at stroeder

Jan 31, 2020, 7:37 AM

Post #19 of 23 (830 views)

On 1/30/20 5:37 PM, Brian Candler wrote:
> On 30/01/2020 16:05, Michael Ströder wrote:
>> Adding authz information to user certs means that you need to renew the
>> cert if the authz information changes during cert life-time. This can be
>> annoying for users.
>>
>> How long should your user certs be valid?
>
> I think on an initial implementation I'd go with 3-month certs, perhaps
> using a PKCS#11 token like a Yubikey. You're right that if we have to
> change the authorization for a user, they'd need a new cert.

That's a pretty long period. So you MUST deal with decent revocation
leading to lots of nasty user-facing processes.

While on the server-side you might have the simple idea for the usual
wget CRON job you would have to monitor whether it functions correctly
on each target system. After all revocation is then a critical part of
your access control.

Furthermore you have to deal with informing the user about having to get
a new updated cert. But the client-side information is pretty terse. For
the user the SSH login just fails. And you have to get rid of stale key
pairs in ssh-agent. Otherwise you might hit MaxAuthTries limit.
Personally I cannot imagine how you want to implement all this with a
decent UX to avoid support requests.

(BTW: yubikey is slow. So if you have admins accessing many machines in
one go you will get a notable latency during first SSH connection.)

> Eventually it would be nice to move to daily certs with online login
> (e.g. cashier, step-ca) in which case anyone who needs a new cert can
> get it themselves instantly. The main thing stopping me from doing this
> straight away is your other point:
>
>> You have to maintain this user-hostgroup relationship somewhere. Is it
>> possible for your system to query this information?
>
> The inventory system tracks hosts rather than users, but I don't see a
> big problem putting the user-group relationship into LDAP, even if it
> only writes out a flat file periodically.
>
> However, the system which issues the certs needs to be able to do the
> mapping from OIDC claims to SSH cert principals.

After reviewing many of the existing SSH-CA implementations for issuing
short-term user certs I've implemented my own (client and server). The
main reason was I wanted to be able to adapt it to whatever requirement
I will have in the future for integrating it with the customer's user
management (and my own LDAP-based user management).

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

Re: SSH certificates - restricting to host groups [ In reply to ]

michael at stroeder

Jan 31, 2020, 7:54 AM

Post #20 of 23 (830 views)

On 1/31/20 3:52 PM, Brian Candler wrote:
> On 31/01/2020 14:29, Michael Ströder wrote:
>> Hmm, personally I'd recommend not to issue user certs for generic user
>> names (e.g. "www"). While some cert information is logged by sshd it
>> requires keeping track of all issued certs in searchable data store to
>> be able to properly map logins to personal user accounts during an audit.
>
> I thought that was the point of the certificate "identity" (-I) in
> addition to the "principals" (-n). The login shows the certificate
> identity:
>
> Jan 30 11:50:49 test1 sshd[4757]: Accepted publickey for alice from
> 2001_db8::2009 port 56943 ssh2: RSA-CERT ID brian (serial 1) CA RSA
> SHA256:fofx2XMj+RqnLlui09aDIuV9fWqPiU54oWStDzYr/p0
>
> In this case, the cert identity was "brian"; cert principals were
> "alice" and "www"; ssh login was as user "alice".

Ah, ok. Description of semantics in ssh-keygen(1) is not really clear so
currently I've just set a UUID for each new key pair. But I could prefix
this with a user name.

> It's still a good idea to keep track of all issued certs though, in case
> you need to revoke one.

Or better get rid of the revocation requirement. ;-)

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

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 31, 2020, 8:21 AM

Post #21 of 23 (830 views)

On 31/01/2020 15:37, Michael Ströder wrote:
> (BTW: yubikey is slow. So if you have admins accessing many machines in
> one go you will get a notable latency during first SSH connection.)

I meant using a single Yubikey as the CA sign the certificates.

I'm thinking of an organization where the number of admins is in the low
tens. The end-game of having daily keys and certs loaded directly into
ssh-agent is very appealing, but I'm not sure we're ready to jump right
there yet. Getting people over to certs and starting to rip out
~/.ssh/authorized_keys is an important first step.

As for the freshness of the CRL file: this is something we can easily
monitor and alert on in prometheus.

Regards,

Brian.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

michael at stroeder

Jan 31, 2020, 8:47 AM

Post #22 of 23 (830 views)

On 1/31/20 5:21 PM, Brian Candler wrote:
> On 31/01/2020 15:37, Michael Ströder wrote:
>> (BTW: yubikey is slow. So if you have admins accessing many machines in
>> one go you will get a notable latency during first SSH connection.)
>
> I meant using a single Yubikey as the CA sign the certificates.

Ah, I've misread that. Just using temporary key/cert files makes things
easier at the client side.

> I'm thinking of an organization where the number of admins is in the low
> tens. The end-game of having daily keys and certs loaded directly into
> ssh-agent is very appealing, but I'm not sure we're ready to jump right
> there yet. Getting people over to certs and starting to rip out
> ~/.ssh/authorized_keys is an important first step.

I'm not sure I get your reasoning why having longer cert validity period
makes things easier for the user. IMHO the opposite is true.

If your installation just works on all required OS platforms (client and
server) it's pretty easy to teach people how to use it to get a
short-term user cert once or twice a day. Anyway they have to be capable
to do this at any time no matter how long the cert validity period is.

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

Re: SSH certificates - restricting to host groups [ In reply to ]

b.candler at pobox

Jan 31, 2020, 9:10 AM

Post #23 of 23 (830 views)

On 31/01/2020 16:47, Michael Ströder wrote:
> I'm not sure I get your reasoning why having longer cert validity period
> makes things easier for the user. IMHO the opposite is true.

I wasn't saying it was easier for users - only as part of a potential
migration strategy.

Today, people use private keys stored on their hard drives, and
~/.ssh/authorized_keys on remote host. So the plan I currently have in
my head is:

Step 1: turn on cert authentication with an offline manual CA. Start
using it for automated processes. (My primary driver for rolling out
certs is to avoid installing an ansible master key in
/root/.ssh/authorized_keys on all servers; instead I will roll out
TrustedUserCAKeys)

Step 2: give end users a manually-issued medium-lifetime cert to sit
alongside their existing private key.

Step 3: start ripping out ~/.ssh/authorized_keys, and deal with the
breakage (e.g. finding hidden automated processes which rely on static
keys, and replace them with certs)

Step 4: build and roll out the infrastructure for issuing short-lived
user keys and certs dynamically

Somewhere along the line: do the signing of host keys. (Probably as
part of step 1, as I have to push out the new ssh configs anyway).

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