Having Trouble Switching Github accounts on terminal

Question

It's been a while since I pushed anything to GitHub. I had initially set up my account on my computer, and everything worked great. Then I changed my account to a client's account (so I could push code to their private repository).

It's been a while and now I am changing back to my old account, and I am having trouble. I generated a new rsa_key and pretty much followed the instructions here to a T.

However, when I type: ssh -T [email protected] I get:

Hi oldincorrectusername! You've successfully authenticated, but GitHub does not provide shell access.

I can't push to my repos either, because this old client username isn't authorized. I've doublechecked my ssh keys both on my computer and on my account setting on GitHub.

I've also set my global account variables:

git config --global user.name "Firstname Lastname" git config --global user.email "[email protected]" git config --global github.user username git config --global github.token 0123456789yourf0123456789token 

And still it is giving me the old username.

Any suggestions?

Thanks,

Answer 1

The problem is that your local ssh is still offering your “old” SSH key to GitHub. This often comes up when you have one GitHub-recognized key (i.e. your “old” key) loaded in an ssh-agent but want to use a different GitHub-recognized key (i.e. your “new” key).

ssh offers keys in this order:

1. specified keys that have been loaded into the agent
2. other keys that have been loaded into the agent
3. specified keys that have not been loaded into the agent

By “specified keys” I mean those keys specified by the -i command line option or the IdentityFile configuration option (which can be given through ~/.ssh/config or the -o command line option).

If your “old” key is loaded into the agent, but your “new” key is not, then ssh will always offer your “old” key (from the first or second categories) before your “new” key (only ever in the last category since it is not loaded), even when you specify your “new” key with -i/IdentitiesOnly.

---

You can check which keys are loaded in your ssh-agent with ssh-add -l. If your “old” key is listed, then you can fix the problem by unloading it from your agent (be sure to also unload any other GitHub-recognized keys, except perhaps your “new” key):

ssh-add -d ~/.ssh/old_key_file 

If you are using Mac OS X, the system may be automatically loading your “old” key if you checked “Remember password in my keychain” when prompted for the password at one point; you can disable this automatic loading by deleting the Keychain entry for the key with the command
/usr/bin/ssh-add -K -d ~/.ssh/old_key_file. Other systems may do something similar, but the commands to tell them to “stop that” will be different.

---

Instead of unloading the “old” key from your agent, you can set the IdentitiesOnly configuration option to yes, to tell ssh to skip the second category of keys (non-specified agent-loaded keys). Your ~/.ssh/config might include a section like this:

Host github.com     User           git     IdentityFile   ~/.ssh/id_rsa # wherever your "new" key lives     IdentitiesOnly yes 

This way, it will not matter whether any other GitHub-recognized keys are loaded into your agent; ssh will always offer only your “new” key.

If you anticipate needing to access the repositories of both GitHub accounts and you do not want to have to edit the configuration file whenever you want to switch between GitHub accounts, then you might setup your ~/.ssh/config like this:

Host clientname.github.com     HostName      github.com     IdentityFile ~/.ssh/client_id_rsa  # or wherever your "old" client key lives  Host github.com     IdentityFile   ~/.ssh/id_rsa        # or wherever your "new" key lives  Host github.com *.github.com     User           git     Hostname       github.com     IdentitiesOnly yes 

Then use URLs like github.com:GitHubAccount/repository for your repositories and URLs like clientname.github.com:GitHubAccount/repository for your client’s repositories (you can put the git@ prefix back in if you like, but it is not necessary since the above entries set the User configuration variable).