Suggestion on easy support for FIDO key types for SSH tunneling.

[Mr Testman]

Every SSH server now supports FIDO hardware based keys, but not a single VNC client can use these when tunneling over SSH.

I understand having to prompt the user to press the Yubikey at the appropriate moment would be very difficult if not impossible to code.  The press request comes from within the libssh library and modifying it and continuing to keep it updated with such a change would be a Herculean task. 

However I have a suggestion that might make support for FIDO based keys easier to support.  

Ssh-keygen allows a "notouch" option where the user does NOT need to press the Yubikey.  For some this may be considered less secure, but a notouch key is still hardware based and when a yubikey is in my pocket that key can not be used. 

Now the support for FIDO based keys is already in libssh, this is really more of a compile issue, if you can do some extra checks to confirm the notouch option was used in the key creation then there is no need to prompt the user and these keys have the same user experience as a software based private key with no password.  

I don’t have Android,  but have Mac and iOS, I am familiar with testdrive and have different FIDO devices that I can test with.  If you need a tester please contact me. Without the need to prompt the user the library support may already be there. 

[i iordanov]

Hey,

I am not familiar with FIDO keys, but both 2FA and FIDO keys seem to be supported by libssh2 (the project uses libssh2 library and not libssh).

I could look into support for standard two factor authentication. The server asks for an additional code after successful authentication, at which point, one can enter a 6-digit code from a hardware or software device or touch a Yubi key.

I am not yet sure what it takes to support FIDO devices.

Could you please make a feature request through the report bug functionality in the app to add support for 2FA authentication for MacOS/iOS? If you think I should look at FIDO devices as well, please make a separate ticket for them.

Thanks!

Iordan

The conscious mind has only one thread of execution.

--
You received this message because you are subscribed to the Google Groups "bVNC, aRDP, aSPICE, Opaque Remote Desktop Clients" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bvnc-ardp-aspice-opaque-remot...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bvnc-ardp-aspice-opaque-remote-desktop-clients/de24200f-1b85-4a13-ab3b-2a8d99b19911n%40googlegroups.com.

[Mr Testman]

So this is a 2fa situation.  These are new types of edecsa and ed25519 keys that are keygened on the FIDO devices and can never be exported.  The private key file generated doesn’t contain the actual private key, but instead is a pointer to the proper Fido device. You manage the key as any other key (private key (pointer) file in .ssh, pub key in servers authorized_key file). There are also some new options at keygen for Fido keys and one of these is "notouch" which I think solves a significant coding problem.  I really think this is an easy compile and support is already there. 

[i iordanov]

If the libssh2 library declares support for these keys, have you tried generating one and pasting its (private pointer) in the app where it accepts ssh private key?

Iordan

The conscious mind has only one thread of execution.

To view this discussion visit https://groups.google.com/d/msgid/bvnc-ardp-aspice-opaque-remote-desktop-clients/9fd3fe68-a1d3-4e38-b424-528b057bf937n%40googlegroups.com.