Yes, it's easy, you don't need gpg-agent or anything, just do `ssh-add -K`:
debug1: ssh_sk_enroll: /dev/hidraw0 does not support credprot, refusing to create unprotected resident/verify-required keyYou don't need so many for SSH, but it's great for usernameless/passwordless auth with websites.
Basically wondering if I can drop gpg-agent (for SSH auth purposes anyway) and 'sshcontrol' without changing key.
Right, but I already have it on the device, I'm talking about using an already provisioned device with this new-ish OpenSSH feature; or whether it does something 'special' that means the key needs to be ('resident' or not) generated by this feature?
Thinking about it though it's probably not for me, since SSH is not the only and probably the minority of my use, since I also use the encryption key (e.g. with `pass`) and signing (e.g. git commits, for no particular reason).
> The keys aren't copied to the device, they're generated on the device, more or less.
In your blog post you say it produces two files, the private and public keys. If it generated on device it wouldn't (be able to) have the private key?
Talking about these things is a bit confusing because the keys do so much, but the simple answer is that you'll need to generate a new key, yes. You need to get the key from the device, at no point will you have the private key outside the device, which means you won't be able to use one you generated previously.
> In your blog post you say it produces two files, the private and public keys. If it generated on device it wouldn't (be able to) have the private key?
I may be misunderstanding your question, but the "private" key it generates is more of a reference to the one existing on the device, not a standalone private key that you get when you generate one with ssh-keygen.
The way it actually works is that these devices come with some randomness baked in and they use that to derive all the private keys you need with various cryptographic techniques. You can never extract any of those private keys (which is where the security lies) .
This ID is public, for practical reasons an OpenSSH client setup will store it in the same sort of place it would keep a (possibly encrypted) private key for normal public key crypto but it isn't actually private, you could for example put the file on a (HTTPS) web page you copy-paste from to configure every new device you get, if bad guys see it they don't learn how to sign in to GitHub as you.
The Security Key doesn't (without resident credentials) remember what this ID value is. On a web site, that ID value would get squirrelled away somewhere during enrollment by the site's backend together with the associated public key, maybe to a database table, and the site gives you a list of IDs after you tell it your username or whatever - when you try to use a Security Key, your Security Key can look at such a list and (using Authenticated Encryption) it can see it made this one, and from there rediscover the private key and use that to authenticate you.
But unless it is shown the ID it is clueless. No idea how to authenticate. If you've lost the ID, or maybe it's on a device you don't have access to at the moment, your Security Key can't help you.
Edited to add: Behind the scenes, the implementation at enrollment goes something like this, the Security Key mints the random keypair and then it uses its own permanent secret symmetric key (which never leaves the Security Key and is likely very hard to extract even in a lab setup) to encrypt the private key or some seed value and that encrypted value (which only this Security Key can decrypt) is used as the apparently random ID.
Oh yeah, I forgot to mention, the ID is not small. This is at least 16 bytes. And even devices that don't need to hide something inside that ID are forbidden from just using some boring counter or something that would be distinguishable, it has to look at least mostly "random" in that case (minimum 100 bits of entropy).