3 ms·

The author keep using the word "easy". I don't think we have the same definition of that word. A cursory read of the article is enough to gather a main point,

by Fradow 7y ago

The author keep using the word "easy". I don't think we have the same definition of that word. A cursory read of the article is enough to gather a main point, which should be a disclaimer: it's aimed at medium/big companies that have significant security threat model and have a dedicated sysadmin team. If you have neither, this is adding operational complexity for no real gain. When your threat model is small, potential attackers are not sophisticated enough to target SSH access. And configuring this and properly using it is a big waste of time. You might even lock yourself out of your servers because of a mistake or lost keys (that's my biggest fear which prevents me from ever switching to certificates unless I get a dedicated sysadmin). Yeah there are benefits, but they are just too abstract to bother for small companies.

mmalone 7y ago
Am author. > medium/big companies My goal (or our goal at smallstep) is to build tools to make this easy enough that it makes sense for small teams. If you have one client and one server, pubkey authn will probably always be easier. And as long as it's the default, certificate authentication will always require some amount of configuration. But I think good tooling with baked in defaults to encourage best practices can make this easy and quick enough to deploy to be a good idea for most non-trivial SSH deployments. However, much of this is aspirational at the moment. So your point remains. The point of the post was to raise awareness and start a discussion about what's needed to make this feasible for pragmatic people. > dedicated sysadmin team I don't think a dedicated sysadmin team should be necessary. On the contrary, with the right tooling, and unless you're just completely punting on any rational management of SSH keys, I think certificates are easier to administer. > potential attackers are not sophisticated enough to target SSH access The more common attack vector is a lost/stolen/compromised laptop or a private key that's accidentally committed to a repository. This is a very real vector. It happens in real life on a regular basis. Since certificates expire a lost/stolen machine or committed private key will become worthless for accessing internal infra very quickly. So it reduces the attack window, which is a real and significant improvement. For a compromised machine, SSH certificates aren't a cure-all, but they're at least as good as pubkey. They make it easier to keep private keys off disk, providing better cover. And they make it harder for attackers to exfil private keys, cover their tracks on the compromised laptop, and do bad things with them later. > You might even lock yourself out of your servers You could do this with pubkeys too. If this happens, cloud VMs typically have a virtual serial interface you can use to remediate. You can leave pubkey authn enabled and still use certificates day-to-day, so you could keep a backup pubkey available for a few select admin users that you trust. Alternatively, you could issue a long-lived certificate in a secure place for use in an emergency. If this is the thing that's preventing you from trying it out I hope these ideas get you over the hump! If they don't, I'd love to hear why! > they are just too abstract to bother for small companies This is a very common problem with security stuff :(. That's why I think the headline feature here is "SSO for SSH". It's an operational improvement and better UX. The security benefits come for free.

by Fradow 7y ago

mmalone 7y ago

Am author. > medium/big companies My goal (or our goal at smallstep) is to build tools to make this easy enough that it makes sense for small teams. If you have one client and one server, pubkey authn will probably always be easier. And as long as it's the default, certificate authentication will always require some amount of configuration. But I think good tooling with baked in defaults to encourage best practices can make this easy and quick enough to deploy to be a good idea for most non-trivial SSH deployments. However, much of this is aspirational at the moment. So your point remains. The point of the post was to raise awareness and start a discussion about what's needed to make this feasible for pragmatic people. > dedicated sysadmin team I don't think a dedicated sysadmin team should be necessary. On the contrary, with the right tooling, and unless you're just completely punting on any rational management of SSH keys, I think certificates are easier to administer. > potential attackers are not sophisticated enough to target SSH access The more common attack vector is a lost/stolen/compromised laptop or a private key that's accidentally committed to a repository. This is a very real vector. It happens in real life on a regular basis. Since certificates expire a lost/stolen machine or committed private key will become worthless for accessing internal infra very quickly. So it reduces the attack window, which is a real and significant improvement. For a compromised machine, SSH certificates aren't a cure-all, but they're at least as good as pubkey. They make it easier to keep private keys off disk, providing better cover. And they make it harder for attackers to exfil private keys, cover their tracks on the compromised laptop, and do bad things with them later. > You might even lock yourself out of your servers You could do this with pubkeys too. If this happens, cloud VMs typically have a virtual serial interface you can use to remediate. You can leave pubkey authn enabled and still use certificates day-to-day, so you could keep a backup pubkey available for a few select admin users that you trust. Alternatively, you could issue a long-lived certificate in a secure place for use in an emergency. If this is the thing that's preventing you from trying it out I hope these ideas get you over the hump! If they don't, I'd love to hear why! > they are just too abstract to bother for small companies This is a very common problem with security stuff :(. That's why I think the headline feature here is "SSO for SSH". It's an operational improvement and better UX. The security benefits come for free.