Geekblok

This guide is the fourth part of the ssh guides. This time I’ll dig deeper into ssh-keygen. Most people use this program only for generating DSA or RSA keys for password less logins. But ssh-keygen can do a lot more (like most unix commands).

First I will have a look at generating those RSA and DSA keys, for we need that in following guides too. I suppose most people use it even for ‘empty-passphrase-logins’. Empty passphrases are killing your security, so please fill out some passphrase when generating your keys. I willl show that you only have to type it once every X-session that you login to your computer in a later guide.

So first of all generate a key if you haven’t done that allready: ssh-keygen -t dsa. Enter through de defaults, though do type in some passphrase you’ll remember.

bq. $ ssh-keygen -t dsa -C ‘joffie@example’

Generating public/private dsa key pair.

Enter file in which to save the key (/home/joffie/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/joffie/.ssh/id_dsa.

Your public key has been saved in /home/joffie/.ssh/id_dsa.pub.

The key fingerprint is:

2e:31:ef:8d:b8:dc:fb:7c:4f:47:36:fc:87:70:bf:c4 joffie@example

Now you need to put the public key: ~/.ssh/id_dsa.pub in this case, on the server you want to login to in ~/.ssh/authorized_keys2. After which you can login to the other server, using your passphrase:

bq. ssh joffie@b10m.example.net
The authenticity of host ‘b10m.example.net’ (192.168.1.100)’ can’t be established.

DSA key fingerprint is 99:24:35:a4:f8:2c:8d:97:14:fe:6f:c5:62:4a:b6:e3.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ‘b10m.example.net,192.168.1.100′ (DSA) to the list of known hosts.

Enter passphrase for key ‘/home/joffie/.ssh/id_dsa’:

After you’ve typed your passphrase you are logged in to the server. Now lets see what happened here. There was a Warning that the key has been added to the known hosts file. This file can be found in ~/.ssh/known_hosts. In older versions of ssh the known hosts file was quite readable, but in newer versions the file has been hashed. If your know_hosts file has not been hashed yet you can ask ssh-keygen to do that for you: ssh-keygen -H,/code>.</p> <p><code>ssh-keygen can help you in identifying known hosts in the file. If you want to look for the host b10m.example.net, type ssh-keygen -F b10m.example.net and you’re shown the keys of that server.

Servers every know and then might change their keys and you’ll end up with the warning: WARNING: POSSIBLE DNS SPOOFING DETECTED! or WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!. If you are SURE that the key has changed on the server and you want to get rid of this message, you can delete the server entry from the known_hosts file. If you don’t know which line you need to delete from that file, just ask ssh-keygen:

bq. joffie@example:~$ ssh-keygen -R b10m.example.net
/home/joffie/.ssh/known_hosts updated.

Original contents retained as /home/joffie/.ssh/known_hosts.old

After which you won’t get the warnings any longer. (Though you are asked to re-add the servers key).

I might add that I am using DSA keys in this example just because I always used DSA keys. I really did not know why (think I once heard one saying that ‘it was better’). When writing this guide I searched the web for arguments on using either one of them. The arguments on this page show that it used to be a patent problem for not using RSA. But that patent has aparently expired. I a later guide I might get back on this.