I work from several computers and VMs. It is somewhat of a pain to have to generate and register keys for each computer and VM. It would be nice if I could just generate the ssh key once on my security key and use that everywhere.
Here's[1] the first blog I could find that at a glance appears to provide the right instructions.
[1]: https://evilmartians.com/chronicles/stick-with-security-yubi...
Well, except when gpg-agent dies out of nowhere and you have to restart it..
It's still better security even if it doesn't go quite as smoothly as I'd hope.
A tip to anyone else here who wants to do this: You want gpg-agent, and you absolutely need to use a newer build of OpenSSH than the one that ships with Windows 10 currently. Remove that and go find the official distribution on GitHub or Chcoolatey so you have a version that supports that key type. Then you also need to make sure to set up the environment variable GIT_SSH to point to that version of OpenSSH or else Git for Windows will try to use its own older build and then you will spend a week trying to figure out how to make it work.
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).
Means I can SSH into any box that has that key on it, or push/pull repos from anywhere as long as I have a yubikey with me.
I also used https://www.jabberwocky.com/software/paperkey/ to make a backup, and have that and a spare yubikey stored elsewhere securely.
(You can create the key on the yubikey directly, but then I think it's not possible to have a backup yubikey)
A $25 blue Yubikey only supports U2F, which requires at least OpenSSH 8.2 on the host you're connecting to. U2F is the standard used for logging into websites with a security key, and there are many vendors other than yubikey.
A $45 black Yubikey 5 also supports OpenPGP and Smart Card/PIV which can do SSH without server updates (with a bit of software installation on your end).
Also I kind of get, you can't make a backup key. But in the end, if they key is lost, you use also mostly just another password again. But for me, I would much prefer to create a second key somehow.
Yubico supply a tool that lets you perform a "factory reset" giving you a random key (effectively: instantly invalidating all credentials you previously used) but not one that would let you pick the key. IIRC The relevant standard is clear that manufacturers should not offer this capability as it's obvious how it would get exploited.
This also stores the private key on the security key itself, removing the need for the key handle file.
For more details, see the release notes for FIDO2 on OpenSSH: https://www.openssh.com/txt/release-8.2
https://www.yubico.com/blog/github-now-supports-ssh-security...
With resident keys you can load the ssh key description from the key directly into the ssh-agent.
$ ssh-keygen -t ecdsa-sk -O resident $ ssh-add -K $ ssh git@github.com
I use a U2F key now, and that key I just have in ~/.ssh. It's useless without my U2F fob anyway. (Right?)
Technically what's happening is that the valuable private key is in a sense in that file you're not worried about. But, you're safe not worrying about it, because it was encrypted by the Security Key, and only the Security Key knows how to decrypt it, so even though in one sense it's the private key and very important, because it's encrypted it's not a big deal if anybody learns it, as they couldn't possibly decrypt it. The contents of the file are given back to the Security Key when you use SSH to connect to (say) GitHub and in fact it will decrypt them to discover your private key, then use it, and then forget it again immediately, but it could (hypothetically) instead store a library of all credentials and use the random contents of the file to just look up the right credentials in the huge library. That would cost $$$ and Security Keys are (relatively) cheap.
It's OK to completely forget that technical description, the designers of Security Keys specifically intended that you needn't care how the magic is done, I have explained it only to reassure anyone puzzling how this could possibly work.