similar to: [PATCH] Early request for comments: U2F authentication

https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Bug ID: 2319 Summary: [PATCH REVIEW] U2F authentication Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at

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

> 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

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

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

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

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

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").

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

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

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

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

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

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