How to Setup Public-key Authentication on a Git-client for Multiple GitHub Accounts November 25, 2012Posted 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 .
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 email@example.com:GitAcount/repositoryName.git , a multiple public-key authentication is as follows : firstname.lastname@example.org:GitAccount/repositoryName.git (email@example.com is replaced by firstname.lastname@example.org) . 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 .