4 ms·

I still think Keybase is right — multi-device or some kind of multi-trust model is best so the key revocations aren’t happening so often. I remember this proble

I still think Keybase is right — multi-device or some kind of multi-trust model is best so the key revocations aren’t happening so often. I remember this problem with PGP and most people did not take the key verification seriously. And the problem with SSH that was pointed out in the article is funny now because of cloud services where servers are constantly being destroyed, so keys are changing frequently, unless you save and persist that private key for the server in your configuration. Which I’ve realized a lot of companies are simply not doing, which leads to people straight up ignoring key verifications in their ssh config.

groestl 8y ago
A side note on the last part: @cert-authority is an underrated feature of OpenSSH. More companies should use it to make their infrastructure safer to use.
- chupasaurus 8y ago
  It has flaws in usage: issuer cert per group isn't easy to manage (and makes pubkeys 1000+ characters long), you have to distribute CRLs, one error in sshd_config could make server unmanagable (multiplied by your config manager). I haven't seen a pure SSH CA automation project too.
  - groestl 8y ago
    Can you elaborate on the first issue?
    - chupasaurus 8y ago
      You can make a certificate with multiple principals, but in order to add/remove some group access you'll have to reissue the public cert (and add previous to CRL with removal of some), which is OK for short-lived certs. With multiple issuers, you can add/remove public keys for different CAs but the resulting meta public key will be a set of keys actually.
swiftcoder 8y ago
SSH is even worse in many corporate environments, because you also have to cross an SSH gateway to transit into from the corp fabric into the prod fabric. At AWS this meant we had to hop to a different gateway for each region, and then onto the (stateless) production host which was recreated from scratch on every deployment... There's no way a human was going to keep all those keys straight, and everyone just disabled SSH host verification.
- rocqua 8y ago
  This actually seems like the right use-case for SSHFP records. They allow for storing the SSH key fingerprint in a DNSSEC secured zone. Normally this is considered rather weak, because of the reliance on DNSSEC. However, in this case I think its a very easy to take step that'll be miles better than just trusting everything. The stronger alternative is Certificate-based SSH, but that is a lot of hassle. As it requires setting up a CA, handling revocation, and actually distributing the certificates.
  - toast0 8y ago
    It depends on how transient your servers are, but you can get pretty good mileage out of a checked in known_hosts file.
cyphar 8y ago
That is what cross-signing will accomplish, but the benefit of having per-device granularity is that users can actually tell if a new (potentially-malicious) device has been added to a conversation and be blacklisted.
platz 8y ago
> this problem with PGP Isn't keybase just doing something similar to subkeys for devices? Keep the master safe, if you need to revoke a subkey, no big deal.
- gnomewascool 8y ago
  My very naïve understanding is that in the keybase model there's no master, just several keys which can sign each other, so you can lose any of the keys (as long as it's not all of them), unlike in the PGP model, where you can't lose the master. In practice, though, as long as you protect the master key appropriately, the PGP model isn't that much worse (and possibly in some ways better — I'm not sure what happens in the keybase model when one of your devices is compromised, rather than just lost, and you don't notice for a while).

groestl 8y ago

A side note on the last part: @cert-authority is an underrated feature of OpenSSH. More companies should use it to make their infrastructure safer to use.

chupasaurus 8y ago
It has flaws in usage: issuer cert per group isn't easy to manage (and makes pubkeys 1000+ characters long), you have to distribute CRLs, one error in sshd_config could make server unmanagable (multiplied by your config manager). I haven't seen a pure SSH CA automation project too.
- groestl 8y ago
  Can you elaborate on the first issue?
  - chupasaurus 8y ago
    You can make a certificate with multiple principals, but in order to add/remove some group access you'll have to reissue the public cert (and add previous to CRL with removal of some), which is OK for short-lived certs. With multiple issuers, you can add/remove public keys for different CAs but the resulting meta public key will be a set of keys actually.

swiftcoder 8y ago

SSH is even worse in many corporate environments, because you also have to cross an SSH gateway to transit into from the corp fabric into the prod fabric. At AWS this meant we had to hop to a different gateway for each region, and then onto the (stateless) production host which was recreated from scratch on every deployment... There's no way a human was going to keep all those keys straight, and everyone just disabled SSH host verification.

rocqua 8y ago
This actually seems like the right use-case for SSHFP records. They allow for storing the SSH key fingerprint in a DNSSEC secured zone. Normally this is considered rather weak, because of the reliance on DNSSEC. However, in this case I think its a very easy to take step that'll be miles better than just trusting everything. The stronger alternative is Certificate-based SSH, but that is a lot of hassle. As it requires setting up a CA, handling revocation, and actually distributing the certificates.
- toast0 8y ago
  It depends on how transient your servers are, but you can get pretty good mileage out of a checked in known_hosts file.

cyphar 8y ago

That is what cross-signing will accomplish, but the benefit of having per-device granularity is that users can actually tell if a new (potentially-malicious) device has been added to a conversation and be blacklisted.

platz 8y ago

> this problem with PGP Isn't keybase just doing something similar to subkeys for devices? Keep the master safe, if you need to revoke a subkey, no big deal.

gnomewascool 8y ago
My very naïve understanding is that in the keybase model there's no master, just several keys which can sign each other, so you can lose any of the keys (as long as it's not all of them), unlike in the PGP model, where you can't lose the master. In practice, though, as long as you protect the master key appropriately, the PGP model isn't that much worse (and possibly in some ways better — I'm not sure what happens in the keybase model when one of your devices is compromised, rather than just lost, and you don't notice for a while).