Trying to move towards Ed25519 OpenSSH host keys: a stumbling block

February 7, 2015

Now that I've upgraded to Fedora 21 on my main machines and actually have it available, I've decided to start shifting my OpenSSH usage towards considering ed25519 my primary and preferred public key authentication system (out of all of the ones that OpenSSH offers). Moving towards Ed25519 for my own keypairs was and is simple; I generated some new keypairs (one for each master machine), loaded them into ssh-agent first, and started adding them to authorized_keys on machines that have a modern enough version of OpenSSH. I expect to be using RSA keys for a long time given that eg CentOS 7 is not Ed25519 enabled, but at least this transition is basically automatic from now onwards.

(Well, I can add my Ed25519 keys to authorized_keys pretty much anywhere but they won't do me any good except on modern machines.)

But I also want to use Ed25519 host keys where machines have them available, and this turns out to be more tricky than I was expecting (at least on the version of OpenSSH on Fedora 21, which is OpenSSH 6.6.1p1). If you read the ssh_config manpage you'll soon run across a description of the HostKeyAlgorithms option, which to quote the manual 'specifies the protocol version 2 host key algorithms that the client wants to use in order of preference'. This sounds like just the thing; I could specify it explicitly in .ssh/config with the Ed25519 options first and everything would work right.

Well, sadly, no. The manual also claims:

If hostkeys are known for the destination host then [the HostKeyAlgorithms] default is modified to prefer their algorithms.

In other words: if you say that you prefer Ed25519 keys, the host has both an Ed25519 key and an RSA key available, and you already have the host's RSA key in .ssh/known_hosts, ssh should authenticate the host with the existing RSA key.

This appears to be what they call 'inoperative' if you specify an explicit HostKeyAlgorithms setting, even if this setting just shuffles the priority order. If you put the Ed25519 options first and you know an RSA key for a host that also offers Ed25519, ssh complains about a host key mismatch between the Ed25519 key being offered and the RSA key you know and does various things in reaction (including turning off X forwarding, which is fatal in my environment at work).

As far as I can tell, the only way to get this to really work is to not set HostKeyAlgorithms. Instead, you have to manually gather Ed25519 keys for anything that has them (perhaps using 'ssh-keyscan -t ed25519'), add them to your known_hosts, and purge any other host key entries for those hosts. This works right in that anything with a known Ed25519 key will be verified against the key, but it won't remember Ed25519 keys for new hosts; instead you'll probably wind up with ECDSA keys for them. You'll want to periodically look for signs that new hosts support Ed25519 and upgrade your known host keys for them.

(Future versions of OpenSSH will apparently support recording multiple host keys for a remote host at once as part of host key rotation. That won't be on all of our Linux machines any time soon, much less other things in the corner.)

I'd say that hopefully this issue is or will be fixed in future versions of OpenSSH, but I'm honestly a little worried that people will say it's actually working as intended (and at most fix the manual page). Even if they do fix it I don't expect to see the fix appearing in Fedora any time soon, given the usual release process and delays.

(It's possible that setting HostKeyAlgorithms in /etc/ssh/ssh_config will work and that only .ssh/config is special here, but I haven't tested this, it's not always feasible, and I'm not holding my breath.)


Comments on this page:

By Chris at 2015-02-07 06:00:11:

I'm going to assume I'm missing something, because it seems like a very small shell script could remove the RSA keys from your known_hosts file for the relevant hosts.

So, what am I missing? Is there a precedence for which kind of key to retrieve from the server that defaults to RSA? My ssh_config(5) (for ssh 6.7p1) lists the Ed25519 algorithms before the RSA algorithms for the HostKeyAlgorithms config option, so I don't think that's it.

By Chris at 2015-02-07 06:01:53:

I should clarify: It seems like simply removing the RSA keys from the known_hosts file should be sufficient for Ed25519 key exchange to occur. And I should probably go to bed.

By cks at 2015-02-07 18:12:42:

The problem is that right now I don't know what are the relevant hosts and the relevant hosts will change over time as machines are upgraded. And when a machine is upgraded to support Ed25519, ssh will wake up and complain about a host key mismatch because I'm now asking for Ed25519 (and getting it) but I have RSA.

So, what am I missing? Is there a precedence for which kind of key to retrieve from the server that defaults to RSA? [...]

I probably wasn't clear here: my known_hosts file and indeed my entire system dates from far enough ago that hosts only offered RSA or DSA keys (and preferred RSA). So at the time I harvested these keys, I got RSA keys. Now the hosts support Ed25519 keys and I'd like to switch to them, and I'd also like to get Ed25519 keys for any new host that I connect to if it has them (instead of RSA or ECDSA; the latter is actually the current default preference).

Written on 07 February 2015.
« A thought on containerization, isolation, and deployment
The history of commercial Unix and my pragmatism »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 7 01:36:55 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.