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.
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.
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.
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
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.
On Thu, Jan 30, 2020 at 7:11 AM Christian, Mark <mark.christian at 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