[otterley]

I think I need some more information. What I'd like to do is to have a signed certificate that only lets me into the "otterley" account on the remote host, while not letting "jsmith" into my account (only hers) or vice versa.

My understanding of CA principals is that they identify the user or role that requested the signing, but not necessarily the login ID on the server that is allowed to be logged into. Ideally there'd be a 1:1 mapping between the principal and the login ID on the server. I think there's some sshd configuration that needs to be done, but I haven't seen any clear instructions for doing so.

Do you know how to accomplish this?

[e12e]

Have a look at eg:

https://linux-audit.com/granting-temporary-access-to-servers...

And re-read the (imnho rather obtuse) ssh-keygen man pages.

[ed: and maybe this too: https://framkant.org/2017/07/scalable-access-control-using-o... ]

[otterley]

Thanks! So it looks like AuthorizedPrincipalsFile/AuthorizedPrincipalsCommand gives us a method for doing this. This would have to be combined with some sort of user ID management system still, like distribution of /etc/{passwd,group} files, LDAP/AD, etc.

[e12e]

There's also: https://github.com/uber/pam-ussh/blob/master/README.md

https://medium.com/uber-security-privacy/introducing-the-ube...

And for the ssh ca part, bless and teleport (as others have mentioned).

There's the option of putting stuff in ad/ldap - but if you're already using ad, kerberized ssh (and sudo etc) might be the way to go.

I like the idea of a system that's simpler than ad/ldap+kerberos - and ssh certs fits most of the bill.

The challenge becomes auth/authz beyond just login - ldap basically requires ssl ca anyway - and at that point, especially with kerberos set up - I think one might be better off sticking with one complex auth/authz system rather than two...

At least it should be possible to avoid passwords with something like: https://wiki.freeradius.org/guide/2FA-Active-Directory-plus-...