4 ms·
I recently rolled out YubiKey 4s to my whole organization and it was a painless experience. There's not a single file-based key left. Provision the keys, replac
by lima 8y ago
I recently rolled out YubiKey 4s to my whole organization and it was a painless experience. There's not a single file-based key left. Provision the keys, replace the old file-based keys via our configuration management tooling, done.
Wouldn't a SSH CA just introduce a whole different kind of complexity?
- How to protect the SSH CA and its key and make it highly available? I don't want to be locked out of my bastion host after something the CA depended on broke and my certificate has just expired.
- How to authenticate users against the CA? Most solutions I've seen use a longer-lived client-side secret, which is just as susceptible to theft than a regular SSH key, or some sort of OAuth or SAML SSO. A malicious Chrome extension can now compromise the SSO process, you still need a U2F token (like a YubiKey 4) to properly secure the SSO account, etc.
- How to make it work with our SCM and random things like a storage appliance and various JunOS devices, which support regular SSH keys, but don't know about SSH certificates?
I would assume that Latacora is using a SSH CA, and I'm legitimately curious how you approached these challenges.
- tptacek 8y agoWe like Y4's just fine. For the very limited set of machines we maintain that we ever need to SSH into, we use Y4 SSH keys. But we don't promote them to clients; we're working on rolling out short-lived SSH credentials with them.
- lvh 8y agoYou raise a bunch of valid points. Just to answer the one about authing against the CA (I'm in the LV airport for BlackHat and my laptop battery is about to die): yes, still get U2F tokens. You're right that malicious Chrome extensions will mess you up, but that's true for everything else you run too: you need to enforce Chrome extensions via MDM regardless of what your SSH key story looks like. I consider having to SSO in a good thing: it means onboarding/offboarding/audit logging is easier. The context for SSH CA/Teleport is SSHing into a box. When you do actually need an SSH key, Yubikeys are the best answer. (I like using gpg-agent's ssh-agent emulation mode because I find it works better on Macs, but that's irrelevant to the security analysis.)
- lima 8y agoI agree that for a large organization - which has the necessary pieces in place - it makes a lot of sense to use SSO for SSH access. The SSO is mission-critical anyway, there might not even be direct SSH access except via an authenticated proxy, there's centralized audit logging and intrusion detection, ... However, I would argue that unless this is the case, operating a SSH CA is riskier (both from a security and availability point of view).
- brazzledazzle 8y agoI think most (if not all) SSO solutions can do push-based MFA these days. It's not perfect by any means and I'm sure plenty of people will blindly approve any requests to the app but it's a lot more secure than without it and it's pretty convenient.
- bsder 8y ago> I recently rolled out YubiKey 4s to my whole organization and it was a painless experience. A writeup would be awesome. I have been trying to set up keys for road warrior VPN as well as our access to cloud, and it has been FAR from straightforward. Generally, everything consists of "Somehow communicate with a Radius server" that Yubi no longer supports(YubiRadius) or "Trust Google".
- HiHelloBolke 8y agoOne way we reduce the risk of CA key compromise is to intermediaries for signing most of our stuff. Our implementation has Vault that's using intermediates certs to sign user's ssh keys, these ssh cert are short lived and we use it for signing in to ephemeral app hosts. One day we had bit of time skew because of bad ntpd & lo we couldn't login because of our short lived certs :-)