2023-04-15
Some thoughts on OpenSSH versus SSH
When I started to write yesterday's entry on how OpenSSH certificates aren't X.509 certificates, I initially titled it as being about 'SSH certificates'. This wouldn't be unusual; Matthew Garrett's article We need better support for SSH host certificates also uses 'SSH' here. I changed my entry's title out of a sense of pickyness, because although OpenSSH is the dominant SSH implementation, it's not the only one. Or maybe it is, depending on your perspective, or at least the only SSH that matters and so we might as well talk about 'SSH certificates'.
In theory, SSH is a protocol, specified across a number of RFCs, and there are multiple implementations of this protocol (for example, Go has an implementation in golang.org/x/crypto/ssh). In practice, well, you can see OpenSSH Specifications, which is a handy list of everything OpenSSH supports and implements. These range from RFCs, to RFC drafts, to OpenSSH's extensions for certificates. I think you can probably interoperate with OpenSSH if you only implement the RFCs, but your users may not enjoy it very much.
The other thing is that the evolution of SSH seems to be pretty much the OpenSSH project's show. I don't think anyone else is working on new protocol features; instead, OpenSSH comes up with them and then people with other SSH implementations either follow along or not. This makes OpenSSH fairly synonymous with 'SSH'; if only OpenSSH is moving the protocol forward and everyone else follows along sooner or later, you might as well say 'SSH certificates' and then mention in passing that other implementations may not support them (yet).
At the same time, there's a not insignificant amount of other SSH implementations being used out in the world (in important and relevant places). In one recently relevant example, one reason Github didn't take advantage of OpenSSH's protocol extension for offering multiple host keys (to enable upgrades or transitions) is that they don't use OpenSSH but instead a different implementation. As an implementation, OpenSSH is a monolith that's focused on its particular usage case of general computer access; if you're not doing that (as eg Github isn't), then you may find using other implementations easier than trying to (securely) bend OpenSSH to your needs. These implementations still clearly matter even if OpenSSH are the only people really evolving the protocol.
(One option would be to use 'OpenSSH' when I talk about some aspect of the OpenSSH programs and 'SSH' when I talk about protocol level things, even when the element of the protocol is only in OpenSSH (maybe unless OpenSSH doesn't yet consider it stable). This would make it 'SSH certificates', since they're a protocol element, but OpenSSH's deprecation of 'ssh-rsa' SHA1-based signatures since that's something the programs do.)