[Feature Request] Allow use of "no-touch-required" for sk ssh keys

[bdelwood]

Per the ssh-keygen docs, sk type ssh keys have an option to disable touch presence via passing -O no-touch-required. sshd rejects such signatures by default, but this can be changed by adding no-touch-required to the authorized_keys option.

It would be nice for no-touch-required sk keys to be supported, via some interface when adding ssh keys on the webui.

[rnorth]

I was about to post similarly; I'd just like to add: in the announcement blog post there's this explanation:

you might wonder why we require verification (via the security key “tap”) when you can configure your security key to allow operations to proceed as long as the security key is present. While we understand the appeal of removing the need for the taps, we determined our current approach to require presence and intention is the best balance between usability and security.

I'd be keen to request that this be reconsidered - it would be great if no-touch-required keys could be an opt-in feature.

As-is, users roughly have a choice between hardware key always requiring taps, and an in-software (keys on disk + ssh agent). The former being very secure but inconvenient, the latter being not very secure but convenient. I would think there are plenty of people for whom a hardware key is appealing for its ability to limit compromise of private keys, who would be willing to forego the added protection that user presence detection gives.

I'd argue that lack of a middle ground option is going to pressure people towards the least secure option, so think that it would be really nice if GitHub could reconsider this approach.

[stinovlas]

I totally agree with this. no-touch-required is a must have feature. It doesn't make operations any less secure than having keys on the disk and added to ssh-agent. Tapping the security key with each fetch and push is really annoying.

[lordmortis]

mmm. It's also annoying in that the older PGP-based SSH keys work fine without presence (but you can't use the newer EC-based keys on those) - even to the point of working in clients like Fork. I can't get the newer FIDO based keys with presence working in Fork - yes this is a fork problem, but if I could use my no-touch-required key, this problem would go away...

[anttiharju]

Perhaps my google-fu was poor, but before finding this issue I gravitated towards https://bugzilla.mindrot.org/show_bug.cgi?id=3355, thinking I'm limited by some openssh bug. (Thankfully?) I was somewhat stubborn and eventually found my way here. This issue might not be getting enough attention because people give up running into the openssh bug.

best balance between usability and security.

disappointed that options are relatively insecure hardware-token-less keys or tapping constantly.

[anttiharju]

And maybe this also poses a chicken-egg problem for Yubikey adoption: using them with github is cumbersome so people can't recommend it and ultimately everyone stays less secure

[anttiharju]

Downstream issues I've found due to having a Yubikey and GitHub not supporting no-touch-required:

• GitLab depends on a open-source tool by GitHub https://gitlab.com/gitlab-org/gitlab/-/issues/367682#note_1027944383 which is explicitly not seeking contributions for new features https://github.com/github/ssh_data?tab=readme-ov-file#contributions
• brew update appears to not work when one has tapped a private repository Git operations should support private github repos with U2F SSH keys Homebrew/brew#11425. They are open to a fix but I suspect there would be similar tools in other tools that wrap git; I've already experienced it with one internal utility and had to resort to using $(gh auth token) injection for git clones.

I would love to see no-touch-required supported so Yubikey adoption would not have to experience so many rough edges. Perhaps it should be down to the individuals or orgs to mandate tap (and deal with the associated issues) rather than a central entity like GitHub.

[mrusme]

GitHub could just allow prefixing the pubkey with no-touch-required , but unfortunately their web interface as well as their API (via gh) prohibit doing so:

