Wandering Thoughts archives

Do I feel uncertain about CentOS's future now? Yes, a bit

I was going to write an entry about how CentOS remains quietly important to us because of its long support period, with CentOS 7 supported through 2024 or so for security updates (per the CentOS wiki and FAQ). Then I paused to think about that in light of IBM buying Red Hat.

The end of 2023 is five years from now. A lot of things can happen in five years after a company is acquired, and a lot of intentions and plans can change. IBM is probably not going to stop doing Red Hat 7 updates, so a CentOS can continue in some form, but at the same time the current Red Hat provides a certain degree of support and assistance to CentOS (see the CentOS wikipedia entry for one account of this). It seems likely that CentOS's activities would at least slow down if IBM decided that it wasn't going to, say, continue to fund as many people to work on CentOS as Red Hat currently does.

Of course, nothing was certain even when Red Hat was an independent company; although we may pretend otherwise, blithe projections of support for Linux distributions three or four or five years into the future are just that (for many of them, not just CentOS). But I can't help but feel that things are now a bit more uncertain than they used to be, and I'm not quite as confident at projecting support for CentOS 7 out to the middle of 2024 as I was a month ago. A month ago, Red Hat pulling away from CentOS would have felt cataclysmic; in the future, it will just be IBM conducting a strategic reassessment (although perhaps a drastic one).

CentOS is still going to continue to be our best option for certain things, but that's another entry (the one I was going to write before I started thinking). And we're certainly not going to migrate our current CentOS 7 machines to anything else any time soon. So in practice what we're going to do is nothing; we're going to carry on and hope for no changes any time soon.

(As far as what this means for Fedora, well, I have no idea (and I certainly hope nothing changes, since I don't want to change Linux distributions). But again things feel a little bit more uncertain now than they used to.)

OpenSSH has broader key revocation than I thought

A while back, OpenSSH gained support for doing host and user authentication through a local Certificate Authority. Instead of directly trusting public keys, you configured a CA (or more than one) and then trusted anything signed by that CA. For user keys, this has the usual weakness of the basic CA model; for host keys, it's probably an improvement in practice but I'd like to know what happens if you get handed a new CA-signed host key for a host that you already saw one for.

If you're sensible, when you add Certificate Authorities to a security system you also add key revocation. So I wasn't particularly surprised to read in passing that OpenSSH supported key revocation, and I didn't think anything more about it. For years, I've assumed that OpenSSH's key revocation was intended for and limited to CA-signed keys. As I discovered recently when I actually looked at the relevant sections of the manual pages, this is not the case. While revoking keys appears to have been added to OpenSSH along with CA signed keys in OpenSSH 5.4 (released in early 2010), they were never limited to revoking only those keys. OpenSSH key revocation can be used to block any SSH key, and it's been that way from the beginning.

(For instance, the sshd_config(5) manpage is very specific on this, saying about RevokedKeys that 'keys listed in this file will be refused for public key authentication'. Any keys. And in fact it cautions you that if this file is unreadable, all keys will be refused.)

Keys to be revoked can be specified in a variety of ways, per the manpage. The most straightforward one is simply one public key per line, exactly as you'd put them in authorized_keys (and perhaps that's where you get them from). For CA-signed keys, you have a couple of options spelled out in ssh-keygen(1)'s 'Key Revocation Lists'. OpenSSH 7.9 adds some additional useful options, but that's another entry (especially since it will probably be a few years before it's relevant to us; Ubuntu 18.04 is probably unlikely to update their version, much less 16.04).

With that said, I'm not sure there's much use for key revocation in our particular environment because people have only a single home directory and thus a single authorized_keys to maintain. If a key is compromised, it just gets removed.

(I'm assuming that attackers won't reuse keys that they add to someone's authorized_keys and so there's no point in blocking further uses of such a key. This may be wrong.)