2024-05-06
What affects what server host key types OpenSSH will offer to you
Today, for reasons beyond the scope of this entry, I was checking the various SSH host keys that some of our servers were using, by connecting to them and trying to harvest their SSH keys. When I tried this with a CentOS 7 host, I discovered that while I could get it to offer its RSA host key, I could not get it to offer an Ed25519 key. At first I wrote this off as 'well, CentOS 7 is old', but then I noticed that this machine actually had an Ed25519 host key in /etc/ssh, and this evening I did some more digging to try to turn up the answer, which turned out to not be what I expected.
(CentOS 7 apparently didn't used to support Ed25519 keys, but it clearly got updated at some point with support for them.)
So, without further delay and as a note to myself, the SSH host key types a remote OpenSSH server will offer to you are controlled by the intersection of three (or four) things:
- What host key algorithms your client finds acceptable. With modern
versions of OpenSSH you can find out your general list with 'ssh
-Q HostKeyAlgorithms', although
this may not be the algorithms offered for any particular connection.
You can see the offered algorithms with 'ssh -vv <host>', in the
'debug2: host key algorithms' line (well, the first line).
(You may need to alter this, among other settings, to talk to sufficiently old SSH servers.)
- What host key algorithms the OpenSSH server has been configured to
offer in any 'HostKeyAlgorithms' lines in sshd_config, or some
default host key algorithm list if you haven't set this. I think
it's relatively uncommon to set this, but on some Linuxes this may
be affected by things like system-wide cryptography policies that
are somewhat opaque and hard to inspect.
- What host keys are on the server configured in '
HostKey' directives, in your sshd_config (et al). If you have no HostKey directives, a default set is used. Once you have any HostKey directive, only explicitly listed keys are ever used. Related to this is that the host key files must actually exist and have the proper permissions.
(I believe that you can see the union of the latter two with 'ssh -vv' in the second 'debug2: host key algorithms:' line. I wish ssh would put 'client' and 'server' into these lines.)
This last issue was the problem with this particular CentOS 7 server. Somehow, it had wound up with an /etc/ssh/sshd_config that had explicit HostKey lines but didn't include its Ed25519 key file. It supported Ed25519 fine, but it couldn't offer an Ed25519 key because it didn't have one. Oops, as they say.
(It's possible that this is the result of CentOS 7's post-release addition of Ed25519 keys combined with us customizing this server's /etc/ssh/sshd_config before then, since this server has an sshd_config.rpmnew.)
This also illustrates that your system may generate keys (or have generated keys) for key algorithms it's not going to use. The mere presence of an Ed25519 key in /etc/ssh doesn't mean that it's actually going to get used, or at least used by the server.
Just to be confusing, what SSH key types the OpenSSH ssh program will offer for host-based authentication aren't necessarily the same as what will be offered by the server on the same machine. The OpenSSH ssh doesn't have a 'HostKey' directive and will use any host key it finds using a set of hard-coded names, provided that it's allowed ny the client 'HostKeyAlgorithms' setting. So you can have your ssh client trying to use an Ed25519 or ECDSA host key that will never be offered by the OpenSSH server.
PS: Yes, we still have CentOS 7 machines running, although not for much longer. That was sort of why I was looking at the SSH host keys for this machine.