Support for `no-touch-required` Option with FIDO2 Resident Keys

[Akorian]

I'm referencing this GitLab issue, where it's noted that GitLab doesn't support ed25519-sk keys with the no-touch-required option, partly due to this library's lack of support:

We use github/ssh_data for handling and validating SSH keys. It doesn't support the no-touch-required option.

I believe adding support for the no-touch-required extension in ssh_data would be highly beneficial. Here are some reasons:

1. Enhanced Security with Convenience: Utilizing resident keys on YubiKeys via FIDO2, even with no-touch-required, offers better security than alternatives like generating a key on bare metal and importing it into the PIV slot of a YubiKey.
2. Improved Usability Across Multiple Servers: Users often need to connect to multiple servers simultaneously. Without no-touch-required, they do resort to less secure methods. Supporting this option would allow them to maintain higher security standards without sacrificing convenience.
3. Much easier setup for Hardware security tokens. Current implementations / ways to setup especially for use with SSH are not as straight forward as a FIDO2 resident key.

[vcsjones]

It doesn't support the no-touch-required option.

It does, unless I am misunderstanding some specific need. The FIDO2 specification calls this "user presence".

For example, when using SSHData::PublicKey::SKED25519, you can use

require "ssh_data"
require "ed25519"

key = SSHData::PublicKey::parse_openssh("sk-ssh-ed25519@openssh.com someEd25519SkKey")
key.verify("data", "sig", user_presence_required: false)

This open is also available for SK-ECDSA, as well as the SSHData::Signature for commit signing.

What we don't support is parsing it as authorized_keys style. For example, this does not work:

key = SSHData::PublicKey::parse_openssh("no-touch-required sk-ssh-ed25519@openssh.com someEd25519SkKey")

Which is perhaps why it is believed the gem does not support it. However it isn't an immediate priority for us to support this syntax, and it can be worked around by doing a little pre-processing of the key.

[Akorian]

Hi, thanks for the clarification!

I'm not a developer myself, so I can only speak from a user and system administration perspective. From that angle, users and admins are generally most familiar with the authorized_keys file syntax—specifically adding no-touch-required as a prefix to their public key.

If I understand correctly, the underlying functionality is indeed supported by the library, just not through that particular syntax in authorized_keys. That makes sense now.

I imagine projects like GitLab could potentially implement a checkbox or similar setting in the UI to handle this logic using your suggested method. I’ll try to convey that to the GitLab developers—thank you again for the quick and helpful response!

That said, I do think it would be a valuable enhancement to support the authorized_keys style prefix directly in ssh_data. Doing so would reduce the burden on downstream developers, and offer a more centralized and familiar way to configure presence requirements across tools and interfaces.

Thanks again!