I updated to the latest versions of libfido2 and openssh-portable tonight, with an intention to test out the security key functionality and look closely at the changes over the last couple of months to see if I need to change anything in my AsyncSSH implementation to stay in sync. However, it seems that libfido2 no longer provides the ?libsk-libfido2.so? library that it used to. That was something I was counting on being able to link against in AsyncSSH, so I didn?t have to directly call into libfido2 and could instead use the much simpler sk_enroll/sk_sign API that libsk provided. After looking around a bit, I saw a comment in the libfido2 repo about the libsk functionality moving into OpenSSH itself, but I don?t see any way to build that as a library any more. In fact, the only implementation I can find now is the one in sk-usbhid.c which seems to be used when ??with-security-key-builtin? is set in configure. Is there any way that this support can still be built as a library? -- Ron Frederick ronf at timeheart.net
On Wed, 5 Feb 2020, Ron Frederick wrote:> I updated to the latest versions of libfido2 and openssh-portable > tonight, with an intention to test out the security key functionality > and look closely at the changes over the last couple of months to > see if I need to change anything in my AsyncSSH implementation to > stay in sync. However, it seems that libfido2 no longer provides the > ?libsk-libfido2.so? library that it used to. That was something I was > counting on being able to link against in AsyncSSH, so I didn?t have > to directly call into libfido2 and could instead use the much simpler > sk_enroll/sk_sign API that libsk provided. > > After looking around a bit, I saw a comment in the libfido2 repo > about the libsk functionality moving into OpenSSH itself, but I don?t > see any way to build that as a library any more. In fact, the only > implementation I can find now is the one in sk-usbhid.c which seems > to be used when ??with-security-key-builtin? is set in configure. Is > there any way that this support can still be built as a library?The middleware does include source-level support for building as a standalone .so, but we don't have any support for that in the build system. If you want to use the middleware in another product though, I think your best bet will be to fork it and occasionally sync with OpenSSH as I think it fairly likely ssh<->middleware API will change further over time. Such changes will be completely invisible to our users, as anyone who wants to use the default middleware will just build against libfido2, but you would be much more exposed e.g. if we made an API change that broke your use of the .so. -d
On Feb 5, 2020, at 11:54 PM, Damien Miller <djm at mindrot.org> wrote:> On Wed, 5 Feb 2020, Ron Frederick wrote: >> I updated to the latest versions of libfido2 and openssh-portable tonight, with an intention to test out the security key functionality and look closely at the changes over the last couple of months to see if I need to change anything in my AsyncSSH implementation to stay in sync. However, it seems that libfido2 no longer provides the ?libsk-libfido2.so? library that it used to. That was something I was counting on being able to link against in AsyncSSH, so I didn?t have to directly call into libfido2 and could instead use the much simpler sk_enroll/sk_sign API that libsk provided. >> >> After looking around a bit, I saw a comment in the libfido2 repo about the libsk functionality moving into OpenSSH itself, but I don?t see any way to build that as a library any more. In fact, the only implementation I can find now is the one in sk-usbhid.c which seems to be used when ??with-security-key-builtin? is set in configure. Is there any way that this support can still be built as a library? > > The middleware does include source-level support for building as a standalone .so, but we don't have any support for that in the build system. > > If you want to use the middleware in another product though, I think your best bet will be to fork it and occasionally sync with OpenSSH as I think it fairly likely ssh<->middleware API will change further over time. Such changes will be completely invisible to our users, as anyone who wants to use the default middleware will just build against libfido2, but you would be much more exposed e.g. if we made an API change that broke your use of the .so.Thanks, Damien. In the end, I decided to re-implement what I had written to use the ?python-fido2? module from Yubico instead of either libsk or libfido2. I wasn?t able to use their high-level API (which was designed to be used for WebAuthn), but ?python-fido2" also provides lower-level CTAP1 and CTAP2 APIs which worked reasonably well for this. Using ?python-fido2", I also implemented resident key support and some other functionality not present in my first cut, and the result is now available in the AsyncSSH 2.2.0 release. More details of the capabilities can be found at https://asyncssh.readthedocs.io/en/latest/changes.html <https://asyncssh.readthedocs.io/en/latest/changes.html>. Thanks very much for all your work on OpenSSH and for answering the questions I had! -- Ron Frederick ronf at timeheart.net