The Git way – II

This is part 2 of the git basics or the git way which should help us in the very least to make a repo. and start contributing.

The first thing to do is to download and install git and openssh-client. As I’m on Debian, I would be using aptitude (similar to apt-get) which should be available on all Debian derivatives, while rpm based would need to use yum or whatever command-line tool they are happy with.

$ sudo aptitude install git openssh-client

Once the installation is complete you should run

$ git --version
git version 2.1.0

and then

$ ssh -V
OpenSSH_6.6.1p1 Debian-7, OpenSSL 1.0.1i 6 Aug 2014

You should get some similar output. It doesn’t have to be this exact version. The only thing to note is that your OpenSSL version should be equal to or greater than 1.0.1g otherwise you are vulnerable to the OpenSSL heart-bleed bug.

Going further, the first thing you will have to do is sign up to some git hosting site. For the series, I would be using as the service is free and the code on which gitorious sits is also open (unlike Github), the commands and services of both are very much alike except for Github’s UI which is more user-friendly for a newbie. Underneath though, they are very much similar. That is a story for another day altogether.

The first thing you would need to do is after having some Username and Password is to generate your ssh public and private keys. Something like this :-

$ ssh-keygen -b 4096 -t rsa -C "shirish@debian"
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/id_rsa4096_2013.
Your public key has been saved in .ssh/
The key fingerprint is:
5d:ab:44:4a:8a:ac:5f:1c:81:c8:79:3a:9d:88:df:81 shirish@debian

ssh-keygen is a utility to generate ssh keys. While I do not want to go too deep into ssh keys, the best analogy to give is like the safe deposit vault in the bank. When you go to open the safe deposit vault, you use your key and your banker uses another key to open the vault. That verifies to the banker that you are who you say you are (with having the right key and the correct locker number).

SSH keys do something similar. They generate two keys, a public key which you can share with everyone and a private key which you should be keeping hidden from everybody else. The public and private key helps establish your identity to a third-party with a certain level of trust which is not possible over plain-text conversations unless you actually meet the individual.

So when you are generating SSH keys, you may be asked to do some things which may seem silly but in the background all it’s trying to while generating the ssh key is to have as much ‘entropy’ as possible. Entropy is a fancy word for randomization so it tries to have as many random alphanumeric numbers which become the face of your public and private keys. Internally, it’s a mathematical algorithm which establishes relationship between the two keys.

Notes :-

A. Make sure you have a strong pass-phrase. The strength of any cryptography is only as strong as its weakest link. If you use dictionary-words or something which can be spelled, it can be easily broken. So the idea is to have as long as a pass-phrase which is nonsensical and yet can be saved. Something like apg (Automatic Password Generator) which I have shared few weeks ago could be helpful.

B. There are countless ways to more secure your SSH keys. An article as well as using the terms ‘Hardening SSH keys’ should give you more than ample tips, ideas, suggestions to do better. This is though for the more paranoid in us, for people just getting used to or new to SSH world the above would be good enough. As you become more familiar you may find your own ways as well.

Now once the keys have been generated, as can be seen the default place where the keys are placed are in ~/.ssh so let’s see what is in .ssh hidden directory.

$ cd .ssh
~/.ssh$ ls

As can be seen there are two files, the id_rsa is the private key while is the public key. The first thing to do is upload the public key to your profile. For instance my public key I uploaded at .

As can be seen the public key contains the following :-

the protocol, the alphanumeric key and the email/something@some domain

Once the keys are successfully uploaded, you can check the finger-print that it shows there with the ones you have.

$ ssh-keygen -lf ~/.ssh/
4096 5d:ab:44:4a:8a:ac:5f:1c:81:c8:79:3a:9d:88:df:81 shirish@debian (RSA)

Once that is established, the next thing is to validate/authenticate yourself to

$ ssh -T
The authenticity of host ' (' can't be established.
RSA key fingerprint is 7e:af:8d:ec:f0:39:5e:ba:52:16:ce:19:fa:d4:b8:7d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ',' (RSA) to the
list of known hosts.
Enter passphrase for key '/home/shirish/.ssh/id_rsa':
Welcome, shirishag75. Use git to push/pull your repositories

The moment you got the welcome message with the username you have been authenticated. I’m sure you noticed that it asked for my passphrase and once I entered it, it authenticated.

Let’s check the .ssh directory again to see if anything has changed in the mean-time.

~/.ssh$ ls
id_rsa known_hosts

As can be seen there is a new file called ‘known_hosts’ which came as we authenticated . The contents of the known_hosts is sensitive hence not sharing.

Once this process is done, it’s time now to do some sort of configuration to git to suit our purposes.

Enter git config , the syntax is very simple .

$git config --some variable

I will share some of the simple ones to start of and give a sort of snapshot of things you can have in your git configuration.

$git config --global "Shirish Agarwal"
$git config --global

All of these values get written to /etc/gitconfig ( in case of multiple users on one machine) or ~/.gitconfig which is there in every user’s home directory.

Here are some of the things I have put up in my config file.

$ cat ~/.gitconfig
name = Shirish Agarwal
email =
editor = leafpad
excludesfiles = /home/shirish/.gitignore
gitproxy = \"ssh\" for
tool = meld
default = simple
ui = true
status = auto
branch = auto

I am not going to go through each of the options I used except for perhaps .gitignore.

.gitignore is a file where you tell git not to track some files based on some attributes or some properties. The .gitignore file is a simple text file which just lists one after another what sort of files you should not track. Here is a simplistic example of a .gitignore file.

$ cat .gitignore

Again, these are just things which I don’t want to track, you are free to add or subtract whatever sort of files you don’t want to be tracked by git.

While you can do this later as well, but as has been often said, ‘well begun is half-done’ I usually like to do the boring part (configuration first) so that I don’t have to go back and do things. One thing to note though, that both the .gitignore and the config file listing is far from exhaustive. I encourage you to per-use your favorite search-engine to find more information and examples of the same which would help you to make your .gitignore as well as your config more robust and to your liking.

We can finally start with starting our first git repository in the next blog post.

Till l8er.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.