Sourcehut began to silently support this last week as well, as the appropriate libraries used to validate SSH keys got updated. Sadly work on supporting FIDO2 as a second factor is blocked by the combination of the insistence that every feature of Sourcehut works without JS and Webauthn lacking a non-JS way to use it.
I know that sr.ht does, GitHub probably does as well. There’s no real reason why it wouldn’t be supported by services, I believe that the reason only ecdsa-sk is shown is that most keys on the market don’t support ed25519 yet.
I’ve seen it recommended to have 2 physical tokens, one of them as a backup access in case the primary one is lost. How would I use this GitHub setup with 2 physical FIDO2 tokens? Should I create 2 separate SSH keys and make sure to configure both of them everywhere? Or some other way?
There are two different kinds of authentication for GitHub:
Authentication needed for repo operations
Authentication needed for admin operations
You can already use WebAuthn (including with a key stored in the TPM on Windows, probably elsewhere, or in the macOS Keychain if you install the fake U2F driver) for the second category, as well as two-factor auth apps. It’s easy to add multiple different keys here, so if you lose one you don’t lose the ability to log in.
If you can log into the admin interface, then it doesn’t really matter if you lose your SSH key. You can always register new ones.
First, the key is deterministically derived using the U2F device. (It’s always the same key.) That means the key could be stolen if you’re accidentally using a compromised SSH client, for instance. Unlike a key on a smart card or a Yubikey in PIV mode, where the root key never leaves the device.
Presumably to mitigate this risk, Github also requires a TOTP one-time token if you’re using U2F. You have to push the button on your device, it spits out a one-time token that GitHub can verify.
But then what value does U2F add in the first place, if you still need to also use TOTP?
The key is generated via FIDO2, and it’s not deterministic. With FIDO2 (the successor to U2F, with backwards compatibility) for registration the key takes as parameters the relaying party name (usually ssh:// for ssh keys, https://yoursite.com for websites), a challenge for attestation, the wanted key algorithm, and a few extra optional parameters. The key responds with an KeyID, an arbitrary piece of data that the should be provided to the key when wanting to use it, the public key data, and the challenge signed with that key. This data usually holds the actual private key, encrypted with an internal private key of the security key, which is then decrypted to actually use it. It’s assumed that the KeyID is unique, therefore it should(and generally is) generated using some sort of secure RNG on the security key. The flow with ssh is quite simple, when you create an SSH key with a security key, a key gets generated on it, the KeyID gets stored as the private key file, and the public key file stores the returned public key. When connecting with SSH, a challenge is issued by the server you are authenticating to, which gets passed to the key with appropriate KeyID, and the response is sent back to the server. No need for any additional TOTP tokens, which are less secure.
First, the key is deterministically derived using the U2F device. (It’s always the same key.) That means the key could be stolen if you’re accidentally using a compromised SSH client, for instance. Unlike a key on a smart card or a Yubikey in PIV mode, where the root key never leaves the device.
How can this make sense? Surely the U2F device has access to a suitable CSPRNG.
Sourcehut began to silently support this last week as well, as the appropriate libraries used to validate SSH keys got updated. Sadly work on supporting FIDO2 as a second factor is blocked by the combination of the insistence that every feature of Sourcehut works without JS and Webauthn lacking a non-JS way to use it.
This is one of the reasons why Sourcehut is appealing to me.
All examples only show
ecdsa-skkeys, but do they (GitHub, sr.ht) also supported25519-sk?The article says “Now you can use two additional key types: ecdsa-sk and ed25519-sk, where the “sk” suffix is short for “security key.”
I could swear I did ctrl+f for “ed25519” on that page, ah well. Great. Thanks!
I know that sr.ht does, GitHub probably does as well. There’s no real reason why it wouldn’t be supported by services, I believe that the reason only
ecdsa-skis shown is that most keys on the market don’t supported25519yet.I’ve seen it recommended to have 2 physical tokens, one of them as a backup access in case the primary one is lost. How would I use this GitHub setup with 2 physical FIDO2 tokens? Should I create 2 separate SSH keys and make sure to configure both of them everywhere? Or some other way?
There are two different kinds of authentication for GitHub:
You can already use WebAuthn (including with a key stored in the TPM on Windows, probably elsewhere, or in the macOS Keychain if you install the fake U2F driver) for the second category, as well as two-factor auth apps. It’s easy to add multiple different keys here, so if you lose one you don’t lose the ability to log in.
If you can log into the admin interface, then it doesn’t really matter if you lose your SSH key. You can always register new ones.
Yes, you should create 2 separate keys. A bit annoying to manage, as SSH wasn’t designed for this, but still manageable.
OK, I have a question about this design.
First, the key is deterministically derived using the U2F device. (It’s always the same key.) That means the key could be stolen if you’re accidentally using a compromised SSH client, for instance. Unlike a key on a smart card or a Yubikey in PIV mode, where the root key never leaves the device.
Presumably to mitigate this risk, Github also requires a TOTP one-time token if you’re using U2F. You have to push the button on your device, it spits out a one-time token that GitHub can verify.
But then what value does U2F add in the first place, if you still need to also use TOTP?
Maybe I’m misunderstanding something here.
The key is generated via FIDO2, and it’s not deterministic. With FIDO2 (the successor to U2F, with backwards compatibility) for registration the key takes as parameters the relaying party name (usually ssh:// for ssh keys, https://yoursite.com for websites), a challenge for attestation, the wanted key algorithm, and a few extra optional parameters. The key responds with an KeyID, an arbitrary piece of data that the should be provided to the key when wanting to use it, the public key data, and the challenge signed with that key. This data usually holds the actual private key, encrypted with an internal private key of the security key, which is then decrypted to actually use it. It’s assumed that the KeyID is unique, therefore it should(and generally is) generated using some sort of secure RNG on the security key. The flow with ssh is quite simple, when you create an SSH key with a security key, a key gets generated on it, the KeyID gets stored as the private key file, and the public key file stores the returned public key. When connecting with SSH, a challenge is issued by the server you are authenticating to, which gets passed to the key with appropriate KeyID, and the response is sent back to the server. No need for any additional TOTP tokens, which are less secure.
How can this make sense? Surely the U2F device has access to a suitable CSPRNG.