similar to: [Bug 2319] New: [PATCH REVIEW] U2F authentication

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

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

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 :(. Hence, any help on this is welcome. On Sat, Dec 27, 2014 at 1:53 AM, Thomas Habets <thomas at habets.se> wrote: > On 24 December 2014 at 18:57, Michael Stapelberg > <stapelberg+openssh at google.com> wrote:

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

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2472 Bug ID: 2472 Summary: Add support to load additional certificates Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-agent Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=3188 Bug ID: 3188 Summary: Problems creating a second ecdsa-sk key for a second Yubikey Product: Portable OpenSSH Version: 8.3p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh-keygen

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

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

On 2019-11-14, Damien Miller <djm at mindrot.org> wrote: > Please give this a try - security key support is a substantial change and > it really needs testing ahead of the next release. Hi Damien, Thanks for working on security key support, this is a really nice feature to have in openssh. My non-FIDO2 security key (YubiKey NEO) doesn't work with the latest changes to openssh

Hi, When we added U2F support, we also extended the interface used by ssh and ssh-agent to invoke the $SSH_ASKPASS program. Originally, the askpass prompt was used to obtain passphrases for ssh in cases where it was not possible to read them from the terminal. Later it was (ab)used for showing confirmation prompts for each use of any key that was added to the agent using "ssh-add -c".

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

Hello, I forgot to mention one other issue in my previous e-mail about the ssh-agent documentation for U2F keys. Right now, https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.u2f <https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.u2f> has the following text: > ssh-agent requires a protocol extension to support U2F keys. At > present the

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

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

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