Archive for February, 2013

Establishing your SSH Server’s Key Fingerprint

February 16, 2013

When you connect to a remote host via SSH that you haven’t established a trust relationship with before,
you’re going to be told that the authenticity of the host your attempting to connect to can’t be established.

me@mybox ~ $ ssh me@
The authenticity of host ' (' can't be established.
RSA key fingerprint is 23:d9:43:34:9c:b3:23:da:94:cb:39:f8:6a:95:c6:bc.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no':

Do you type yes to continue without actually knowing that it is the host you think it is? Well, if you do, you should be more careful. The fingerprint that’s being put in front of you could be a Man In The Middle (MITM). You can query the target (from “it’s” shell of course) for the fingerprint of it’s key easily. On Debian you’ll find the keys in /etc/ssh/


ls /etc/ssh/

you should get a listing that reveals the private and public keys. Run the following command on the appropriate key to reveal it’s fingerprint. For example if SSH is using rsa:

ssh-keygen -lf

For example if SSH is using dsa:

ssh-keygen -lf

If you try the command on either the private or publick key you’ll be given the public key’s fingerprint, which is exactly what you need for verifying the authenticity from the client side.

Sometimes you may need to force the output of the fingerprint_hash algorithm as ssh-keygen may be displaying it in a different form than it’s shown when you try to SSH for the first time. The default when using ssh-keygen to show the key fingerprint is sha256, but in order to compare apples with apples you may need to specify md5 if that’s what’s being shown when you attempt to login. You would do that like the following:

ssh-keygen -lE md5 -f

Details on the man page for the options.

Do not connect remotely and then run the above command, as the machine you’re connected to is still untrusted. The command could be dishing you up any string replacement if it’s an attackers machine. You need to run the command on the physical box or get someone you trust (your network admin) to do this and hand you the fingerprint.

Now when you try to establish your SSH connection for the first time, you can check that the remote host is actually the host you think it is by comparing the output of one of the previous commands with what SSH on your client is telling you the remote hosts fingerprint is. If it’s different it’s time to start tracking down the origin of the host masquerading as the address your trying to hook up with.

Now, when you get the following message when attempting to SSH to your server, due to something or somebody changing the hosts key fingerprint:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/me/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/me/.ssh/known_hosts:6
  remove with: ssh-keygen -f "/home/me/.ssh/known_hosts" -R
RSA host key for has changed and you have requested strict checking.
Host key verification failed.

The same applies. Check that the fingerprint is indeed the intended target hosts key fingerprint. If it is, run the specified command.


Painless git diff

February 2, 2013

I’ve been using Node.js quite a bit lately and decided it was time to start using Git for my projects.

I’m used to using Mercurial (Hg) for DVCS, but have only used it on Windows and a little on Linux via command line.

I was looking for a similar experience that Windows gave me for Hg (file explorer integration with tortoisehg), but for Linux. I had created a repository using tortoisehg. When I attempted to add files to the repository using tortoisehg or straight from the command line, I was getting a few errors. tortoisehg, nautilus integration is broken on my distro at the time of writing this too. So this encouraged me to invest a little more time in Git. I had done a bit of reading and listened to a few good podcasts on Git, so I felt it was a good time.
think like a git is also good for a read.

As I was creating repositories, dealing with remote repositories, cloning, setting up all the config files, adding, committing, pulling, pushing, viewing status and diffing. What I quickly came to realise, was that the Git commands were very extensive, made more sense to me than Hg, and there is a lot of good documentation around. In saying that, it’s been a while since I used hg from the command line and most of my work has been through the GUI tools.

One area I was struggling with was the diffing of files and directories on the command line. There are a couple of good ways to make this experience a lot more pleasurable.
I like using meld on Linux for my file and directory comparisons, so already had that installed.

git diff

Create a bash file in the /bin directory.
I called it git-meld, and it looks like the following:

meld $2 $5

Turn the executable bit on, so it can be executed.

chmod git-meld +x

Now modify your ~/.gitconfig file

git config --global diff.external git-meld

To make sure your’ve added git-meld as the script that’ll run meld with the correct parameters:

cat .gitconfig

and you should see at least the following:

external = git-meld

Now that should be all you need to get git to pop meld on diff.

git diff [options] <commit> <commit> [<path_to_file_to_compare>]

If you have a stack of files (rather than just one, as shown in my above example) that were changed between these commits, diff will pop each file open in meld. One at a time until you’ve finished with each one


git difftool

git also comes with difftool. I found this really nice to use. There is no setting up for it. All you do is replace the diff command with difftool. Optionally you can specify the GUI diff tool you want to use, simply by appending -t [your_GUI_diff_tool] like this if you like using meld.

git difftool -t meld <commit> <commit> [<path_to_file_to_compare>]

If you do this without specifying the file you want to compare, you are prompted if you want to view each file, rather than how diff works by just opening every one.


If you choose to leave the -t option out, difftool will give you the option of all the possible tools able to perform the diff (some of which may need installation).

multiple diff tools

So using difftool is a better diff IMHO. This is how git difftool behaves whether or not you set up ~/.gitconfig file with your prefered diff tool.