Mailing List Archive

On Tue, 31 Dec 2019, Fox, Kevin M wrote:

> When using openssh with a u2f key, you generate a key via:
> ssh-keygen -t ecdsa-sk
>
> Each time you run it, it gives a different key pair. (Randomly seeming).
>
> A differently generated key pair is not valid with the first's public key.
>
> All good so far, but you run into a problem if:
>
> You generate a keypair (A).
> You register your public key for (A) on a bunch of ssh servers.
> You take your fido2 key to a second client machine and try and login to your servers.
>
> It kind of defeats the purpose of being able to have a portable
> keyfob.

It's possible to use the key on another machine if copy the private key
you generated on the original machine over. U2F is almost completely
stateless, so there's no way of storing the key on the token itself (for
U2F-only tokens anyway)

> If there was a way to seed the generation phase manually, then
> the same seed can be used on each client machine so that the ssh
> pub/private key doesn't have to be transferred along with the u2f
> keyfob?

That's not possible unfortunately, the U2F protocol doesn't offer any way
to set the seed and AFAIK doesn't specify how the tokens generate the keys.

There is some good news though, the FIDO2 protocol does support "resident
keys" - i.e. keys that can be stored on, and retrieved from a token. I've
just started landing support for these in OpenSSH last week.

To use them, you'll need a FIDO2 token that support resident keys. You'll
also need to set a PIN on the token, as retrieving the keys requires
authentication. Once you've done this, you can generate a resident key
by running "ssh-keygen -Oresident -t ecdsa-sk" (along with any other usual
options).

You'll get back a keypair that you can use exactly like any other, but
you'll also be able to download it again from the token if you move it to
another host. At present the only way I've implemented so far is via
"ssh-add -O", which will download all resident keys and add them to a
ssh-agent, but I'll add an option to ssh-keygen to explicitly download them
to public/private key files shortly.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this. It just needs to be exposed to the user. The content of the private keyfile in ssh is generated somehow. Where is that done?

Thanks,
Kevin

________________________________________
From: Damien Miller <djm@mindrot.org>
Sent: Wednesday, January 1, 2020 9:36 PM
To: Fox, Kevin M
Cc: openssh-unix-dev@mindrot.org
Subject: Re: u2f seed

On Tue, 31 Dec 2019, Fox, Kevin M wrote:

> When using openssh with a u2f key, you generate a key via:
> ssh-keygen -t ecdsa-sk
>
> Each time you run it, it gives a different key pair. (Randomly seeming).
>
> A differently generated key pair is not valid with the first's public key.
>
> All good so far, but you run into a problem if:
>
> You generate a keypair (A).
> You register your public key for (A) on a bunch of ssh servers.
> You take your fido2 key to a second client machine and try and login to your servers.
>
> It kind of defeats the purpose of being able to have a portable
> keyfob.

It's possible to use the key on another machine if copy the private key
you generated on the original machine over. U2F is almost completely
stateless, so there's no way of storing the key on the token itself (for
U2F-only tokens anyway)

> If there was a way to seed the generation phase manually, then
> the same seed can be used on each client machine so that the ssh
> pub/private key doesn't have to be transferred along with the u2f
> keyfob?

That's not possible unfortunately, the U2F protocol doesn't offer any way
to set the seed and AFAIK doesn't specify how the tokens generate the keys.

There is some good news though, the FIDO2 protocol does support "resident
keys" - i.e. keys that can be stored on, and retrieved from a token. I've
just started landing support for these in OpenSSH last week.

To use them, you'll need a FIDO2 token that support resident keys. You'll
also need to set a PIN on the token, as retrieving the keys requires
authentication. Once you've done this, you can generate a resident key
by running "ssh-keygen -Oresident -t ecdsa-sk" (along with any other usual
options).

You'll get back a keypair that you can use exactly like any other, but
you'll also be able to download it again from the token if you move it to
another host. At present the only way I've implemented so far is via
"ssh-add -O", which will download all resident keys and add them to a
ssh-agent, but I'll add an option to ssh-keygen to explicitly download them
to public/private key files shortly.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, 2 Jan 2020, Fox, Kevin M wrote:

