5 ms·

Yes, it's easy, you don't need gpg-agent or anything, just do `ssh-add -K`: https://www.stavros.io/posts/u2f-fido2-with-ssh/ https://www.stavros.io/posts/u2f-f

Yes, it's easy, you don't need gpg-agent or anything, just do `ssh-add -K`: https://www.stavros.io/posts/u2f-fido2-with-ssh/ https://www.stavros.io/posts/u2f-fido2-with-ssh/

allset_ 5y ago
You do need a fairly recent version of OpenSSH though.
- StavrosK 5y ago
  That's true, but it's old enough that you'll probably have it, and I think that's the only way that'll work with this Github feature, since it's U2F support they're adding.
RcouF1uZ4gsC 5y ago
This was exactly what I was looking for
OJFord 5y ago
Does this work with existing keys, including ones generated on the device? (as distinct from 'resident' here which seems to generate on computer and copy to device, anything else special?) Basically wondering if I can drop gpg-agent (for SSH auth purposes anyway) and 'sshcontrol' without changing key.
- StavrosK 5y ago
  No, if you don't use resident keys you need the files (as the keys need to come from somewhere). The keys aren't copied to the device, they're generated on the device, more or less.
  - OJFord 5y ago
    > No, if you don't use resident keys you need the files (as the keys need to come from somewhere). 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?
    - StavrosK 5y ago
      > I'm talking about using an already provisioned device with this new-ish OpenSSH feature 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) .
- tialaramex 5y ago
  No. It can't work because the material you want to replicate doesn't exist in this scenario.
  - OJFord 5y ago
    What material do I want/need to replicate?
    - tialaramex 5y ago
      The "ID" for this credential. For residential credentials, that lives on the Security Key, but without them the Security Key just mints a new random ID, plus a key pair each time it is told to enroll. 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).
loulouxiv 5y ago
And adding -O resident to the ssh-keygen command. However it is only supported on FIDO2 keys (which are spec'd to ask a PIN when using a resident key)
- danieldk 5y ago
  Not just FIDO2, I think you also need CTAP 2.1 for credential management/protection. E.g. my pre 5.2.3 firmware (which adds credential management) YubiKey Nano fails with: debug1: ssh_sk_enroll: /dev/hidraw0 does not support credprot, refusing to create unprotected resident/verify-required key
  - StavrosK 5y ago
    Yes, your USB key needs to have resident key support. I'm looking forward to the Solo key (which is now one or two years delayed from when it was originally supposed to come out), which will apparently support thousands of resident keys. You don't need so many for SSH, but it's great for usernameless/passwordless auth with websites.
bostik 5y ago
And if you get nonsensical keygen errors even after enabling the PIN, check that you enabled it for the right embedded application: https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html

Yes, it's easy, you don't need gpg-agent or anything, just do `ssh-add -K`: https://www.stavros.io/posts/u2f-fido2-with-ssh/ https://www.stavros.io/posts/u2f-fido2-with-ssh/

allset_ 5y ago

You do need a fairly recent version of OpenSSH though.

StavrosK 5y ago
That's true, but it's old enough that you'll probably have it, and I think that's the only way that'll work with this Github feature, since it's U2F support they're adding.

RcouF1uZ4gsC 5y ago

This was exactly what I was looking for

OJFord 5y ago

Does this work with existing keys, including ones generated on the device? (as distinct from 'resident' here which seems to generate on computer and copy to device, anything else special?) Basically wondering if I can drop gpg-agent (for SSH auth purposes anyway) and 'sshcontrol' without changing key.

StavrosK 5y ago
No, if you don't use resident keys you need the files (as the keys need to come from somewhere). The keys aren't copied to the device, they're generated on the device, more or less.
- OJFord 5y ago
  > No, if you don't use resident keys you need the files (as the keys need to come from somewhere). 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?
  - StavrosK 5y ago
    > I'm talking about using an already provisioned device with this new-ish OpenSSH feature 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) .
tialaramex 5y ago
No. It can't work because the material you want to replicate doesn't exist in this scenario.
- OJFord 5y ago
  What material do I want/need to replicate?
  - tialaramex 5y ago
    The "ID" for this credential. For residential credentials, that lives on the Security Key, but without them the Security Key just mints a new random ID, plus a key pair each time it is told to enroll. 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).

loulouxiv 5y ago

And adding -O resident to the ssh-keygen command. However it is only supported on FIDO2 keys (which are spec'd to ask a PIN when using a resident key)

danieldk 5y ago
Not just FIDO2, I think you also need CTAP 2.1 for credential management/protection. E.g. my pre 5.2.3 firmware (which adds credential management) YubiKey Nano fails with: debug1: ssh_sk_enroll: /dev/hidraw0 does not support credprot, refusing to create unprotected resident/verify-required key
- StavrosK 5y ago
  Yes, your USB key needs to have resident key support. I'm looking forward to the Solo key (which is now one or two years delayed from when it was originally supposed to come out), which will apparently support thousands of resident keys. You don't need so many for SSH, but it's great for usernameless/passwordless auth with websites.

bostik 5y ago

And if you get nonsensical keygen errors even after enabling the PIN, check that you enabled it for the right embedded application: https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html