Canot push to remote repo - "Please make sure you have the correct access rights and the repository exists."

Question

I'm constantly facing authentication issues as a consequence of moving between pushing to my private projects and my work ones. Each time I move from a work context to a personal one, I spend some time dealing with my ssh keys and configuration. I often go through the github documentation around generating and adding ssh public keys to the site.

Today, I'm getting:

ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I tried generating a new ssh key pair and submitting the public key to github but github says "key already in use". I googled that for a bit but could not fully make sense of that error message.

Switching gears I noticed that when running the command ssh -T [email protected], the output greets me as the Github user associated with my personal account username and not my work one.

My understanding of ssh was that it was in some sense "accountless". No username or password is part of the ssh connection process. So now that I believe the authentication issue revolves around some system believing I'm logged in as my private github account's username, what can I do?

Answer 1

How GitHub knows who you are

My understanding of ssh was that it was in some sense "accountless". No username or password is part of the ssh connection process. So now that I believe the authentication issue revolves around some system believing I'm logged in as my private github account's username

You are correct: the problem is GitHub makes an assumption about your GitHub username, but it's not always correct for your current need.

All SSH connections have a username. In the case of GitHub, it is always "git". That's the "git@" part of your GitHub URL, e.g.

[email protected]:username/projectname.git

As far as SSH is concerned, the username is always "git".

But GitHub (the application running on the server) has another layer. It looks at the SSH key you used to authenticate, and looks up which GitHub user has that key associated with their account. That is how it maps your SSH connection to a GitHub username.

The problem

You have multiple accounts on GitHub. So you need a way to control which one you are using. But SSH will, by default, always use the same key for "github.com".

The solution

(The below assumes macOS or Linux - how to do this in Windows is different, but the same concept applies.)

You can control which key is used by mapping different virtual hostnames.

Let's say you have two keys,

• ~/.ssh/id_github_work
• ~/.ssh/id_github_personal

You can set up profiles like this in ~/.ssh/config:

Host github.com-work
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_github_work

Host github.com-personal
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_github_personal

Now you can control, using the hostname, which key is used. You can clone like this:

git clone github.com-personal:yourusername/projectname

It will use your personal key. To use the other key, just use the other hostname.

Why this works

SSH will see the hostname in your URL, e.g.

github.com-personal

Before doing anything else, it looks in its own configuration to see if there are any parameters associated with that hostname. Since this hostname matches an entry we added to ~/.ssh/config, it loads those parameters.

One of those parameters, Hostname, tells SSH that the hostname we gave it is not the real hostname of the service. SSH (and therefore Git) will still connect to the hostname "github.com", but it will use the SSH key (and username) specified by this SSH profile.

Fixing existing repos

If you already have a repo, you don't need to re-clone it. You can just change the URL.

git remote set-url origin github.com-personal:yourusername/projectname

git-passport

You can also try git-passport as was suggested by RichouHunter in the comments. I have no experience with that tool so I can't vouch for it, but it appears to try to address the same problem.