> In the u2f protocol, my understanding is in the normal case, the web
> browser seeds the keypair process with the hostname of the remote
> server. In the case of ssh, the hostname is probably not what I would
> want to do. But the u2f protocol seems to have a way to handle this.
> It just needs to be exposed to the user. The content of the private
> keyfile in ssh is generated somehow. Where is that done?

The key generation is done solely by the token. There are several
strings (challenge, application) that OpenSSH sends to the token that
are inputs the the process, but I'd expect most tokens would have
onboard CSPRNGs that they use the actually generate the keys.

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From my understanding, somehow a website talking through the web browser is able to get the same keypair used no matter which computer the keyfob is plugged into. I'm wondering if we can use the same mechanism there. If application is part of the process, maybe allowing the application to be specified by the user rather then being randomly generated by openssh would be enough?

Thanks,
Kevin

________________________________________
From: Damien Miller <djm@mindrot.org>
Sent: Thursday, January 2, 2020 2:36 PM
To: Fox, Kevin M
Cc: openssh-unix-dev@mindrot.org
Subject: Re: u2f seed

On Thu, 2 Jan 2020, Fox, Kevin M wrote:

> In the u2f protocol, my understanding is in the normal case, the web
> browser seeds the keypair process with the hostname of the remote
> server. In the case of ssh, the hostname is probably not what I would
> want to do. But the u2f protocol seems to have a way to handle this.
> It just needs to be exposed to the user. The content of the private
> keyfile in ssh is generated somehow. Where is that done?

The key generation is done solely by the token. There are several
strings (challenge, application) that OpenSSH sends to the token that
are inputs the the process, but I'd expect most tokens would have
onboard CSPRNGs that they use the actually generate the keys.

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-01-02, "Fox, Kevin M" <Kevin.Fox@pnnl.gov> wrote:

> In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this.

There is no guarantee that the U2F token derives the key pair in a
deterministic fashion from the challenge/application parameters
passed during registration.

For instance, if I read the firmware code correctly, the Solokey
creates the key material using its built-in random number generator
and only uses its master secret and the application parameter to
wrap the key for the key handle.

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case?

What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key?

Thanks,
Kevin

________________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+kevin.fox=pnnl.gov@mindrot.org> on behalf of Christian Weisgerber <naddy@mips.inka.de>
Sent: Thursday, January 2, 2020 3:42 PM
To: openssh-unix-dev@mindrot.org
Subject: Re: u2f seed

On 2020-01-02, "Fox, Kevin M" <Kevin.Fox@pnnl.gov> wrote:

> In the u2f protocol, my understanding is in the normal case, the web browser seeds the keypair process with the hostname of the remote server. In the case of ssh, the hostname is probably not what I would want to do. But the u2f protocol seems to have a way to handle this.

There is no guarantee that the U2F token derives the key pair in a
deterministic fashion from the challenge/application parameters
passed during registration.

For instance, if I read the firmware code correctly, the Solokey
creates the key material using its built-in random number generator
and only uses its master secret and the application parameter to
wrap the key for the key handle.

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://protect2.fireeye.com/v1/url?k=c4371812-988227ab-c4373207-0cc47adc5fce-56c2948a65834232&q=1&e=0f45e6c0-4544-44ae-af8d-3d64af881ea7&u=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, 2020-01-02 at 23:35 +0000, Fox, Kevin M wrote:
> From my understanding, somehow a website talking through the web
> browser is able to get the same keypair used no matter which computer
> the keyfob is plugged into.

That's right ... there wouldn't be much use to the token otherwise.

> I'm wondering if we can use the same mechanism there. If application
> is part of the process, maybe allowing the application to be
> specified by the user rather then being randomly generated by openssh
> would be enough?

To operate like a website, you need the two stage registration then
login/authentication process.

When you register with a U2F CTAP token, the registration info that
must be stored by the remote website includes a 'key handle'. In most
of the implementations, the key handle is, in fact, a wrapped key which
can be unwrapped by the token. So on Login (or Authentication in the
FIDO speak), the website presents they key handle and some parameters
(including origin information) which are validated and if the
validation passes, the token unwraps the key handle to get the website
unique key and signs the challenge combined with a key or token unique
counter and returns the signature and the counter value, which is used
by the remote site to verify the login.

