jump to navigation

How to Setup Public-key Authentication on a Git-client for Multiple GitHub Accounts November 25, 2012

Posted by Tournas Dimitrios in Uncategorized.

Whenever I get asked what GitHub is used for , my answer is very short .  GitHub is a code sharing and publishing service ,  a social networking site for programmers . Although both statements are true , they do not reflect the real power of GitHub’s functionality , neither shed light to the question that was raised by the questioner . Almost always , I have to complement my answer with a few more phrases  ….  At the heart of GitHub is Git , an open source project started by  Linus Torvalds (yes … the creator of the Linux kernel ) , where without his participation (and some others of course) , we would not have lived  this explosive route  of the “Open source programming world ” . Don’t get me wrong , it;s not GitHub’s participation to the aforementioned “explosion ” , but the general perception cultivated by these aforementioned personalities , they first envisioned for an open source programming tool-set for all participants . GitHub ,  like other version control systems , manages and stores revisions of projects . Although it’s mostly used for code , it could be used to manage any other type of file , such as Word documents or Final Cut projects . Think of it as an electronic filing system for every draft of a document , were you could at any time (like a time machine) , restore a previous state in just a few clicks .

Prerequisites : The reader should already be familiar with the basic concepts of Git , I wont even mention how to install / setup an Git  system . The reader should already have a GitHub account (only private  repositories are charged) , and he/she should be familiar with Git’s commands  like : init, add , commit , push and pull (the basic commands to enable and maintain a code repository on GitHub) .

A basic installation on GitHub is based on username/password  authentication . Each time a developer commits an improved version of it’s code to GitHub , he/she will be asked to type his/her credentials  . If you still use this type of authentication (username/password) ,  this article will guide you how to setup an public-key authentication account  (a basic explanation follows on the next paragraph) . We won’t stop here though , our next step will be to setup a public-key authentication mechanism for multiple accounts . Usually a developer  maintains multiple GiHub repositories (his/her own repo , and probably one or more projects of prospective customers) . It would be inefficient to type all these different usernames/passwords each time we “pushed” an new revision to GitHub .

In conventional password authentication , you prove you are who you claim to be by typing the correct credentials . If the server has been hacked , or spoofed  , an attacker can learn your password . Public key authentication solves this problem . You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody) . The private key is able to generate signatures . A signature created using your private key cannot be forged by anybody who does not have that key ,  but anybody who has your public key can verify that a particular signature is genuine . So you generate a key pair on your own computer , and you copy the public key to the server . Then , when the server asks you to prove who you are , you send a signature which was generated from your private key . The server can verify that signature (since it has your public key) and allow you to log in . Now if the server is hacked or spoofed , the attacker does not gain your private key or password , they only gain one signature . And signatures cannot be re-used , so they have gained nothing .

Although the examples in this article use MINGW32 (a Windows based Git client) , all concepts remain the same for all operating systems . Particularly , Linux users shouldn’t have any problem to adapt this guide to their operating system .

The following screenshot demonstrates the basic workflow of a GitHub project (cloning ,  editing and pushing back to GitHub ) . We were asked to type our credentials during the “push” stage .

Here comes the interesting part of the public-key authentication process :

  • Generating keys on our local machine . The generated keys will be stored into our $HOME directory into a hidden folder (dot folder) with the name of .ssh
  • Open the public-key file (which was created in previous step) and copy it’s content to your GitHub’s account administration panel . Login to GitHub -> Account-Settings -> SSH-keys -> Add-SSH-Keys .
  • Let’s clone a repository and configure git to use public-key authentication . Notice : we use https to clone the repository , then we add a new origin address , it will use the git protocol (ssh) . No password asked
  • Another example : Cloning a repository using the git protocol . Notice : this time we don’t have to change the origin address . No password asked .

If you are using a single GitHub account , then your journey is finished here  . Readers that have multiple GitHub accounts and want to setup public-key authentication for multiple accounts should continue reading this article .
The concept is as follows , until now , our key-pair is stored into $HOME/.ssh  directory .  As we will have multiple ssh key-pairs , we have to create multiple sub-irectories into $HOME/.ssh . Each sub-directory should contain the key-pairs for a specific GitHub account . Into $HOME/.ssh we will create a file with the name of config which will list the position of each key-pair (in which sub-directory it is located ) . Here follows an example of my config file

#Default GitHub account
Host github.com
	HostName github.com
	User git
	IdentityFile  ~/.ssh/personal-keysn/id_rsa
Host bobsponge.com
	HostName github.com
	User git
	IdentityFile  ~/.ssh/bobsponge/id_rsa
Host goofy.com
	HostName github.com
	User git
	IdentityFile  ~/.ssh/goofy/id_rsa

Hope the structure of config is self-explanatory ,  Host defines a custom designation (it will be used later to configure Git ) and IdentityFile defines the position of the key-pair (which folder these keys are located) .  Create a sub-folder into  $HOME/.ssh  move your existing key-pair into this sub-directory (the name of the sub-directories is up to you  ) . Re-create new keys (as described in step-2 of this article) and move those keys in a separate sub-directory . I have created three sub-directories for my three GitHub accounts , the final directory structure is as follows (I know ,  those are funny names ) :

Of course , the content of each public key should be copied to the relevant GitHub account (as demonstrated on step-3 of this article) . The following trick can be used to verify that everything is setup correctly :

Notice the -i  command-line option , it defines the position (folder) of each key-pair . GitHub respond with a “successfully authenticated ” message . Let’s demonstrate how to connect to one of our GitHub accounts . While on a single public-key authentication mechanism the URL would be git@github.com:GitAcount/repositoryName.git  , a multiple public-key authentication is as follows :  git@bobsponge.com:GitAccount/repositoryName.git   (git@github.com is replaced by git@bobsponge.com) . Of course , bobsponge reflects the name of the sub-directory which contains the relevant key-pairs . The Git-client will match the configuration directives defined into $HOME/.ssh/conf  file with a sub-directory and it will load the relevant private key . With the private key loaded , it will produce a signature , which will be used to authenticate to GitHub’s server .


1. Michael - December 3, 2012

loved it.

2. Carol - December 3, 2012

i would like to stay informed of your new posts. thanks a lot.

3. Celia - December 4, 2012

it was a great experience to read such kind of great work i really enjoyed while reading this article.

4. DCC - December 10, 2012

thank you a lot

5. mercado - December 12, 2012

maybe you should improve your articles, that would help us understand better.

6. KitDeed - December 14, 2012

hi, good post. i want to thank you for this informative read, i really appreciate sharing your post. keep up your work…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s