Ability to restrict user-level SSH key access to specific repositories/organizations

[xdavidhu]

It would be useful to have the ability to restrict the scope of a user-level SSH key (not a deploy key) to specific repositories/organizations. A question about this exact feature was asked on Stack Overflow. The access scope (which repositories/organizations can the SSH key access) could be configured at key-creation, and preferably edited afterward.

Why?
a personal example:

I'd like to securely separate my work & personal environments.
Currently, I am using a headless VM for my work-related activities. To have the ability to access the work organization's GitHub repositories (without manually adding a new deploy-key to every repo, which wouldn't be feasible), I have to create a new SSH key for my GitHub account and attach it to the VM. This SSH key gives the VM access to all of the work organization's repositories, but it also gives the VM access to my personal public & private repositories. Therefore, if the work environment is compromised, the personal repositories are compromised as well. tips tinfoil fedora.

So, currently, GitHub doesn't provide a way to limit the scope of user-level SSH keys, but having a feature like this would allow users to create better security boundaries between repositories since it's mainly encouraged to use one GitHub account for personal & work purposes, rather than creating multiple ones.

[mattmccutchen]

I have a slightly different use case for the same feature. I disagree with GitHub's recommendation and already use separate GitHub accounts for personal and work projects. But even within the personal account, I work on several different projects whose code I don't fully trust, and if a collaborator adds malicious code to one project, I don't want that code to be able to push to the other projects. So I use a separate VM for each project, but then I need a way for each VM to push code to its own GitHub repository. (This is one common case. I may apply additional restrictions in some cases, such as when testing a third-party PR that I trust less than the project.)

My current workaround is to have the host (which has my real GitHub SSH key) run a proxy that accepts SSH connections from the individual VMs (authenticated via per-VM authorized keys) and validates the target repository in the SSH command (e.g., git-receive-pack some-owner/some-repo.git) against the requesting VM before forwarding the connection to GitHub using the real key. Of course, this approach relies on having a host environment that I trust with access to all the personal projects, so that I can run the proxy there. But for any given GitHub account, any browser that is logged into the account has access to all of the account's privileges anyway, so it should be safe to run the proxy in the same local user account as that browser.

[douglascaetano]

I also miss this feature, but for the inverse case pointed by @xdavidhu. In my case, I have personal repositories that I don't care as much as the repositories of my work organization. In my personal laptop, I would like to have an SSH key that is not protected the same way I protect my work SSH key, but this is not possible because this same key would access my work repos.

[mikeweilgart]

Very surprised this doesn't exist already. Finer-grained access would seem to be a basic feature for enterprise scale, and adding a key that can only work within an organization seems like a clear win, especially since GitHub's official recommendation is to use the same GitHub account for personal and work.

I suppose the easiest "workaround" with at least a bit of security is to have a strong passphrase for the ssh key you put on your headless development VM, and then not use ssh-agent. But it's a poor compromise compared to properly separated auth.

There is a parallel in the TLS certificate world, of CAA records in DNS. Just because you trust a CA for some certs doesn't mean it should be trusted for any and all domains. Similarly, just because an SSH key is used by a particular user for access to some repos doesn't mean that user actually intends for the key to access all his repos.

[Roy-Orbison]

I think the equivalent functionality of a configurable key could be accomplished with an additional layer of deploy key management, so it doesn't necessitate a change in how key access is granted at the infrastructure level.

It couldn't be too hard to upload a public key that's not treated as a global account key, but is instead internally copied to specific repos and orgs as a deploy key, e.g. via a list:

---

Key x

Access entity	None/inherit	Read	Write
user/repo-a	⦿	◯	◯
user/repo-b	⦿	◯	◯
org-a	⦿	◯	◯
org-a/repo-c	⦿	◯	◯
org-a/repo-d	◯	⦿	◯
org-a/repo-e	◯	◯	⦿
org-b	◯	⦿	◯
org-b/repo-f	⦿	◯	◯
org-b/repo-g	⦿	◯	◯

---

Adding it to an org could recursively copy it to existing repos, and mark it for copying to future repos under the org. The same interface could allow complete revocation via recursive deletion, avoiding the need to delete it from individual repos.

Deleting/demoting a deploy key from the current interface could prompt whether to make similar changes to any other entities accessible via the same key, and whether to reduce the key owner's access as well (if not the current user).

The caveat with this approach is that the permission level of a deploy key would have to be actively limited to that of its user, so it would get deleted/demoted in the event its user has a change in access to that org/repo.

[arhuaco]

I have been using deploy keys but now I'm not sure they are helping make things more secure. Interested as well.

[toby1984]

I have a need for this as well. I have some automations running on rather exposed hosts and I only want those machines to be able to push to a specific GIT repository, not all of my repositories.

Please add this feature!

[Roy-Orbison]

@toby1984 It sounds like your use case is covered by deploy keys, as they are for single repos. You could do one key per machine, though if one were compromised, the others might also be, so you'd probably want one shared key, anyway. That way you could simultaneously revoke access for all, if necessary.

[toby1984]

Yes, sorry for the noise ... should not have stopped reading after glancing over the first sentence of the issue description ;) A deploy key is in fact the solution for my use case.

[Octobug]

People need this feature, make it happen, please. 🥹

[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. ⭐

[mattmccutchen]

A belated note that GitHub now lets you generate a "fine-grained personal access token" with access to specific repositories. Read-only or read/write access can be configured for the actual repository contents as well as for other GitHub features (issues, etc.). Thus, fine-grained personal access tokens subsume the feature requested in this thread except:

1. They only support HTTPS access, not SSH.
2. Currently, you can't use them to access repositories owned by another individual or an organization you don't belong to (Fine-grained PATs can access open source repos [GA] github/roadmap#600 and Outside Collaborator support for Fine-grained PATs [GA] github/roadmap#601; vote here).

I don't feel strongly about (1), but I won't be able to migrate from my SSH proxy to fine-grained personal access tokens unless/until (2) is solved. I guess we can keep this thread for anyone who still wants repository-level access control for SSH keys; they would probably need to make an argument for why they need to use SSH rather than HTTPS.