Skip to content

Instantly share code, notes, and snippets.

Last active December 12, 2020 23:18
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?
Use multiple SSH keys for multiple GitHub accounts without modifying ~/.ssh/config

Using multiple SSH Keys for multiple GitHub accounts

If you are using separate GitHub accounts to help manage different silos of work (personal, work, etc), you can use a combination of directory structure and .gitconfig files to manage your commit authorship details and SSH keys.

Ensure that you have already created/added SSH keys to ssh-agent and have added them to your corresponding GitHub accounts.

Other guides on this problem encourage modifying your ~/.ssh/config file to use a different SSH key depending on a prefix on the hostname for each GitHub account you need to manage.

For example (~/.ssh/config):

# Account A
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_A

# Account B
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_B

# Account *
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa

This works, but has the potential to become brittle and hard to maintain over time. To clone a repository using credentials for account A, you need to remember to append "A" to the hostname in the clone command:

git clone

Otherwise, the clone will attempt to authenticate using "Account *"'s SSH key, which is probably not what you want. You also need to consider how to manage your global ~/.gitconfig to correspond to the git user you want to author commits as. If you don't remember to modify your ~/.gitconfig to update your email and username to line up with what you want, then your commit's authorship may be incorrect.

A more robust pattern utilizes some recent features for git's ~/.gitconfig file, which incorporates directory structure to clearly reflect your configuration intentions. This makes this style of configuration easier to maintain over time and extend.

For example:


In each directory, make an individual .gitconfig file to manage the local git configuration.

$ touch ~/DEV/A/.gitconfig-A
$ touch ~/DEV/B/.gitconfig-B

Modify each individual .gitconfig file to reflect the intended git user you want to author commits as, in addition to the correct SSH key to authenticate with when interacting with the remote git server.

For example, for ~/DEV/A/.gitconfig-A:

	name = A
	email =
	sshCommand = ssh -i ~/.ssh/id_rsa_A -F /dev/null

And for ~/DEV/B/.gitconfig-B:

	name = B
	email =
	sshCommand = ssh -i ~/.ssh/id_rsa_B -F /dev/null

The key configuration here is the sshCommand value. This is how we augment git's clone/fetch/push SSH logic to use this SSH key.

Then, setup your ~/.gitconfig file to delegate the authentication and git user config to the specific directories.

[includeIf "gitdir:~/DEV/A/"]
        path = ~/DEV/A/.gitconfig-A
[includeIf "gitdir:~/DEV/B/"]
        path = ~/DEV/B/.gitconfig-B

At this level, the key configuration is the combination of includeIf and gitdir.

Now, whenever I am working in a git repository that is under ~/DEV/A/, I will be using ~/DEV/A/.gitconfig-A. Because I will be using that specific .gitconfig-A file as my git config, I will be authoring commits as the expected user and any remote git workflow will authenticate using the corresponding SSH key. You can now also leave your ~/.ssh/config alone, no matter how many accounts and keys you need to manage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment