Am I missing something here or shouldn’t I be just a touch leary of getting Google in the middle of my ssh SSO?
Hey there. I’m the author of this blog. It’s a good question.
Google doesn’t even know that your CA exists. For them, it’s just another OAuth login.
What you’re trusting is the security of Google’s OAuth sign-in flow. Specifically, Google’s role is to authenticate your users and issue signed identity tokens to them. Your CA then verifies those tokens—making sure they were signed by Google—and issues SSH certificates.
If you have more specific concerns, I’d love to address them.
BTW, you could use any OpenID Connect provider you like. It’s a small config change to use a different provider. You could even run your own OIDC provider, but we used Google in our example because a lot of organizations use G Suite.
Well that’d depend on your threat model :).
Google isn’t a requirement here. It’s using OAuth OIDC. There are lots of other identity providers that support OAuth OIDC, including open source stuff that you can run yourself.
If you just want certificate-based SSH you don’t even need to use single sign-on. There are a bunch of other ways to get certificates from step-ca.
This has a whole boat load of prerequisites - including client side, and conveniently ignores that the vast majority of the issues it identifies with regular ssh keys, are solved by just plugging ssh and Pam into ldap.
But I guess it wouldn’t be a sales blog if they highlighted a better alternative than their own service would it.
This came up last time we posted about SSH certificates. LDAP + GSSAPI or something similar is a viable option, but it has way more prerequisites. Including stuff like DNSSEC.
The only client-side prerequisites here are that you have an OAuth OIDC identity provider (which most already have) and you’ve installed the open source step binary client-side. Then you need to run step-ca. It’s just barely non-trivial.
LDAP doesn’t actually solve all of the problems that certificates solve, like eliminating trust on first use and host key verification failure. There are other mechanisms you can use alongside LDAP to achieve similar results, but they’re at least as complicated. In fact, if you already have LDAP, using it for user lifecycle management with certificates from step-ca would be a great combo. If you don’t already have LDAP I wouldn’t set it up just for this though.
If we included this in our blog post then there’d have been nothing for truculent users on link-aggregation sites to complain about!
Genuinely curious, does LDAP + PAM + ssh solve TOFU? That is, can it handle host keys and how?
Caveat: am smallstep employee / am biased.
No, LDAP + PAM can’t solve TOFU (or HKVF on host key / hostname reuse). Not directly anyways. You can use LDAP + PAM along with Kerberos/GSSAPI and DNSSEC to solve TOFU though, or so I’ve heard. I’m assuming that’s what OP is referring to.
But you can also use certificates alongside LDAP + PAM.
But you can also use certificates alongside LDAP + PAM.
That seems like the simplest solution to start with. You can create Ansible (or puppet or whatever) roles to auth your servers off your companie’s AD or LDAP server, restrict access to certain LDAP groups, and have config-management setup SSH to have its host keys signed by your CA.
That takes care of authentication/authorization/identity.
Kerberos for AD->Linux is painful. Yast on OpenSUSE is really good at connecting to AD domains, but the last time I touched it, it wasn’t easy to automate that process (but that was in 2012 so I imagine it’s gotten better).
That assumes one’s company has LDAP. Many smaller companies just rely on Google for SSO, which is perfectly OK. I’m quite wary of statements containing “just” and “LDAP” in the same sentence, as usually it’s not that simple to run and maintain it. In addition, it may work only for Linux, but in heterogeneous environments (Linux/Darwin/FreeBSD), it’s not so easy to have a consistent solution.
Yep. You’re basically describing how our hosted product works, which builds on step and step-ca. Except instead of syncing via LDAP we sync users & groups using SCIM [RFC7644] and have some custom NSS & PAM glue to make user management and access control work. It also uses PAM for audit logging and restricting sudo access.
To get certificates issued to hosts step-ca can be configured to accept instance identity documents on major clouds, which makes everything completely turnkey. For other environments we have a bunch of other mechanisms that offer different ease-of-use vs. security vs. generality tradeoffs. We’ve discussed adding kerberos enrollment, so you can get a certificate using a kerberos ticket, but that doesn’t exist yet. I think that’d be cool for folks who already have LDAP in place. It’d be good to hear whether that’s worth doing from people who run that sort of setup though.
Can’t you also create a CA and sign your ssh private keys with it?
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist
of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a
Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate
rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509
certificates used in ssl(8).
They are generating short-lived certificates through their cli.
Right but why not just sign users’ public keys?
Not sure what you are getting at, but the thing you quoted is what they are using as far as I understand. And I know of no other ways to sign a users public key. Could you provide an example of what you are trying to achieve and possible benefits over their approach?
Create a CA and install it on your servers, then sign your users’ ssh keys with it.
They are creating a CA, installing it on the server and signing users keys.
Of course you could also do that without their tooling, but this article is specifically about the SSO integration so I am still not sure what your original question was, but that’s okay :)
I think, technically you are not signing your ssh keys, but the certificate is itself a key type for OpenSSH.