Thanks a lot for your feedback, and sorry for the late reply (been quite busy). I’ll update this thread once I’ve got a new version of the patch to share :). On Tue, Dec 2, 2014 at 2:01 AM, Ángel González <keisial@xxxxxxxxx> wrote: > Michael Stapelberg wrote: > >> Thank you very much for any replies :). >> I haven’t seen any replies yet, and it’s been almost a week. It could >> just be that none of you care, or all who care are incredibly busy. >> Still, I’d appreciate a “don’t know about the details, but we’ll most >> likely merge your patch” so that I know any further work on this is >> not in vain :). >> >> Thank you! >> > Now it has been almost a month. :) > > In case it is helpful, here are my 2 cents: > 1) It looks cool to support U2F in openssh. > 2-3) No, sshd writing the users authorized_keys file doesn't seem a good > idea :) > I would put the client registration process in ssh-copy-id > > 4) For the server to identify itself, the only think it knows about its > identity is its own [set of] host key. The hostname or gethostid(2) can be > quite useless. Perhaps a sshd_config param? :/ > > 5) Looks good. From the client point of view, I would use hostname[:port], > as currently checked by ssh in known_hosts. That seems more consistent with > ssh way. I also suspect that using the server fingerprint would allow some > attacks, in addition of avoiding possible issues with multiple hosts with > the same key (shared fs, cloned machines…). Note that if the server is > exposed to the origin value, it may deserve to be hidden (hashed?) first > (I understand the server shall treat the origin as an opaque value) > > 7) Wouldn't ERR_load_crypto_strings() be enough? > No, it’s unfortunately not enough. > > +// TODO: use auth_info() so that in log messages about accepted auths we >> will see a message that identifies the key. perhaps we can just use the >> human readable suffix that you can specify in the authorized_keys file(s)? >> > Just that suffix won't help root to figure things out. A fingerprint -like > it's now provided for public keys- could help here. > > > And a few u2f questions: What is the purpose of the challenge provided by > the server on I think throughout the protocol (not only when registering), the challenges are used to ensure nobody is capturing and replaying these messages, as they get hashed by the security key (and that signed hash is verified by the server). > registration? What is a u2f key expected to do if asked to register an > system it already has already registered? Should it be appended or replaced? > I think it gets replaced, but I don’t recall the spec being explicit about that. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
