OpenSSH now (release 5.7) supports some elliptic curve cryptography! Excellent to have modern crypto, and something not based on prime number factorisation. I am put in mind of baskets, containing all of ones eggs.
So, time to add ECDSA to my running OpenSSH setup, so that if there's ever a reason to disable RSA and/or DSA, I still have a way in. Mostly very simple to do because of the normally-high skill of the developers of OpenSSH; but there was one glitch. I'm writing it up so I have a reference to point people to.
# ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ""
turns out to be unnecessary. OpenSSH “make install” depends upon the host-key target, which creates absent host-keys for you.
Then explicitly add “HostKey /etc/ssh/ssh_host_ecdsa_key” to /etc/ssh/sshd_config, via your preferred config management system.
% ssh-keygen -t ecdsa -C firstname.lastname@example.org
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/troll/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/troll/.ssh/id_ecdsa.
Your public key has been saved in /home/troll/.ssh/id_ecdsa.pub.
The key fingerprint is: [...]
Run ssh-agent via your normal means and then invoke ssh-add to confirm that you really did use the same passphrase for the ECDSA key as for RSA & DSA, so that all three keys can be loaded at once with one passphrase.
Then add the contents of ~/.ssh/id_ecdsa.pub to ~/.ssh/authorized_keys.
We need to know the new identity of the server, so that we know what to compare against, and know what to advertise to the system users in an update email, to put into the template for new system users, and to put into DNS.
# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
256 22:20:32:f8:fb:65:87:09:33:a9:b6:c9:b0:5e:14:b8 /etc/ssh/ssh_host_ecdsa_key.pub (ECDSA)
Then try it ... and watch it fail:
## -nok is an alias in ~/.ssh/config to disable Kerberos
$ ssh -o HostKeyAlgorithms=ecdsa-sha2-nistp256 trollheim-nok
Error calculating host key fingerprint.
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/troll/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/troll/.ssh/known_hosts:10
ECDSA host key for trollheim.invalid.tld has changed and you have requested strict checking.
Host key verification failed.
This is confusing -- I ask for ECDSA, get sent the correct fingerprint, but then told there's an offending RSA key? Try again with -v and I see something interesting just beforehand:
debug1: found 2 insecure fingerprints in DNS
Hrm. I was planning on updating DNS after confirming things worked, but could it be keeping things from working? Okay, let's try adding it:
% ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -r trollheim.invalid.tld
export_dns_rr: unsupported algorithm
After a trollish sigh, it's time to go look at the source, and find ... that DNS doesn't matter. And hey, let's ssh to localhost instead, so that there's no DNS, and ... indeed, it fails. So, that was a red herring.
More debug testing shows no sign of anything highlighted as a problem, aside from the fact that this is new. So, edit “~/.ssh/known_hosts”, add the results of running “ssh-keyscan -t ecdsa trollheim.invalid.tld”. Connect via ssh and ... it works.
I read in the announcement mail:
automatically order the hostkeys requested by the client
based on which hostkeys are already recorded in known_hosts. This
avoids hostkey warnings when connecting to servers with new ECDSA
keys, since these are now preferred when learning hostkeys for the
It looks as though the OpenSSH developers maybe went a little too far, since they've managed to break automatic learning of new hostkeys — before, if you connected with DSS after connecting with RSA, then you'd be prompted with the existing RSA key, the new DSA key and asked if you were sure you wished to continue. Oops! Time to file a bug report, then get shouted at by Theo for being dumb and missing something Obvious.
Okay, can't do DNS yet, IANA haven't allocated a type.
UPDATE 2011-01-24: This was a deliberate design change by the OpenBSD folks, not called out in the announcement or documentation (that I could see). They recommend using ssh-keyscan for this, which is rather manual and contrary to the spirit of the design which made the SSH protocol a success — but I do see their point, from a security and consistency-with-new-security-approach perspective. An unfortunate situation.