I am familiar with these alternatives. My experiment was specific in wanting FIDO2 and I ended up figuring out the issue. It was the intersection of a couple of weird behaviours that made debugging very confusing, but it works exactly as I expected it would once those are resolved. I guess we can consider this a proof of concept that you can indeed use FIDO2 tokens as an external SSH host key (though as I said below whether this is practically useful is another matter entirely).

FYI I got it working, please see the update above.

Got the client working (mostly) without issues again, though trying to imitate my process for host keys as closely as possible I did encounter some weirdness that led me to this open bug: https://bugzilla.mindrot.org/show_bug.cgi?id=3355 So that may be the source of my issues… If they keys I was using suddenly were secretly requiring touch, it would explain a lot. I can’t right now but I will do another experiment with host keys when I can. Still would love to see if anyone else is able to reproduce this behaviour or get it working.

I previously have had no issues using this as a client key, but honestly I wouldn’t put it past myself to have picked the wrong key and not noticed. Maybe I will give it another try, but I don’t think that’s it.

Yeah, the rough idea is to use any old FIDO2 key as a USB HSM. Not necessarily looking for a very practical solution (the easy fix would be to just encrypt the drive), but curious. What inspired this, though not necessarily the final application, is Nix secret distribution tools that use the host key as the secret recipient. This means that theoretically if you have the host identity tied to an external HSM or similar you could have the same image deploy as different machines based on what security key you have plugged in.

I possibly should put greater emphasis on the fact that I am talking about the host key, not the client key. This guide is for a client identity key. I am talking about host keys as you find in /etc/ssh/ssh_host_ed25519, etc.