Include libfido2

[nicoduck]

Openssh 8.2 includes the option authenticate via fido token backed ssh keys. The key itself can be stored on the phone or FIDO 2 token (older FIDO U2F tokens only support them on the phone).
OpenSSH release notes provide more information on that: https://www.openssh.com/releasenotes.html
I don't know if the mentioned libfido2 is also working on android or (because android has its own way to talk to fido tokens) a workaround with the native API is possible.

Link to home page and sources
https://github.com/Yubico/libfido2
https://www.openssh.com/releasenotes.html
https://developers.google.com/identity/fido/android/native-apps

Additional information
Have you compiled or tried to compile the package on device?
No

Trying to generate a ssh key with the needed options currently returns:
➜ ~ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Provider "" dlopen failed: dlopen failed: can't read file "/data/data/com.termux/files/usr/lib": Is a directory
Key enrollment failed: invalid format

[hashworks]

Hm, I wonder if libfido2 supports the NFC devices of Android phones (or NFC at all).

[dsseng]

Not only NFC, but also USB OTG connection should work, just as libusb patch by Termux.

[Fresheyeball]

Any progress on this?

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hashworks]

This is still relevant.

[xtkoba]

Depends on libudev.

[iprouteth0]

Depends on libudev.

What about for NFC?

[vb0]

What's the status here? I presume there isn't a complete roadblock as the issue is still open, but where it got stuck and is there anything we can do to get it unstuck?

The use case for this is very strong, ssh access is probably the thing that should be secured the most and Termux is IMHO the most trusted solution for Android, between loads of closed source clients, with ads, data collection, subscriptions, some not updated for years, some coming out of nowhere and so on. Heck, even Microsoft puts telemetry in their (open source) Windows openssh!

Allowing for FIDO2 tokens increases the security, simplifies the provisioning (like almost none at all needed on the phone like on any other client), makes it unnecessary to use unsafe ways like just having a secret key on a regular USB stick (even if it's encrypted a rogue machine can steal it, together with the passphrase if you log in there) and makes it easier to get in when there's an emergency just having the token you usually have for access (but not full Linux machine to access the token itself). Even more relevant as Android is trying to be usable as a desktop in recent versions (plus Samsung had the DeX since a while) and more and more tablets are sold with keyboards and intended as laptop replacements.

[Maxr1998]

Yubico/libfido2#571 might be relevant for this.

[jd1100]

Some additional context.

I tried compiling within termux using the steps from the repo docs but it failed on the "libcbor" dependency which I was not able to find in the termux pkg repo. This was after running the below command.

cmake -B build

[olmari]

+1 to this, nowadays there is no way in hell I use my servers SSH without FIDO2 (ed25519-sk).

[pgaskin]

Based on a quick skim through libfido2/src/hid_linux.c, libfido2/src/hid_freebsd.c, and related files, it doesn't seem like it'd be too complicated to make a PoC which uses termux-api/termux-usb to get access to the USB devices. I might attempt this at some point if I have time and nobody gets to it first. With this, the only other dependencies would be zlib, cbor, and openssl.

It seems like the only thing needed would be a custom implementation of fido_hid_manifest and fido_hid_open. Would probably also need to extend termux-api to return additional information from USB_SERVICE (product/vendor, usb hid interface fd).

For just OpenSSH, an alternative could be to write an implementation of sk-api.h using com.google.android.gms.fido.fido2. A minimal implementation would only need sk_sign. For sk_load_resident_keys, the privileged GMS Fido2 client would be required. For sk_enroll, it isn't apparent if the GMS Fido2 client provides the required functionality. I'm not sure how the PIN and key handle stuff would translate directly, so I'll probably look at the raw USB stuff first (that usb permission popup will get annoying over time, though...).

This might also be interesting: https://github.com/cotechde/hwsecurity.

And a kinda crazy idea: could maybe implement a ssh agent in a standalone app, then connect to that...

Back to the termux-api idea, it definitely would need changes on the Java side to be able to get the product/vendor ID, and to expose the HID interface indexes (and probably expose the interface claim functionality too, though that could be done directly with ioctls). Might also be nice to somehow reuse connections to termux-api, since the setup is somewhat expensive (requires a broadcast and socket setup). In the short term, for myself, I might either do the ssh agent thing, or implement something with root since I don't feel like messing with with termux-api just yet.