Add support for a single deploy-key to use it with multiple repositories

[lynxis]

Select Topic Area

Product Feedback

Body

Since github introduced the deploy keys years ago it was never possible to use the same deploy-key for multiple repositories.
Add this feature is implemented by all other github competitor for many years.
Please add support for this.

Why is this a problem?

You want to give an external CI or deployment access to your project repository via a deploy-key.
If you have a project which lives in a single repository, it's working. But if your project consist of multiple repositories, your CI and deployment need to access multiple repositories. Or your project depends on multiple private repositories you can't use deploy-keys anymore.

What is a deploy key?

A deploy key is a ssh-key used for deployment and CIs. Usually deploy-keys have only access to a subset of repositories and
can only read those.
The deploy-key isn't bound to a user account.

deploy-keys

• access level based on repository
• can be read-only
• independent to an account

personal access token

• bound to an account
• have access to all private repositories of the user
• can be read-only (per repository/project)

ssh key of a user account

• bound to an account
• have access to all private repositories of the user
• can be read-only (per repository/project)

So everything except a deploy-key have much more access than a fine grated deploy key and give a read permission to everything in the repository. Also you wouldn't create multiple bot-accounts only to have fine-grate permissions as those bot-accounts also need a seat, email account, registration.

So many other competitors are supporting multiple repositories for a single deploy-key.
Please add this long out-standing feature.

[az-catch]

Wow this is pretty bad, just ran into this and it's a massive problem resulting in a number of stupid work arounds like having to create a fake user account and add ssh keys to it...

[elliott-bfs]

I'd like to know the reasoning behind why it's more secure to have a unique key for each account. If the computer hosting the keys is compromised, all the keys will be compromised anyways!

[HarryVasanth]

This has been a thorn in our flesh for a while now. We have a few repositories that has to be deployed in a single server, and we are currently managing it by generating individual keys for each repository to be able to pull their respective codebase. I still can't figure out a legit reason for not being able to reuse the same deploy key for multiple repository but allows the same keys to be used for a bot account to perform the same functions as a work-around. Which defeats any purpose and actually makes it vulnerable if the bot-account is compromised.

[Martin-Widmer]

Ran into exactly the same problem. Fine-Grained access tokens can in a limited way alleviate this problem, but become extremely useless because of their limited timespan. I just want to give read access to a couple of private repositories for a server that is not connected to my personal account. This shouldn't be this hard.

[ebndev]

Hey @lynxis,

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. Other users may engage with your post, sharing their own perspectives or experiences. GitHub staff may reach out for further clarification or insight. 

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(GitHub Public 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. ⭐

[hsein-bitar]

We also need this.

[KieranP]

Same issue here. We have a main git repo, and it contains a submodule. I went to add the deploy key from the main repo to the submodule repo (since they will be deployed together) but it won't let me. Why must I create a different SSH key for the submodule I'm trying to clone when the same ssh key for the main repo should suffice. This is cumbersome and annoying.

[R1ckyH]

We Need IT!

[lev-slinsen]

Upvote! I've had to deal with this on multiple projects that consist of 2-3 repos (services). Every time I have to google a workaround, every time it is pain.

[tsahlin]

We need this

[viktaur]

Any updates on this?

[YevKix]

We need this!

[bgardner-noggin]

This seems hopelessly broken as it stands.

Personal access tokens (classic) - have too broad an access, you cannot create a read only token
Personal access tokens (fine grained) - no way to grant access to a private repo in your organisation, that does not belong to the user that generated the token

Also, personal access tokens expire, and are tied to specific user accounts - what happens when that user leaves the organisation and their account is no longer valid?

Github has no support for PHP packages. So a composer.json file needs to be re written, only during the github action mind you otherwise it breaks developers local workflow, to add a key per target repository. Worse if your composer.json is being used inside a docker build, to be secure it really should be using docker secrets which requires a --mount=type=secret,id=/path/to/secret again per repository. This also breaks local developer workflows

As far as I'm aware, recursive git submodules have no available workaround. eg the git checkout action

      - name: Checkout code
        uses: actions/checkout@v5
        with:
          submodules: 'recursive'
          ssh-key: ${{ secrets.ssh_key }}

cannot work as you cannot rewrite the first set of retrieved repositories own's .gitmodules file.

[devopsmitch]

Another +1 for this issue please.