HTTP 422: Validation Failed (https://api.github.com/user/keys)
key is invalid. You must supply a key in OpenSSH public key format

It is sad that there's no answer to this after over two years.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[new23d]

It could be allowed, via opt-in, for SSH Authentication Keys at least. As opposed to allowing for SSH Signing Keys as well (if allowed, this should be an org-level security setting to be opted-in.)

Edit: Already works for signing since that process is entirely local.

[yakimant]

This issues is very annoying, I need to touch yubikey all the time.
It's not only when I write to the remote, but also feching.
And fetching is used in many place to check the state of local repo.

Is there any option to raise this with GitHub?
Fix should be very simple.

[yakimant]

Good news everybody!

I've got a workaround - keep ssh session:

Host github.com
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h:%p
  ControlPersist 15m

[mrusme]

Using a master connection to keep the SSH session open might help with things like go get and cargo, by not having to touch the key for every dependency that's being downloaded; It does however have security implications, especially with a timeout of 15m. For the aforementioned tools a few minutes should be more than enough.

However, this doesn't fix the issue that is the presence requirement that GitHub is imposing on security keys.

[yakimant]

Yes, forgot to mention, that keepin SSH session creates a security drawback.
(If someoe gains access to your system)
ControlPersist is the setting to tune for you usability vs security preference.

Ultimate workaround for touch requirement is not to use SK keys and switch to GPG or PIV yubikey module.

[markstos]

I gave up on this and switched to using SSH keys stored in 1Password. Github sees them as being provided by an SSH agent, so doesn't prompt every time, and 1Password allows to your require MFA to unlock the vault if you like and can you set your own policy for how frequently you need to re-enter the password. The goal if not storing the private keys directly on your laptop is met either way.

[yakimant]

Befor SK keys I was using gpg-agent with enable-ssh-support.
Another option is to use yubikey PIV module.

All compared here:
https://developers.yubico.com/PIV/Guides/Securing_SSH_with_OpenPGP_or_PIV.html

[HoodedDeath]

Just gonna add another on the pile saying I'd like to see this added. With an account that doesn't have anything particularly sensitive on it, I'd be more than happy to give up a bit of security in order to not require the user presence confirmation on my Yubikey. Could hide an opt-in option within account settings somewhere, but allowing it would be great.

[simonryf]

Another perspective/opinion: While not a problem of github - VSCode has microsoft/vscode#164402 opened for 3 years (openssh writes "Confirm user presence for key" which vscode/git misinterprets). So having to use touch is even less feasible when working with it. Yes - it's a vscode issue but that is exactly...

My point is that security needs to be practical or it is not used. And this is IMO what's happening here too. Honestly - the few people actually using FIDO keys and set it up in github (and prefixing it with 'no-touch-required') probably know what they are doing. So in essence my opinion is that it would improve rather than harm the situation if no-touch would be accepted. For the time being my Private-Key is now also NOT in HW but in my PW-Manager. Point (at least for me) proven 😛.

[jackrosenberg]

Bumping this after spending 30 mins trying to figure out why my ssh key was not working :(. It would be very nice to have this as an opt in feature, or at least display an error message as opposed to just timing out.

[AFulgens]

Forbidding no-touch-required when the standard explicitly allows it is absolutely not understandable from an end-user perspective.

I understand sunsetting old encryption/signature standards like DSA. But I cannot allow my users to use ED25519_SK keys without touch? Why?!

The same issue exists on GitLab and this unneccessary restriction is just demolishing developer experience for hardware hosted SSH keys...

[AriESQ]

I prefer keeping sk to require a tap, because it allows the server to have assurances about the client.

[n00b42]

Many users do use unsecured ssh keys stored on their devices to authenticate, no-touch keys wold be no different in terms of assurance.
Furthermore, having no-touch optional would still allow to require touch if thats what the user wants.

[AFulgens]

Nobody says that "touch-required" should not be possible. This feature request is about that it should be optional (heck, even default; but it must be optional).

[yakimant]

It's a part of openssh, so should be supported:

no-touch-required
Do not require demonstration of user presence for signatures made using this key. This option only makes sense for the FIDO authenticator algorithms ecdsa-sk and ed25519-sk.
verify-required
Require that signatures made using this key attest that they verified the user, e.g. via a PIN. This option only makes sense for the FIDO authenticator algorithms ecdsa-sk and ed25519-sk.

https://man.openbsd.org/sshd#no-touch-required

I dont think there is a restriction reasoning here, issue is just not highlighted to the Github guys.

Using touch is not only annoying for manual git operations, but mostly for automation, like running Ansible etc.