> > It's done this way to allow FIDO keys to work along other key types in > the SSH protocol without requiring a whole new authentication subprotocol > just for FIDO keys, which would be needed to communicate the key handle > from the server back to the client - no such ability exists in the > existing SSH publickey authentication subprotocol. > > This was a deliberate tradeoff we made when integrating FIDO keys > into SSH: making the integration more SSH-like (dramatically lowering > the costs for other SSH server vendors to add authentication-only > FIDO support) vs making it more web-like (lowering the costs of of > implementing the client side of generating assertions). > Understood. Thanks for clarification. I just wanted to make sure we are on the same page and there is not an easier way how to do things. > > This way FIDO authenticators wouldn't even need to > > support resident credentials to function with OpenSSH. Secondly, assuming > > that there is some kind of rational reason not to place the FIDO > credential > > into `id_ed25519_sk.pub`, credential management commands should still not > > be needed. I see no justifiable reason why to load resident keys from a > > FIDO authenticator to the SSH client computer, which is what `ssh-add -K` > > does. The normal way to work with resident credentials is to specify the > RP > > ID `ssh:` in the authentication request to the authenticator. This all > > works well with CTAP 2.0. > > First, the client doesn't a priori know which RPID to use, it might be > something other than "ssh:". That's one of the reasons why we store it > in the pub/privkey file. How does a user of a RK-capable token get this > information from a token? For OpenSSH, we implemented it as `ssh-add -K` > > I have no idea whether invoking keys by RPID alone works with other > RK-supporting FIDO 2 tokens, we've always provided the key handle + RPID > and no other FIDO 2 token vendor that I'm aware of has had trouble with > this. > I will forward this to our dev team. Thanks! Anyway, it's totally up to Trezor whether they want to be compatible > with this relatively-niche feature, but I don't plan on spending any > development cycles on it for the sake of a single vendor. > 100% in agreement here. I don't want to make exceptions for any single vendor, but want to work out the solution which makes most sense for all vendors. -- Best Regards / S pozdravom, Pavol "Stick" Rusnak Co-Founder, SatoshiLabs _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
