Accessing multiple github accounts over ssh
The most convenient way to connect to github is to use a ssh key. However, this is surprisingly poorly supported. Here is a simple workaround.
Github is a great tool for managing code, storing intermediate versions and sharing it between multiple machines. It is a stalwart of modern development.
This posts deals with the issue of configuring access to multiple accounts on a single github instance, e.g. a personal and a professional account. This is surprisingly tricky to set up.
1 TLDR
Edit:
~.ssh/config:~/.ssh/config
- 1
- Using the real url as an alias for convenience.
- 2
- You can use any alias here.
When connecting to respositories with the second account, modify the remote repository url. Use the alias (here
github.perso) instead of the real url.
2 Detailed explanation
2.1 Configuring a ssh connection to github
Setting up a secured ssh connection to github is very convenient. Once it is set-up, github will register a specific ssh key to identify a specific machine. All connections from this machine will then be authorized for a number of actions on the github api.
Setting up a new key is really easy (cf. github docs). For example, to generate a ed25519 key:
ssh-keygen -t ed25519
This creates two files to store your brand new public and private keys.
To register the keys on github, navigate on your profile settings to the SSH and GPGP keys sub-page. Copy the contents of the *.pub file in the appropriate field.
If everything is set-up correctly, you should now be able to connect with ssh git@www.github.com. Test your connection with the following command:
ssh -T git@github.com
>>> Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.
You might also need to to accept the key fingerprint of github.com if this is your first connection.
2.2 This doesn’t work with two accounts
Sadly, this very convenient connection method does not work with two accounts. The first thing you might attempt is to use the same key on both accounts. This seems somewhat logical since the ssh key essentially identifies the computer. This is sadly rejected by github.com. My guess is that this must be to increase security.
It also doesn’t work to just create a second key. This is clearly part of the solution since we need to give a second key to github. However, the issue is that we need to be able to identify which key needs to be used for a specific git repository. By default, git will always use the same key for all repositories and github will only see connection attempts from a single account.
2.3 The fix
In order to fix the issue, we will use the ssh config file located at ~/.ssh/config. This file is normally used to create alias for recurrent connections so that you don’t need to repeat connection information all the time. For example, if you regularly connect to a development machine, you can create a new dev alias:
~/.ssh/config
Host dev
Ip: 127.0.0.1
User: JohnDoe
Port: 4123Now, the command ssh dev gets automatically translated to:
ssh JohnDoe@127.0.0.1:4123
Any ssh option can be configured in this file.
We can use these settings to have git use different keys for different repos. However, this requires the use of two separate alias. Each alias will correspond to a separate github account.
For example, on my machine, I have:
~/.ssh/config
- 1
- Using the real url as an alias for convenience.
- 2
- You can use any alias here.
When using my professional account, I use the standard github.com url. When using my personal account, I need to manually switch the url of the remote to use github.perso instead.
You can check that this is correctly setup by trying to connect with ssh -T to all aliases:
ssh -T git@github.com
>>> Hi USERNAME_WORK! You've successfully authenticated, but GitHub does not provide shell access.
ssh -T git@github.perso
>>> Hi USERNAME_PERSONAL! You've successfully authenticated, but GitHub does not provide shell access.
This is an annoying manipulation since it requires manually messing with the remote repository url. As far as I can tell, this is still the best workaround.