Last year, I read a blog post that urged me to Upgrade Your SSH Key to Ed25519 and so I did. Ed25519 keys have been available since OpenSSH 6.5 (OpenSSH 8.0 was released on 2019-04-17), and they are smaller, faster and better than RSA, it seems. More info is in the blog post.

However, many months later, I found that ed25519 keys are not well supported for a few key systems:

1. Unifi network devices allow you to provide SSH keys in the CloudKey UI to be distributed to your network devices, but the UI only accepts some types of keys. At the moment, Unifi CloudKey, AP, and USG all support ed25519 keys on the hardware, but the CloudKey UI rejects them.
2. Dropbear, which you can run inside of initramfs to remotely unlock encrypted Linux filesystems, does not seem to support ed25519. An HN comment from 11 months ago suggests a fix is in the works, but nothing about ed25519 has appeared in the changelog.

Admittedly, these issues are not total show stoppers and I could use ed25519 keys for normal access and RSA keys for network device access and when my linux box reboots. It’s just that juggling ed25519 and RSA keys for all my iOS devices (Blink is great), a linux workstation, raspberry pis and several laptops, seeding them correctly, managing passphrases and configuring clients to use the right ones is complicated.

There already is an open feature request for ed25519 keys in the Unifi UI and an unreviewed PR for Dropbear, but we build systems with what we have, not what is on the roadmap.

If you are looking at ed25519 keys for your infra, they are fine and good, except for the unifi and Dropbear edge cases. You could probably work around them by deploying a config.gateway.json and applying the Dropbear patch manually, but that sounds as exhausting as managing RSA and ed25519 keys, so we have a cure which becomes an ailment.

So, for now, I’m following Github’s docs and using 4096 bit RSA keys, as well as Github’s public key “feature” (https://github.com/username.keys) to seed authorized_keys from Ansible through out my infra.

It’s fine.

Postscript

Screens for iOS can connect to VNC via a secure connection which appears to use an SSH tunnel. While you can use SSH keys for authentication, ed25519 keys not supported and one can only use ”…RSA keys of 2048-bits or less; 4096-bits or greater are unsupported”. This is less than ideal and I’ll revisit Screens, if I get a desktop on linux that is worth using VNC for.

Post-postscript (August 5, 2019)

Linux VMs in Azure also do not support ed25519 keys.

Azure currently supports SSH protocol 2 (SSH-2) RSA public-private key pairs with a minimum length of 2048 bits. Other key formats such as ED25519 and ECDSA are not supported.

A friend alleges that Azure Devops also does not support ed25519 keys, but the product name gives me heartburn and makes it difficult to find docs that confirm this.