[michaelt]

> be extra careful when using SSH forwarding (the -A option), as the server can then ask your computer to authenticate to other servers on your behalf.

That would require an extra press of the token's button for each extra authentication, right?

[StavrosK]

That's a good point, I haven't tried it but I think you're right, which is another great benefit of using hardware tokens.

[staticassertion]

I would assume the agent caches the key for signing.

Would someone please confirm this? If it did require another key press that would be pretty huge.

[tialaramex]

> I would assume the agent caches the key for signing.

For that to happen the agent would need to have some way to get the key out of the FIDO authenticator, which is deliberately not intended to be possible. I will now go away and confirm that this behaves as I expected and update this message shortly.

Update: Yes, the OpenSSH agent just has code to go talk to the authenticator each time it needs to sign something. The authenticator may or may not (most seem to not) allow this to happen without verifying user presence (e.g. via a button press or touching a contact) but even if your device does allow this the signed payload says whether the user was present, so a remote SSHD can (if it wanted) demand to see signed evidence of user presence or refuse login, and I think a SSH agent can't fake that without help from the FIDO authenticator itself.

[jlgaddis]

> ... so a remote SSHD can (if it wanted) demand to see signed evidence of user presence or refuse login, ...

I'd like to be able to, server-side, 1) require that the private key used for authentication be stored on a hardware device and 2) require user presence, but I've never read or heard that this is possible (granted, I haven't looked into too much).

If you have links to any documents that discuss how to implement this, I'd appreciate you sharing them. The only relevant documentation I can find is regarding FIDO/U2F support and even the release notes for 8.2 mention that "OpenSSH does not currently make use of this [attestation certificate]".

[tialaramex]

So there's two parts, let's take them separately.

> 1) require that the private key used for authentication be stored on a hardware device

So for this you're going to need the attestation data, which as you observe OpenSSH currently doesn't do anything with. It is willing to stash it in a file, and because it's a certificate it's safe for the token's owner to send this somewhere. So you could construct a mechanism to examine the attestation file and decide whether to accept the proffered public key based on that attestation. e.g. "This is a genuine Yubikey 5C, so OK" or "This is a Crap Corp Funky Fake, no thanks".

I expect this would be a bunch of work, and I don't expect Free Software people to help build something to do it any time soon. But from what I can see it's possible with the components that already exist. Maybe somebody who really wants this will do all the work and put it on GitHub.

> 2) require user presence

The FIDO "options" bitflags have a flag for "user presence" (sometimes labelled UP). If this isn't set, user presence was not checked by the authenticator.

The FIDO authenticator includes this options parameter as part of the message it's signing.

So this means if a SSH client/ agent sends you an options field with UP set, but actually user presence wasn't checked it won't be able to provide a signature that matches. The SSH server doesn't need to do anything special except look at the UP bitflag if it cares (all WebAuthn servers are required to check this, it's on the long list of steps to perform WebAuthn authentication properly).

To be fair this isn't OpenSSH (though I'm sure they have at least somebody paying attention) it's FIDO itself that designed the signatures to also sign the user presence indication, they couldn't have avoided it.

[jlgaddis]

> I expect this would be a bunch of work, and I don't expect Free Software people to help build something to do it any time soon.

That's basically the conclusion I ended up at but I was hoping you were aware of some recent progress that I didn't know about! Thank you, though, I certainly appreciate the response.

[staticassertion]

Oh duh, of course. Yes please confirm! Super eager to hear if this is the case.

[mightybyte]

It depends on how you configured your Yubikey. I believe you can configure it both ways.