CODEWITHSUNDEEP
gitgithubsshbitbucket
Numerials
Numerials

Reputation: 47

SSH single repo different remotes different git hosts different users/emails/passwords

I have a single repository. I have two remotes named: Origin and Remote Origin points to github, Remote points to bitbucket. My github account login uses my personal email ******@gmail.com, my bitbucket account uses my work email account *******@ca****et.com.

Both Atlassian and github have my ssh keys, my ssh keys are linked and working, they're in different files id_rsa, id_rso.

I want to be able to git push remote master:development and separately, not at the same time (don't want sync) git push origin master:master etc.

How do I create a git config that allows different user/email for the ssh login?

My git config:

[user]
  1 »»»»»»»»email = [email protected]
  2 »»»»»»»»name = Serafin Wesnidge
  3 [core]
  4 »»»»»»»»editor = vim
  5 »»»»»»»»pager = diff-so-fancy | less --tabs=4 -RFX
  6 »»»»»»»»excludesfile = /home/user386/.gitignore_global
  7 [push]
  8 »»»»»»»»default = simple

(Sorry for formatting, don't know how to get VIM to yank into my ubuntu os buffer. That's a question for another time)

Thanks for the help!

For the Stack Overflow "Duplicate question" police, see below the list of articles I read and the explanation of why they don't apply to my question.

Stack overflow wont let me post my proof so here's an image of it.

enter image description here

Upvotes: 0

Views: 68

Answers (1)

torek
torek

Reputation: 488193

First, arrange for your ssh command to send your "GitHub identity" (really: key) to GitHub, and your "Bitbucket identity" to Bitbucket. That means your ssh configuration1 (not Git configuration!) would include:

Host github.com
        IdentityFile ~/.ssh/id_rso
        IdentitiesOnly yes

(the last line is not required, but is a good idea) and:

Host bitbucket.org
        IdentityFile ~/.ssh/id_rsa
        IdentitiesOnly yes

(assuming I have the ID files correct here). Then use ssh://[email protected]/path/to/repo.git and ssh://[email protected]/path/to/repo.git as the URLs for your two remotes (you can use the git@$hostingsite:path syntax if you prefer, this makes no difference, I just like the ssh:// syntax myself). The separate remotes will remain separate, and you will only fetch from, or push to, each one as you tell Git to fetch from, or push to, each one.

Technical notes

Technically, neither GitHub nor Bitbucket use your email account. Well, they both use it—but to send you email, not to identify some incoming data stream as "you". They also use it to identify commits "made by you" for display purposes; but such commits can be injected by someone else.

In particular, whenever you use SSH to connect to either Bitbucket or GitHub, you run the non-interactive equivalent of:

ssh -T git@$hostingsite

where $hostingsite is either bitbucket.org or github.com. This means you are asking those systems to log in as the user named git, not as yourself! So how do they know that you are you?

The rest of this discussion is really about how Gitolite works

The description below assumes a linear scan through the entire authorized_keys file, which is probably far too slow for busy Bitbucket and GitHub servers. The principles should be the same, though. The Gitolite system literally works this way, so as to work on unmodified Unix / Linux servers.

The user git, on these systems, is not allowed to do very much. However, that particular user has a very long authorized_keys file that has, instead of the usual ssh-rsa AAAA... lines, lines that start out with:2

restrict,command="<path>/gl-auth-command <user>" ssh-rsa AAAA...

When the sshd server on the machine accepts an incoming key and matches it to the public key stored in user git's authorized_keys file, this restricted-and-special-command line makes it run something other than a general-purpose shell. In this particular example we provide both a path to the Gitolite authorization step, and the name of the user ssh has just authorized based on this key.

The request that your Git sent, to run git upload-pack or similar, is preserved in an environment variable ($ORIGINAL_SSH_COMMAND). Hence, the actual command just run knows whose key it was that let you in, along with what Git operation you asked to do (if you asked to do one—if not, you get that "successfully authorized, but" message that $hostingsite prints).

There is additional discussion in Running a “secure” git server over SSH without gitosis/gitolite? and in this superuser.com Q&A.

1The ssh configuration file is typically named $HOME/.ssh/config.

2I use restrict here rather than laboriously enumerating all the ssh capabilities to disable. I think some older sshd versions do not support restrict, hence the longer versions in the linked questions.

Upvotes: 2

Related Questions