In BlogPost, Git

Why I Needed Multiple SSH Identities for Github and Bitbucket

Why would you need multiple ssh identities if you’re a Git user? The short answer is that it helped me with changing jobs. Also, I didn’t want to pay for private Git repository hosting.

git-logo_1000x418

Dealing with changing jobs

For my first couple of Rails jobs, I used my public treble37 GitHub identity to contribute to organizational repositories.

But eventually, as I changed jobs, I discovered a limitation. I started preparing for interviews and would come across GitHub repositories with titles like “Backend Interview Questions”. If I wanted to bookmark those in GitHub with the star icon, this showed up in my public activity feed.

As a result, anyone (including my boss and coworkers) could see this. In addition, I thought it would blur the line between code I wrote on my own time versus code that I wrote for work.

In fact, virtually every employment contract I’ve read says your employer owns whatever you create on company time and resources.

Consequently, if you have your own side project(s), it’s best to try and keep it separate in my opinion

Before I go further, I should tell you this article assumes you know how to set up your GitHub accounts with ssh.

GitHub starts charging for private repositories

As I learned to code over the years, GitHub started charging $7 for its private repository hosting. It used to be you received 5 private repositories for free. But then it became a 2 billion dollar unicorn.

Eventually, I found Bitbucket, a service similar to GitHub except it offers free hosting for private repositories.

That’s why I ended up needing multiple GitHub accounts – one for the company and one for my personal use.

Setting yourself up to login in with SSH with multiple accounts

Having multiple accounts started forced me to learn to perform an ssh login with multiple identities.

When I first started coding, I would have a config file that looked like the below in my ~/.ssh directory.

Honestly, it worked great for quite a while. But as I stated above, I soon needed yet another GitHub account exclusively for work.

First, I tried using HTTPS. But that became tedious quickly. Why? HTTPS forces you to enter your username and password every time.

You quickly notice using ssh to perform operations such as push and pull in your Git workflow is faster than using HTTPS.

Consequently, it’s best to set up an ssh public and private key pair for each GitHub account. But in order to do that, I had to understand the ssh identities configuration file.

Understanding the SSH Identities Configuration File

Below is a very high-level description of the fields in the configuration file I showed you above. A much more detailed description is given in the ssh_config man page here.

  • Host – bitbucket.org – This restricts you to using the host bitbucket.org. It can also be a pattern.
  • User treble37 – This specifies the user you are logging in as.
  • Hostname bitbucket.org – This specifies the actual hostname to log in to.
  • PreferredAuthentications publickey – This specifies the order of authentication methods to be tried. In our case, we want to use a public key.
  • IdentityFile ~/.ssh/my_bitbucket_key – This specifies the file from which your authentication identity is read. In our specific use case, it is the name of your public key file that you generated.

Step 1 – Configuration File Setup

Below is my current configuration file for Mac OSX. Note that I’ve changed the names of my actual public keys in the IdentityFile field.

MacOSX configuration file

A word on Linux

One thing I found on Linux was that I needed to change the Host field from github.com to my GitHub user name(s). The file and that change is shown below.

Ubuntu Linux configuration file

Now, do you notice the Host field with a value of bruce-work? That represents my workplace GitHub username. I’m not using my actual username for the sake of privacy. In the corresponding User field, you’ll notice I have git for the value.

I don’t think it actually matters what the User field is, though I haven’t actually tested it.

Step 2 – Setting the remote URLs correctly

However, what matters is setting up the remote URLs in your local Git repository correctly. This was the tricky part that I didn’t find in any of my Google searches.

Let’s say you’re on your home laptop but you need to clone one of your company’s repositories because you’re working off this laptop temporarily.

For your own personal GitHub repositories, you’ll use a Host value of github.com. For your work GitHub repository you’ll use a Host value of your-GitHub-work-username. You can use the configuration file above with the appropriate substitutions in the Host and IdentityFile fields.

For example, let’s say you clone your work repository called workrepo and your company organization’s name is WorkingForTheMan. Your work GitHub username is ilove.

You’ll cd into the directory and set the remote origin URL as follows:

Henceforth, you’ll be able to perform the usual git operations over ssh.

Step 3 – Set your work email in your Git configuration

One thing I always forget is to set the GitHub configuration in my work repositories with my work email address.

So after cloning your work repository, don’t forget to set your work email in your Git repository.

Summary

In conclusion, keeping your GitHub work and personal life is useful. If you don’t want to mix business with personal coding pleasure, set up your ssh configuration file properly using the 3 steps above.

Recommended Posts
server