How to Add Deploy Key for 2 Repo with 1 User on Github

how to add deploy key for 2 repo with 1 user on github

You can create two public/private keys with whatever name you want:

~/.ssh
  repo1
  repo1.pub
  repo2
  repo2.pub

  config

(Ie it doesn't have to be named id_rsa(.pub) to work, provided you indicate ssh where to look.

That is where 'config' comes into play: the config file includes the name of your two connections for GitHub repo1 and GitHub repo2 with, for each connection, the path to your private repo key, as described in "change github account mac command line" and in "Quick Tip: How to Work with GitHub and Multiple Accounts":

Host githubRepo1
HostName github.com
User git
IdentityFile ~/.ssh/repo1

Host githubRepo2
HostName github.com
User git
IdentityFile ~/.ssh/repo2

That way you can pull from any of the two repos, as long as you are using their ssh addresses.

Using the same deploy key for multiple github projects

The only reason, illustrated by the workaround you reference (creating a single "build" user, or sharing the same id_rsa.REPONAME.pub per repo) is:

avoid sharing public/private key for different user

Even though that wouldn't be the case in your situation (build multiple project), allowing to reuse the same ssh key would open the possibility for two different users to share the same ssh key, which would defeat the authentication purpose.

Authentication means:

"using a certain ssh key should imply that you are supposed to know who is using it".

However, as noted in jtlindsey's answer, this is less related to authentication/identity/good policy, and more related to a "role" you attach to those keys. (role to deploy a certain repository).

As noted in "Why can't I use one ssh key on more than one github repo?" by tkeeler:

This workflow becomes a problem when using automated systems and git submodules.

You can't use the same deploy key in more than one repo, so the workaround becomes adding that key to their user account (or a dedicated machine account).

Taking the least path of resistance, most users will add it to their own account resulting in a greater security risk.

GitHub should rather let the user choose and assume the risk on a per repository basi

---

The GitHub page "Managing deploy keys" details the various accounts using ssh:

• SSH agent forwarding: Agent forwarding uses the SSH keys already set up on your local development machine when you SSH in to your server and run git commands.
  
  You can selectively let remote servers access your local ssh-agent as if it was running on the server.
  
  So no need to replicate your private key on the server.

• Machine users: (this is the "dummy account" strategy) Attach the key to a user account. Since this account won't be used by a human, it's called a machine user.
  
  You would treat this user the same way you would a human though, attach the key to the machine user account as if it were a normal account.
  
  Grant the account collaborator or team access to the repos it needs access to.
  
  So one private key associated to one "machine user", one per server.

(DHa points out in the comments to a deploy key limit number, and the fact you can have only one machine user account)

• Deploy key (one per GitHub repo) SSH key that is stored on the server and grants access to a single repo on GitHub.
  
  This key is attached directly to the repo instead of to a user account.
  
  Instead of going to your account settings, go to the target repo's admin page.
  
  Go to "Deploy Keys" and click "Add deploy key". Paste the public key in and submit.

This time, the ssh key isn't attached to a user (for which you could grant access to several repo), but to one repo.

Granting the ssh access for several repo would be the equivalent of a "machine user".

In term of authentication:

• using the same key for several repos is okay when it is done by a user (which has said key associated to his/her account)
• using the same key for several repo is NOT okay when the key is attached by a repo, because you don't know at all who accessed what.
  
  That differs from the "machine user" where a "user" is declared as a collaborator for many repo.
  
  Here (Deploy key), there is no "collaborator", just a direct ssh access granted to the repo.

---

Yusuf Bhabhrawala further illustrates this model limitation in the comments:

Consider these very plausible use cases - a python project using a private pip module or a node project using a private npm package - both from another repo in same organization.

Currently there is no way to deploy this very simple use case either using a deploy key or an account key (which exposes too many other repos).

And Chris Stenkamp points out to "How to discover where 'pip install git+ssh://...' is searching for ssh keys?", which involves setting the GIT_SSH_COMMAND environment variable.

GitHub - Using multiple deploy keys on a single server

What i though was an issue with authentication what actually an issue with the git service not knowing which ssh key to use as i had multiple on the server.

The solution was to use a config file in the .ssh folder and assign alias to specify which ssh key to use for git operations in separate repositories.

Solution is here: Gist with solution

This gist explains the general idea, it suggests using sub-domains however a comment further down uses alias which seems neater.

I have now resolved the issue and the system is working fine with a read-only, passphrase-less deploy key.

Why can't I use one ssh key on more than one github repo?

That's not quite the right characterization of what it says on the GitHub page you linked. In fact, you can use the same ssh key for many different GitHub repositories. What you can't do is use one ssh key for many repositories and as what they call a "deploy key", nor use the same ssh key as some other user.

What's going on here is that GitHub's ssh server classifies incoming keys into one of two types:

• An account key, which authenticates an incoming connection as you. You then have permissions on some wide (or narrow) swath of repositories, as controlled by each repository's "accounts that have access" settings. That is, the key itself is how they know you are kramer65 (or whatever your account name actually is there).
• A deploy key, which authenticates an incoming connection as having access to one particular repository. That is, there's no "account" involved: it's just one key, attached to one specific repository.

There are also "machine users", but those are a form of account; I'm not sure whether GitHub even distinguishes those internally from regular account-keys. Because these are account-like rather than deploy-key-like, you can give them access to many different repositories. (This is probably what you want.)

I really wonder though; why is this a problem? Why can't one server have access to several repo's? What's the risk they're trying mitigate here?

They are not really protecting anything here. They are just letting you save, on GitHub, this one extra key, and for (your) convenience, do it without bothering to create an account. For (their) convenience, they then attach this one extra key to exactly one repository, which lets their ssh server—or really, what's right behind it after the key authenticates, i.e., the "login shell"—look up the one allowed repository without having to indirect through an "account" table first. When the incoming key is an account (or machine user) key, their ssh server, or what's right behind it, must look in this secondary table, to find the set of allowed repositories.

See https://developer.github.com/guides/managing-deploy-keys/#deploy-keys for details.

(There is no theoretical reason they could not allow a deploy key to automatically create an otherwise-anonymous "machine user" that is then automatically added to each repository, or removed from it, as you would like. However, that buys them nothing, since machine users already exist, and perform this same function. They can try to spin it as a security feature because it lets you know "hey, that key already means something to me" ... but if you have that key and aren't supposed to have that key, you can now find out what that one key actually unlocks, which if anything is somewhat anti-security. On the other hand, if you are supposed to have that key, and have simply forgotten which of your repositories it unlocks, that makes the system very difficult for you. This is typical of any security system though: the more secure you make it, the more inconvenient it is to actually use.)

---

Related Topics