similar to: Another U2F documentation issue

I spent some time today implementing support for loading U2F keys into the SSH agent from my AsyncSSH library. I got it working, but along the way I ran into a few issues I wanted to report: First, it looks like the value of SSH_AGENT_CONSTRAIN_EXTENSION has changed from the value 3 defined at https://tools.ietf.org/html/draft-miller-ssh-agent-02

Hi, As of this morning, OpenSSH now has experimental U2F/FIDO support, with U2F being added as a new key type "sk-ecdsa-sha2-nistp256 at openssh.com" or "ecdsa-sk" for short (the "sk" stands for "security key"). If you're not familiar with U2F, this is an open standard for making inexpensive hardware security tokens. These are easily the cheapest way

Hi Damien, On Nov 14, 2019, at 3:26 PM, Damien Miller <djm at mindrot.org> wrote: > On Fri, 1 Nov 2019, Damien Miller wrote: >> As of this morning, OpenSSH now has experimental U2F/FIDO support, with >> U2F being added as a new key type "sk-ecdsa-sha2-nistp256 at openssh.com" >> or "ecdsa-sk" for short (the "sk" stands for "security

On Fri, 15 Nov 2019, Damien Miller wrote: > On Fri, 1 Nov 2019, Damien Miller wrote: > > > Hi, > > > > As of this morning, OpenSSH now has experimental U2F/FIDO support, with > > U2F being added as a new key type "sk-ecdsa-sha2-nistp256 at openssh.com" > > or "ecdsa-sk" for short (the "sk" stands for "security key").

Hi, So I finally have time to test the u2f support but so far I haven't been very successful, Specifically, current HEAD has SSH_SK_VERSION_MAJOR 0x00040000 and I can't seem to find a matching libfido2 version, current HEAD of Yubico/libfido2 is 0x00020000 Is there a more up to date libfido2 or a particular commit of openssh-portable I should be using? thanks Sean

I've had a patch on the bugzilla for a while related to U2F with support for a few additional settings such as providing a path to a specific key to use instead of the first one found and setting if user presence is required when using the key. Is there any objection to folding those parts in if appropriate? Joseph, to offer comment on NIST P-256. There was originally quite a limited subset

Hi, OpenSSH 8.2p1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a feature release. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via git using the instructions at

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

I was recently looking at verifying the attestation data (ssh-sk-attest-v00) for a SK key, but I believe the data saved in this structure is insufficient for completing verification of the attestation. While the structure has enough information for U2F devices, FIDO2 devices sign their attestation over a richer "authData" blob [1] (concatenated with the challenge hash). The authData blob

Hey, Recently, the FIDO alliance announced U2F [1], and Google announced that it supports U2F tokens (?security keys?) for Google accounts [2]. As the spec is not a very short read, I gave a presentation last week about U2F which may be a good quick introduction to the details [3]. For the rest of this mail, I?ll assume that you read either my presentation or the spec, but feel free to post any

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?

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

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

Hey, Judging from the (private) responses I?ve got, there is quite a bit of interest in the U2F feature I proposed a while ago. Therefore, I?ve taken some time to resolve the remaining issues, and I think the resulting patch (attached to this email) is in quite a good state now. I also posted the new version of the patch to https://bugzilla.mindrot.org/show_bug.cgi?id=2319 (which I?ve opened

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

On Thu, Feb 26, 2015 at 8:44 AM, Damien Miller <djm at mindrot.org> wrote: > On Thu, 26 Feb 2015, Michael Stapelberg wrote: > > > At this point it should be obvious, but let me state that I don?t have > > motivation/time to spend on this right now, given that upstream shows > > 0 interest in this at all :(. > > That's not how I recall it. When you

> I?ve spent some time (together with Christian and Thomas) hacking on > U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s > not complete, but it should be good enough to get the discussion going > :). Please see the two attached files for the patch. This is great - I'm looking forward to it! :) I've implemented U2F into another (C-based) application these

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

At present whenever non-resident keys are used the key_handle required to use the token must be given by selecting the ssh 'private key' file generated by ssh-keygen during negotiation. In the more common webauthn context this key_handle would be stored on the server and then transmitted to the client during authentication. The client then checks connected tokens for one that reports it

>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,