To get this to work with ssh, you need something that corresponds to
the data that is stored on registration. My understanding of the way
ssh works is that we don't really have that ... the server expects you
to sign a challenge which it then compares with your remote public key.
There's nothing the remote server initially passes back to the local
that would allow the U2F token to use as a key handle ... at least not
without significantly altering the current protocol.

James

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, 2 Jan 2020, James Bottomley wrote:

> To get this to work with ssh, you need something that corresponds to
> the data that is stored on registration. My understanding of the way
> ssh works is that we don't really have that ... the server expects you
> to sign a challenge which it then compares with your remote public
> key. There's nothing the remote server initially passes back to the
> local that would allow the U2F token to use as a key handle ... at
> least not without significantly altering the current protocol.

Right - you wouldn't be doing pubkey authentication any more, you'd be
doing some new authentication method. I chose not to go this way when
implementing FIDO support in OpenSSH because SSH users are familiar with
public key authentication and there is a large amount of infrastructure
that already uses them.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-01-02, "Fox, Kevin M" <Kevin.Fox@pnnl.gov> wrote:

> That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case?

Let's cut this short without losing ourselves in details: Even if
you resend exactly the same U2F registration message, the token may
still create a different key pair. Only a very minimal U2F token
without an on-board RNG might derive the key pair purely from the
parameters in the registration message; I don't know if any such
devices exist.

This actually made me curious and I checked the simple FIDO1 U2F
token I have here (HyperFIDO Titanium): It issues a different key
pair each time, even if the registration message is exactly the
same. As would the Solokey.

Every time you run "ssh-keygen -t ecdsa-sk", the token will give
you a different key pair, and this is enforced by the token itself.

> What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key?

The OpenSSH private key file stores the U2F key handle. The key
handle is an opaque blob which you need to pass back to the token
so it can find the private key.

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

How does a u2f website then authenticate the same user, with the same keyfob, on a different machine? If that actually works, then we should be able to use the same mechanism. Maybe it doesn't, and some people are going to be locked out of their account when their machine fails and they have to go to another one. portability was one of the selling points of u2f though I thought. Maybe I'll try and dig up the u2f spec and see if there is any detail in it.

Thanks,
Kevin

________________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+kevin.fox=pnnl.gov@mindrot.org> on behalf of Christian Weisgerber <naddy@mips.inka.de>
Sent: Friday, January 3, 2020 5:01 AM
To: openssh-unix-dev@mindrot.org
Subject: Re: u2f seed

On 2020-01-02, "Fox, Kevin M" <Kevin.Fox@pnnl.gov> wrote:

> That sounds like the application param is still used as part of the process though? Would allowing the user to specify the application work in the Solokey case?

Let's cut this short without losing ourselves in details: Even if
you resend exactly the same U2F registration message, the token may
still create a different key pair. Only a very minimal U2F token
without an on-board RNG might derive the key pair purely from the
parameters in the registration message; I don't know if any such
devices exist.

This actually made me curious and I checked the simple FIDO1 U2F
token I have here (HyperFIDO Titanium): It issues a different key
pair each time, even if the registration message is exactly the
same. As would the Solokey.

Every time you run "ssh-keygen -t ecdsa-sk", the token will give
you a different key pair, and this is enforced by the token itself.

> What is stored in the private keyfile? The documentation says no private key is stored there. So is it just information used to reseed the public/private key?

The OpenSSH private key file stores the U2F key handle. The key
handle is an opaque blob which you need to pass back to the token
so it can find the private key.

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://protect2.fireeye.com/v1/url?k=102d876a-4c98b8d3-102dad7f-0cc47adc5fce-f963eec20cc653fd&q=1&e=445ca71b-c946-44b4-a663-d2d3fc1f288f&u=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Fri, 2020-01-03 at 16:15 +0000, Fox, Kevin M wrote:
> How does a u2f website then authenticate the same user, with the same
> keyfob, on a different machine?

