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)

  • Oisteink@feddit.nl
    link
    fedilink
    English
    arrow-up
    0
    ·
    4 days ago

    Nah - storing cryptographic key pairs is a supported and valid use-case for fido2

    • ricecake@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 days ago

      It wasn’t the crypto key pair part I was referring to, it was the part where fido is geared towards interactive user auth, not non-interactive storage.
      It wouldn’t have surprised me if the ssh devs hadn’t put implementing fido support for host keys high in the development list, or that it was tricky to find documentation for. Using something like a tpm is the more typical method.

      There’s no technical reason it can’t work, and the op got it to work so clearly the implementation supports it, but that doesn’t mean it’s the most expected setup, which means it might have unexpected gaps in functionality or terrible documentation.