1. 17

  2. 3

    The next level up from SSH keys is SSH certificates. [citation needed]

    The benefit of doing this is twofold: you no longer need to rely on the insecure trust on first use (TOFU) model for new hosts […] TOFU isn’t insecure. CA certificates are PSKs. Apples and oranges.

    Another way to improve your SSH security is to enforce the use of a bastion host [citation needed]

    There are a lot of legitimate criticisms of bastion hosts. And many organisations have followed Google’s BeyondCorp lead and decided to focus on endpoint security.

    The methods above give practical examples of several ways in which you can improve the security of your SSH infrastructure, all while giving users the flexibility to keep using the tools they’re familiar with.

    The methods are also exactly what’s offered by Gravitational. Mmm, content marketing 👨‍🍳

    1. 2

      The methods are also exactly what’s offered by Gravitational. Mmm, content marketing 👨‍🍳

      Yeah, that’s always a risk with corporate blog stuff. In this case, the advice was generally applicable with almost anything with an sshd without using their stuff, though of course, bikeshedable…

    2. 3

      I’m always bothered by how OpenSSL and OpenSSH have different key formats that makes it hard to correctly manage your PKI.

      It would be much nicer to be able to use your CA for everything and not having 2 CAs, for different purposes. Intermediates can probably fulfill this purpose, and this way I only have 1 root CA to safeguard.

      1. 1

        In general, I sympathize with your desire for things to be simpler. In particular, I agree that the proliferation of key formats is frustrating.

        I do feel I should say that intermediates won’t give you the separation you want, here. Notionally they could be designed that way, but the way it works right now in openssh is that you specify the root cert. That means that the authentication code isn’t looking at which intermediate cert was used for which purpose, only that it was derived from the root cert that it’s set to trust. That means it would still be possible for the machine that issues client certs to also issue server certs, even if you don’t use it that way habitually. You want that to be impossible, for reasons the article explains.

        Even if you could specify an intermediate cert as the trust root, though, I don’t think you should want this. In security, you want to optimize for how easy it is to reason about the security properties you’re depending on. That means you shouldn’t share infrastructure unless you have an affirmative reason to share it, because it’s hard to be certain there isn’t some subtle vulnerability that you’re opening yourself up to. As much as possible, everything security-related should have one single function and do it well, because that’s easier to reason about. Yes, in this case, that winds up being the opposite of what would feel tidy in other areas of software.

        This is of course only my opinion, and you are free to disagree with it, but I thought I’d offer it since I felt like I might have some perspective that you weren’t considering.

        The actual work of maintaining multiple root certs isn’t that challenging - just a couple more commands, ultimately. It’s mostly the cognitive overhead of keeping track of what you’re doing that makes it hard. My advice on how to cope with that is to write documentation for yourself about what choices you made and why, so it’ll be easy to reference a year from now when you need to update things. For example, write out for yourself what each root cert is called, what you use it for, and how you secure it. Yes, it’s extra work, but a lot of doing this right is about the record-keeping aspect.