I thought I was clear the last time: The remote website account
creation process stores a u2f key handle in the remote website as part
of the user registration information (the token generates a new key for
*every* registration meaning every remote website has a different
authentication key). This key handle is usually implemented as the
wrapped key for the specific website, so every time you access that
website account from whatever client system, the server presents the
client with the stored key handle, which the client passes on to the
token, so you get the same key back because the token unwraps the key
handle from the server to use as the authentication key.

> If that actually works, then we should be able to use the same
> mechanism. Maybe it doesn't, and some people are going to be locked
> out of their account when their machine fails and they have to go to
> another one. portability was one of the selling points of u2f though
> I thought. Maybe I'll try and dig up the u2f spec and see if there is
> any detail in it.

There's nothing in the current ssh public key based process that can
present remote information to the local client. Without that, you have
to get the token's key handle locally which means if you take the
token to a different local client, you also need to bring the key
handle as well because the remote won't provide it.

James

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020/01/03 16:15, Fox, Kevin M wrote:
> How does a u2f website then authenticate the same user, with the same
> keyfob, on a different machine? If that actually works, then we should
> be able to use the same mechanism. Maybe it doesn't, and some people
> are going to be locked out of their account when their machine fails
> and they have to go to another one. portability was one of the selling
> points of u2f though I thought. Maybe I'll try and dig up the u2f spec
> and see if there is any detail in it.

With a website, the site can store information that is passed back via
the client's browser to use as a key handle.

As said in James Bottomley's message and djm's reply, doing similar in
ssh is not possible without significantly changing the protocol:

https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-January/038092.html

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Ohhh... sorry. Somehow I missed that. I understand now. Yeah. there is nothing we can do then.

Thanks for all the help.

Kevin

________________________________________
From: James Bottomley <James.Bottomley@HansenPartnership.com>
Sent: Friday, January 3, 2020 8:34 AM
To: Fox, Kevin M; Christian Weisgerber; openssh-unix-dev@mindrot.org
Subject: Re: u2f seed

On Fri, 2020-01-03 at 16:15 +0000, Fox, Kevin M wrote:
> How does a u2f website then authenticate the same user, with the same
> keyfob, on a different machine?

I thought I was clear the last time: The remote website account
creation process stores a u2f key handle in the remote website as part
of the user registration information (the token generates a new key for
*every* registration meaning every remote website has a different
authentication key). This key handle is usually implemented as the
wrapped key for the specific website, so every time you access that
website account from whatever client system, the server presents the
client with the stored key handle, which the client passes on to the
token, so you get the same key back because the token unwraps the key
handle from the server to use as the authentication key.

> If that actually works, then we should be able to use the same
> mechanism. Maybe it doesn't, and some people are going to be locked
> out of their account when their machine fails and they have to go to
> another one. portability was one of the selling points of u2f though
> I thought. Maybe I'll try and dig up the u2f spec and see if there is
> any detail in it.

There's nothing in the current ssh public key based process that can
present remote information to the local client. Without that, you have
to get the token's key handle locally which means if you take the
token to a different local client, you also need to bring the key
handle as well because the remote won't provide it.

James

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Fri, 3 Jan 2020, Stuart Henderson wrote:

> As said in James Bottomley's message and djm's reply, doing similar in
> ssh is not possible without significantly changing the protocol:
>
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-January/038092.html

so how does Google change the protocol to support u2f?

not supporting authentication from multiple machines seems to defeat the purpose
of adding u2f support.

David Lang
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

David Lang:

> not supporting authentication from multiple machines seems to defeat the
> purpose of adding u2f support.

It works just like other SSH key types. You have a private SSH key
and a public one, and you can copy the private key to multiple
machines or load it into ssh-agent and use agent forwarding.

The only difference is that the private SSH key on its own is
insufficient and requires the cooperation of the FIDO/U2F authenticator.

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 01/03/2020 05:34 PM, James Bottomley wrote:
> There's nothing in the current ssh public key based process that can
> present remote information to the local client.

Remote information *external to the SSH authentication procedure
itself*. IIUC, at the point where the client starts to authenticate,
both sides are already in agreement what the server's (hopefully unique)
pubkey is, that the server has demonstrated possession of the matching
private key, and which server-side account the client asks to access.

