Some thoughts on OpenSSH versus SSH
April 15, 2023
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.)
