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: > > In case you?re interested, please feel free to try the patch. I?m happy > for > > any feedback. All you need is libu2f-host installed and a clean copy of > > OpenSSH 6.7p1. Apply the attached patch, delete configure, use autoreconf > > -i to regenerate it, then run ./configure --with-u2f and compile OpenSSH. > > Transferring my notes from the other thread: > > 1) PAM doesn't work (--with-pam, then UsePAM yes and > ChallengeResponseAuthentication yes) > Fix: detect loops in ssh2connect:userauth_u2f in some other way, such > as a dedicated variable in authctxt. (but also see point 5) > > 2) origin doesn't seem to be respected by YubiKeys (if I understand > the spec correctly) > Is AppID a better choice for this reason? > > 3) Include paths (probably bug in libu2f-host) > This is https://github.com/Yubico/libu2f-host/issues/13 that you filed. > > 4) What happened to 51? > MONITOR_REQ_TERM = 50, > + MONITOR_REQ_READUSERU2FKEY = 52, MONITOR_ANS_READUSERU2FKEY = 53, > > 5) Why does registration connect to the server anyway, if the server > doesn't keep state and origin is not tied to the server pubkey? > Indeed, without AuthenticationMethods registration returns the blob before > password prompt is shown. > Registration only makes sense if server writes the key handle to > ~/.ssh/authorized_keys, right? > Hmm, unless authorized_keys is signed by the server, the registration > process will never be "online" asyway, as U2F intends, so it may as > well be generated on the client and copy-pasted into the server's > authorized_keys. Enforced origin (but point 2) should prevent > accidentally pasting the same blob to multiple servers). > > Tested on: > Ubunty Trusty > OpenSSH 6.7p1 > Yubikey Security key > > > -- > typedef struct me_s { > char name[] = { "Thomas Habets" }; > char email[] = { "thomas at habets.pp.se" }; > char kernel[] = { "Linux" }; > char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; > char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; > char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; > } me_t; >
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 :(What do you expect? It's a significant change, a seemingly convoluted specification and there was no discussion with upstream before embarking on the project.> Hence, any help on this is welcome.FWIW, if u2f must not be the sole authentication then that should of course be checked by the code. //Peter
On Thu, Feb 26, 2015 at 7:33 AM, Peter Stuge <peter at stuge.se> wrote:> 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 :( > > What do you expect? It's a significant change, a seemingly convoluted > specification and there was no discussion with upstream before > embarking on the project. >I agree that it?s a significant change. With regards to discussion with upstream: before my first post, I looked for any sort of contributor guidelines on the openssh.org website and couldn?t find anything. Without any guidelines to go on, my default approach is to contact upstream by sending a patch, demonstrating the feasibility of what I?m suggesting. If this is not the way OpenSSH works, it?s worth documenting that somewhere prominent, so that new contributors are made aware of that. GitHub for example promotes a special file called CONTRIBUTING.md: https://github.com/blog/1184-contributing-guidelines With regards to what I expect: regardless of how I initially contacted upstream, I still think that not even getting as much as ?Oh, I can imagine we would like to eventually merge this, please give me a month to get back to you? from upstream is very discouraging. I also want to point out that I have sent my first initial request for comments on 2014-11-05, which by now is almost 4 months ago. I do understand and acknowledge that we are all busy people with little time, but from what I can tell upstream?s opinion might as well be ?this will never get in?, and then I?d just be wasting my time. I hope what I just wrote makes some sense (if not, please ask for clarifications!) and doesn?t offend any of the project members. I wrote it with the best of intentions, and I really think that the OpenSSH project should improve in such a situation as the one we?re talking about.> > > > Hence, any help on this is welcome. > > FWIW, if u2f must not be the sole authentication then that should of > course be checked by the code. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
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 approached me last year, I told you then that I wouldn't have time to properly look at it for months - I have limited time to work on OpenSSH so I have to chose my priorities carefully. A new authentication mode for a nascent hardware standard unfortunately had to take a back seat to a big refactoring that has been almost-finished for two years. When you posted your patches to bugzilla, I it took a while for you to come up with a protocol spec to review which really should have been starting point before diving in to write code. Now it's great that the protocol spec is there to look at, but it still requires more familiarity with the rest of U2F than I have at present. The code as it stands also AFAIK requires an incompatibly-licensed helper library. Neither of these problems are insumountable, but they do make it harder to start. -d
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 approached me last year, I told > you then that I wouldn't have time to properly look at it for months - >This didn?t come across well, but it could be that I just misunderstood what you were saying.> I have limited time to work on OpenSSH so I have to chose my priorities > carefully. A new authentication mode for a nascent hardware standard > unfortunately had to take a back seat to a big refactoring that has been > almost-finished for two years. >That?s definitely fair.> > When you posted your patches to bugzilla, I it took a while for you to > come up with a protocol spec to review which really should have been > starting point before diving in to write code. >Different people have different approaches :).> > Now it's great that the protocol spec is there to look at, but it still > requires more familiarity with the rest of U2F than I have at present. > The code as it stands also AFAIK requires an incompatibly-licensed > helper library. Neither of these problems are insumountable, but they do > make it harder to start.Agreed. I want to point out that you still haven?t clarified the (to me) crucial question, so let me ask you directly: Do you think, right now, based only on the information you have so far, that you?ll eventually merge a patch adding U2F to OpenSSH? It?s okay to reverse your decision later and I?m not taking this as a promise, but what I do want to know is the upstream sentimen, i.e. if you?re rather adverse to having U2F support in OpenSSH at all.