In other words, we may not be able to come up with a wrapped key that is
unique to the combo of target account and token and kept secret from
everyone else, but we can hash us a long-lived ID for the target account
alone that at least promises to have some good randomness, if poor
secrecy. Would that, compared to doing the token auth essentially
memoryless/"first time ever" every time, buy us some worthwhile
top-level properties? *Beyond* the "hold, that's a *different* pubkey
the server has now!" check that the known_host cacheing already allows
*sans* the U2F part?

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Robert-Koch-Straße 9
64331 Weiterstadt

On Fri, 3 Jan 2020, Christian Weisgerber wrote:

> David Lang:
>
>> not supporting authentication from multiple machines seems to defeat the
>> purpose of adding u2f support.
>
> It works just like other SSH key types. You have a private SSH key
> and a public one, and you can copy the private key to multiple
> machines or load it into ssh-agent and use agent forwarding.
>
> The only difference is that the private SSH key on its own is
> insufficient and requires the cooperation of the FIDO/U2F authenticator.

part of the value of u2f is that there is not anything that you need to install
on every system.

turning u2f into just a way to unlock ssh keys may be an easy way to use a u2f
key, but it's missing out on the value of u2f.

As I said, Google has a modified sshd that they use with u2f keys that does not
require anything be copied or stored on the client machine.

Yes, it modifies the protocol to pass a server/application name, but why is it
bad to add a new authentication mechanism? There is provision for the ssh
protocol to issue a prompt for a password, that could be (ab)used to pass the
name needed for u2f to work properly.

David Lang
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Fri, 3 Jan 2020, David Lang wrote:

> On Fri, 3 Jan 2020, Christian Weisgerber wrote:
>
> > David Lang:
> >
> > > not supporting authentication from multiple machines seems to defeat the
> > > purpose of adding u2f support.
> >
> > It works just like other SSH key types. You have a private SSH key
> > and a public one, and you can copy the private key to multiple
> > machines or load it into ssh-agent and use agent forwarding.
> >
> > The only difference is that the private SSH key on its own is
> > insufficient and requires the cooperation of the FIDO/U2F authenticator.
>
> part of the value of u2f is that there is not anything that you need to
> install on every system.

Well, see what I said earlier about resident keys. If you have a FIDO2 token
and generate a resident key then you don't need to pre-arrange anything.

> As I said, Google has a modified sshd that they use with u2f keys that does
> not require anything be copied or stored on the client machine.

I'm fairly sure that this isn't the case. Can you point me at some
documentation of this?

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 6 Jan 2020, Damien Miller wrote:

> On Fri, 3 Jan 2020, David Lang wrote:
>
>> On Fri, 3 Jan 2020, Christian Weisgerber wrote:
>>
>>> David Lang:
>>>
>>>> not supporting authentication from multiple machines seems to defeat the
>>>> purpose of adding u2f support.
>>>
>>> It works just like other SSH key types. You have a private SSH key
>>> and a public one, and you can copy the private key to multiple
>>> machines or load it into ssh-agent and use agent forwarding.
>>>
>>> The only difference is that the private SSH key on its own is
>>> insufficient and requires the cooperation of the FIDO/U2F authenticator.
>>
>> part of the value of u2f is that there is not anything that you need to
>> install on every system.
>
> Well, see what I said earlier about resident keys. If you have a FIDO2 token
> and generate a resident key then you don't need to pre-arrange anything.

I'd much rather register the token with each foreign host than have to install a
key on all devices that I may end up authenticating from.

>> As I said, Google has a modified sshd that they use with u2f keys that does
>> not require anything be copied or stored on the client machine.
>
> I'm fairly sure that this isn't the case. Can you point me at some
> documentation of this?

I worked there and could use my token from any computer without having to do
anything other than insert the key. As a SRE, I also carried an encrypted USB
drive that contained one-time-passwords just in case then u2f based tokens
didn't work.

David Lang
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 5 Jan 2020, David Lang wrote:

> I worked there and could use my token from any computer without having
> to do anything other than insert the key.

No - Google uses SSH certificates with keys backed in the tokens
(documented in [1]). This isn't U2F, they are regular SSH keys/certs
and the hardware in this case is behaving more like a PKCS#11 token
than a U2F device.

-d

[1] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45728.pdf
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev