Two local Git accounts, using SSH - Account A can commit to Account B's private repos

Question

So, I have two Git accounts, (call them A and B) and they each have their own private repos. Lets call them A1 and B1 for each git users private repo.

I set up SSH for both accounts on my PC and added them to my git client, Git-fork.

I cloned the repos, then set up the user specifically for each repo, versus a global user.

I accidentally set Account A as the user for Account Bs repo - I thought it wouldn't let me commit, but it worked fine.

How do I prevent this in the future, so only the owner of the private repo can push to their repo?

I made sure the generated SSH key was paired to each github account correctly - it must be a setting on my desktop, but not sure what?

See the attached image enter image description here which shows both accounts committing to OWlB's private repo.

Is there an easy safety feature to stop this? I think it happens as the git gui client doesn't differentiate the SSH keys between the users obscured email I use for the commits - could it be a mistake in the SSH generation?

This is using Git-fork on Windows. I've set up aliases for the remotes to match the users SSH keys, but the url cannot be cloned via Git-Fork with the alias in place. Unsure if this will solve the issue of commiting to specific branches or not.

Answer 1

There are two separate forms of identification here that need to be considered: the identity in the commits, and the credentials used to push.

Every time you make a commit, a personal name (not username) and email are recorded into the commit, usually based on the Git configuration values user.name (the personal name) and user.email (the email). In fact, two are recorded: one for the author (the person who created the change) and one for the committer (the person who made the commit). Once a commit has been made, this data is embedded, and the only way to change it is by replacing the commit with a new one.

When you push commits with SSH to GitHub, your authorization is based on your SSH public key. The key that you're using is associated with a user account or a repository, and in the latter case, we call it a deploy key. The user account or repository and the permissions associated with the key determine what repositories can be accessed.

However, when you push commits, you can push commits for any user. This is by design, since projects like Git accept patches from many authors which are all committed by a single person, the maintainer. It would be very difficult to adopt this workflow if you couldn't push others' commits, and it would also be impossible to push a new copy of an existing repository.

In your case, you've committed to the same repository with two different identities, and so both of those are in the history. You then pushed that history with the owner's key, and thus those commits were uploaded.

There is no option in GitHub's configuration to disable the ability to push arbitrary commits to the repository, because it's not generally useful. GitHub does allow users to prohibit forgeries by requiring commits to be signed, but that doesn't help in your case because you'd have the credentials for both users. It's also the case that GitHub doesn't permit multiple free accounts and typically corporate contributors require employees to use a company machine (thus avoiding this problem), so this is not a scenario that tends to be well supported.

You could use a pre-push hook that runs through the history and rejects commits for the wrong user. This can be done by replacing the check for WIP commits in the default pre-push hook (.git/hooks/pre-push.sample) by a check against the appropriate range with git log --format='%ae %ce'. That would print the author and committer emails and you could then reject the commit if it had values you didn't like. This could still be silently bypassed with --no-verify, however.