A common application of security keys is as a hardware-backed SSH key. I have lately been curious as to whether it would be possible to use one as an SSH host key. It seems like it should be straightforward enough, it’s just another SSH key after all, if it works as a client identity key, why wouldn’t it work as a host key?

So I had a mess around with this, but haven’t been able to get it to work. Using sudo ssh-keygen -t ed25519-sk -O no-touch-required (or with -O resident as well) just ends up with the connection being refused and the auth log showing sshd: no hostkeys available – exiting.

I had a look at the source for OpenSSH, but after 10 minutes of digging can find no indication of why it would cosider this to not be an ED25519_SK key, which the code explicitly accepts as a host key.

If anyone has any ideas for what is going wrong or has better luck, I would love to hear the details.

(Posted in selfhosted because this is the most prominent community that talks about ssh I can find, somewhat unsurprisingly)

EDIT to emphasize that this is talk about host keys like /etc/ssh/ssh_host_ed25519, not client keys. My attempts to make a working “ssh_host_ed25519_sk” are what I am reporting on here.

UPDATE: It works! So it ended up being a combination of a couple of confusing things, I believe.

One is that there is an old bug that means that ssh-keygen -K will accidentally make keys require user interaction again, which sshd then ignores as though they don’t exist. I believe this is what I was seeing previously, as I had been messing around with the keys elsewhere to verify them and then used ssh-keygen -K as a convenient way to drop them into /etc/ssh. But that alone would not have been enough to stop me, as I did try generating them in-place…

But I generated them with the name ssh_host_ed25519_sk_key, following the naming convention of id_ed25519_sk, and the fact that ED25519_SK is listed as a different enum value in the OpenSSH source. However, even upon stripping out every other key and enabling debug logging, it simply never even tried to touch that file as far as I could tell. So as an experiment I renamed it to ssh_host_ed25519_key as though it is a normal key, and that immediately worked exactly as expected!

So my final steps to get this working were:

sudo ssh-keygen -t ed25519_sk -O resident -O no-touch-required
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator: 
Enter file in which to save the key (/root/.ssh/id_ed25519_sk): /etc/ssh/ssh_host_ed25519_key
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /etc/ssh/ssh_host_ed25519_key
Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub

Testing sshing into the host then works flawlessly as long as the security key is plugged in, and the connection is rejected the moment it is unplugged.

So this has been an interesting little experiment. Notably, because of the requirement for interaction with the security key, this will mess up anything else (like age) that uses the key directly as a cryptographic identity and isn’t smart enough to reach out to the security key.

Given how long it took me to find any information about this, hopefully this will serve someone well in future.

#selfhosted