{"id":21134104,"url":"https://github.com/horgix/github-deploykeys-request","last_synced_at":"2026-01-02T10:05:20.276Z","repository":{"id":95051137,"uuid":"82938809","full_name":"Horgix/github-deploykeys-request","owner":"Horgix","description":"Feature request to Github about deploy keys and private submodules","archived":false,"fork":false,"pushed_at":"2017-02-28T16:38:58.000Z","size":5,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-03-05T17:46:08.900Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Horgix.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-02-23T15:06:33.000Z","updated_at":"2017-02-28T16:44:38.000Z","dependencies_parsed_at":"2023-06-11T23:15:25.639Z","dependency_job_id":null,"html_url":"https://github.com/Horgix/github-deploykeys-request","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Horgix%2Fgithub-deploykeys-request","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Horgix%2Fgithub-deploykeys-request/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Horgix%2Fgithub-deploykeys-request/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Horgix%2Fgithub-deploykeys-request/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Horgix","download_url":"https://codeload.github.com/Horgix/github-deploykeys-request/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243581060,"owners_count":20314162,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-20T06:23:15.939Z","updated_at":"2026-01-02T10:05:15.224Z","avatar_url":"https://github.com/Horgix.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"Hello,\n\nI have some questions regarding the Deploy Keys and OAuth tokens, in the context of access management to repositories for external services.\n\n# Context\n\n- An external **service that needs to be able to clone a repository**. Example: configuration management tool (i.e. Ansible, Saltstack, Puppet, etc) that needs to `git clone` its configuration before applying it.\n- This repository is a **private** repository on Github\n- This repository has **git submodules** (also hosted on private Github repositories)\n\n# The step by step story\n\n## Read-only cloning from a service\n\nAccessing a repository content as a service be done through a *Deploy Key* added to the project. And it works perfectly fine.\n\n## The limitation of Deploy Keys\n\nAdding a *Deploy Key* to a Github project works fine. But it's **not possible to add it to another, different project**, and fails with the error: `Key is already in use` (this behavior seems intended, more on that below).\n\n## The case of private submodules\n\nWhen you have a private repository to clone and this repository has other private repositories as submodules, things start to hurt.\n\n- You expect to be able do it with the same deploy key, since it's the **same service** trying to do a clone of **related repositories** for **the same purpose**\n- ... But it's not possible to have the same deploy key\n- ... and using different deploy keys is not possible\n\n**Why is it not possible to use different deploy keys?**\n\nEvery Github repository is accessed through the same `github.com` domain so it's not possible to differenciate it in the SSH configuration; and I honnestly think it's dirty to do things like [1].\n\n## Workaround from git itself\n\nIt would be possible to use different deploy keys by changing the SSH command used by git between each submodule fetch to take a different private key with `-i identity_file`, either by using the `GIT_SSH_COMMAND` [2] or by setting the `core.sshCommand` [3] configuration.\n\nBut this is honnestly just complicated to do, let alone integrate it in existing tools that rely on being able to clone a repository and its submodules to do some automated actions.\n\n## Official solution\n\nAs stated in link [4], the problem seems to be known and **the recommended solution is to use OAuth tokens**.\n\n## On OAuth tokens\n\nSo, now that the official solution seems to be \"use oauth tokens as user to clone repositories\", let's take a look at it.\n\n1. Go to the Organization's Settings\n2. Declare an OAuth Application\n3. Get the `client_id` and `client_secret`\n4. Use this `client_id` and `client_secret` to call a PUT on the `/authorizations` endpoint to generate an oauth token\n5. Use this token to clone the repositories\n\nHowever, what is happening here is not really appropriate for services access:\n\n- To call the `/authorizations` you have to provide an **existing user's username** in addition to the `client_id` and `client_secret`\n- Thus, the OAuth token is tied to the user {him,her}self, which we don't want in the case of a service account. THe last thing we want is the token to be invalidated when the user leaves the organizations and the service to break.\n- Plus, the available scopes do not seem to be precise enough: giving access to private repositories gives access not only to the user's private repositories but also to the private repositories he can see for organizations he/she belongs to (I probably missed some rules here that allow to restrict it)\n\n# Conclusion\n\n- It's not possible to use the same Deploy Key on multiple projects\n- It's not possible or hard/ugly to use multiple Deploy Keys on a repository + its submodules\n- =\u003e Deploy Key are out\n- It's not reliable on the long term to use OAuth token since they're bound to a user and since their scope since to not be able to enforce enough limits\n\nDoes this problem seems relevant to you? If so, do you have any solution for this case of \"I want a service to access repositories with private submodules in a safe and clean way\"?\n\nSolutions I see right now are:\n\n- Allow the same Deploy Key to be used on multiple projects. I guess this will not be possible since it seems it's an intended behavior, but I'm still interested in the details of the rationale behind this decision (which is probably a good one)\n- Allow OAuth tokens to be generated without an associated user, just as a service account that can access an Organization's projects\n\nI would definitely like to avoid the \"real Github account\" with username/password, for obvious reasons.\n\nThanks for your time.\n\n- [1] https://gist.github.com/jexchan/2351996\n- [2] https://github.com/git/git/commit/3c8ede3ff312134e84d1b23a309cd7d2a7c98e9c\n- [3] https://github.com/git/git/commit/39942766ab9bc738f49f93d4c8ea68ffbaadc305\n- [4] https://github.com/blog/1270-easier-builds-and-deployments-using-git-over-https-and-oauth\n\n# Follow ups / answers\n\n## First Github reply\n\n\u003e Thanks for hanging in there! After speaking with the team about this, I'd like to share their input with you here. From your document, you said:\n\u003e \n\u003e     Allow OAuth tokens to be generated without an associated user, just as a service account that can access an Organization's projects\n\u003e     I would definitely like to avoid the \"real Github account\" with username/password, for obvious reasons.\n\u003e \n\u003e We're not 100% sure about the reasons you're referring to. Could you help us understand what those reasons are?\n\u003e \n\u003e If your server needs to access multiple repositories, you can choose to create a new GitHub account and attach an SSH key that will be used exclusively for automation. Since this GitHub account won't be used by a human, it's called a machine user. You can then add the machine user as collaborator or add the machine user to a team with access to the repositories it needs to manipulate. Our team wrote more about this here:\n\u003e \n\u003e https://developer.github.com/guides/managing-deploy-keys/#machine-users\n\u003e \n\u003e Would such an approach using machine users work for you? If not, could you tell us more about why that wouldn't work for your use case? Any information there would help. Thanks!\n\n## Reaction\n\n\u003e On Mon, Feb 27, 2017 at 5:56 PM, XYZ (GitHub Staff)\n\u003e \u003csupport@github.com\u003e wrote:\n\u003e \u003e\u003e I would definitely like to avoid the \"real Github account\" with username/password, for obvious reasons.\n\u003e\n\u003e \u003e We're not 100% sure about the reasons you're referring to. Could you help us understand what those reasons are?\n\u003e \n\u003e Sorry, I shouldn't have made the assumption that it was obvious, my bad.\n\u003e \n\u003e  I was refering to the reason for which I believe Deploy Key notion\n\u003e exist at all in Github and other software: having a \"real\" user\n\u003e account, even if it's only used by a machine, implies that the\n\u003e password for this user has to be remembered, stored (securely), and\n\u003e that if for whatever reason it is ever leaked (chances increased by\n\u003e the fact that we have to store it somewhere), it's much harder to\n\u003e renew it (considering the account has been compromised): we have to\n\u003e remove the user, create a new one, assign it to projects again,\n\u003e generate new key and assign it to the user. And the main pain in that\n\u003e is the 2 first steps : manually remove the user and create it (since\n\u003e bot account creations are forbidden according to the link you gave\n\u003e me).\n\u003e \n\u003e\u003e If your server needs to access multiple repositories, you can choose to create a new GitHub account and attach an SSH key that will be used exclusively for automation. Since this GitHub account won't be used by a human, it's called a machine user. You can then add the machine user as collaborator or add the machine user to a team with access to the repositories it needs to manipulate. Our team wrote more about this here:\n\u003e\u003e https://developer.github.com/guides/managing-deploy-keys/#machine-users\n\u003e\u003e Would such an approach using machine users work for you? If not, could you tell us more about why that wouldn't work for your use case? Any information there would help. Thanks Alexis!\n\u003e \n\u003e \n\u003e Well, that's what I itended to do if you didn't come up with another solution.\n\u003e It will do the job for sure, but I wish there was a cleaner solution\n\u003e to this, i.e. exactly what Deploy Keys are now in Github, but with the\n\u003e possibility to assign them to multiple projects.\n\u003e \n\u003e If you are promoting the so called \"machine-users\" way, may I ask then\n\u003e what would be the purpose of the Deploy Keys if they are not intended\n\u003e to avoid the downside of machine-users I mentionned ?\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhorgix%2Fgithub-deploykeys-request","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhorgix%2Fgithub-deploykeys-request","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhorgix%2Fgithub-deploykeys-request/lists"}