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.
Manoel Domingues Junior
2020-Jan-30 13:31 UTC
SSH certificates - restricting to host groups
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 at 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 at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >-- Manoel Domingues Junior https://keybase.io/mdjunior
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.
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/gshI 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.