similar to: u2f seed

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?

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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