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.

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.

It depends on how transient your servers are, but you can get pretty good mileage out of a checked in known_hosts file.

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.

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.

Can you elaborate on the first issue?

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.

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.

> 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.

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).