git setup for multiple repos on same server
Probably a simple question, but I am at a loss here…
In github one can add a deployment key for each repository which only gives access to that single repository.
But for one client I have two projects managed with git on the same server (project A and project B). If I use the public key for project A, github tells me I cant use it as a deployment key for project B and vice versa.
How can I create another public key and setup git to use one key for project A and the other one for project B?
2 Solutions collect form web for “git setup for multiple repos on same server”
ssh way to do this would be using
~/.ssh/config, creating a hostname alias and accessing github with different hostnames for both projects. I have no idea whether there is a
git config (or
git remote) way too.
Host a.github.com HostName github.com User git IdentityFile ~/.ssh/project-a-id_rsa Host b.github.com HostName github.com User git IdentityFile ~/.ssh/project-b-id_rsa
b.github.com:user/project-b.git (or similar) as your repository URLs.
alice is a github.com user, with 2 or more private repositories
For this example we’ll work with just two repositories named
You need to be to pull from these repositories without entering a passwords probably on a server, or on multiple servers.
You want to perform
git pull origin master for example, and you want this to happen without asking for a password.
You don’t like dealing with ssh-agent, you have discovered (or you’re discovering now) about
~/.ssh/config a file that let’s your ssh client know what private key to use depending on Hostname and username, with a simple configuration entry that looks like this:
Host github.com HostName github.com User git IdentityFile /home/alice/.ssh/alice_github.id_rsa IdentitiesOnly yes
So you went ahead and created your
(alice_github.id_rsa, alice_github.id_rsa.pub) keypair, you then also went to your repository’s
.git/config file and you modified the url of your remote
origin to be something like this:
[remote "origin"] url = "ssh://firstname.lastname@example.org/alice/repo1.git"
And finally you went to the repository
Settings > Deploy keys section and added the contents of
At this point you could do your
git pull origin master without entering a password without issue.
but what about the second repository?
So your instinct will be to grab that key and add it to
repo2‘s Deploy keys, but github.com will error out and tell you that the key is already being used.
Now you go and generate another key (using
ssh-keygen -t rsa -C "email@example.com" without passwords of course), and so that this doesn’t become a mess, you will now name your keys like this:
You will now put the new public key on
repo2‘s Deploy keys configuration at github.com, but now you have an ssh problem to deal with.
How can ssh tell which key to use if the repositories are hosted on the same
.ssh/config file points to
github.com and it doesn’t know which key to use when it’s time to do the pull.
So I found a trick with github.com. You can tell your ssh client that each repository lives in a different github.com subdomain, in these cases, they will be
So first thing is editing the
.git/config files on your repo clones, so they look like this instead:
[remote "origin"] url = "ssh://firstname.lastname@example.org/alice/repo1.git"
url = “ssh://email@example.com/alice/repo2.git”
And then, on your
.ssh/config file, now you will be able to enter a configuration for each subdomain 🙂
Host repo1.github.com HostName github.com User git IdentityFile /home/alice/.ssh/repo1.alice_github.id_rsa IdentitiesOnly yes Host repo2.github.com HostName github.com User git IdentityFile /home/alice/.ssh/repo2.alice_github.id_rsa IdentitiesOnly yes
Now you are able to
git pull origin master without entering any passwords from both repositories.
If you have multiple machines, you could copy the keys to each of the machines and reuse them, but I’d advise doing the leg work to generate 1 key per machine and repo. You will have a lot more keys to handle, but you will be less vulnerable if one gets compromised.