3 ms·

I'm very confused, given Yubikeys have smart card fuctionality and they can be used by gpg-agent to SSH with the regular gpg key (you can add to authorized_keys

I'm very confused, given Yubikeys have smart card fuctionality and they can be used by gpg-agent to SSH with the regular gpg key (you can add to authorized_keys just like any other keys) and you don't have to go through this whole mess of setup to create a CA and install it. What am I missing?

tashian 6y ago
That sounds like a great option too, depending on your situation. One difference is that the CA is on the hardware key, but the cert (and its private key) is not. Imagine you're on a team of 50, and anyone on the team might need emergency access to a host at some point. You wouldn't want to buy 50 keys and 50 safes. Just designate a couple folks to manage emergency access. They can manually mint a cert for a colleague as needed, and send it over a secure channel. No security key needed to use the cert, and it self-destructs after a few minutes.
munchbunny 6y ago
It's a chicken and egg problem: if you can't SSH into the machine, how do you add your key to the SSH config on the target machine? You could use a very long lived key, but then as soon as you have multiple people who might need production SSH access, you've got access control and revocation issues. The SSH CA is a good minimal solution, because the CA can issue only short-lived SSH keys (few hours at a time) that you use once and throw away. Also, CA trust scales better because it moves user management burden to the certificate issuing process and removes the need to modify the SSH config every time you onboard a new user. It's a pretty standard practice. Here's a post from Facebook about it from several years ago. This post is just about how to do it using YubiKeys. https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/ https://engineering.fb.com/security/scalable-and-secure-acce...
- harikb 6y ago
  This can also work as a solution where the “setup” (of trusting CA) is baked in to the image. Then there is no ssh related setup until the day you actually need to ssh to the host. And you get the guarantee that no ssh login can happen until you issue a temp-pair. This is actually quite useful for deploying clusters of machines that one doesn’t want normal ssh access until there is a real need. I think this was also mentioned in another comment

tashian 6y ago

That sounds like a great option too, depending on your situation. One difference is that the CA is on the hardware key, but the cert (and its private key) is not. Imagine you're on a team of 50, and anyone on the team might need emergency access to a host at some point. You wouldn't want to buy 50 keys and 50 safes. Just designate a couple folks to manage emergency access. They can manually mint a cert for a colleague as needed, and send it over a secure channel. No security key needed to use the cert, and it self-destructs after a few minutes.

munchbunny 6y ago

It's a chicken and egg problem: if you can't SSH into the machine, how do you add your key to the SSH config on the target machine? You could use a very long lived key, but then as soon as you have multiple people who might need production SSH access, you've got access control and revocation issues. The SSH CA is a good minimal solution, because the CA can issue only short-lived SSH keys (few hours at a time) that you use once and throw away. Also, CA trust scales better because it moves user management burden to the certificate issuing process and removes the need to modify the SSH config every time you onboard a new user. It's a pretty standard practice. Here's a post from Facebook about it from several years ago. This post is just about how to do it using YubiKeys. https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/ https://engineering.fb.com/security/scalable-and-secure-acce...

harikb 6y ago
This can also work as a solution where the “setup” (of trusting CA) is baked in to the image. Then there is no ssh related setup until the day you actually need to ssh to the host. And you get the guarantee that no ssh login can happen until you issue a temp-pair. This is actually quite useful for deploying clusters of machines that one doesn’t want normal ssh access until there is a real need. I think this was also mentioned in another comment