Linux Secure Shell (SSH) I : key generation, private key and public key

To connect to a remote machine, we run ssh hostname on our local machine. By default ssh assumes that we want to authenticate as the same user we use on our local machine. To override this and use a different user, we can simply use remoteusername@hostname:

$ ssh ubuntu@54.86.56.112

If it's the first time, it will ask us if we want to add the remote host to a list of known_hosts. We usually don't pay attention to this question, however, this is one of SSH's major features: host validation. We can go ahead and say yes:

k@laptop:~$ ssh k@bogotobogo.com
The authenticity of host 'bogotobogo.com (173.254.28.78)' can't be established.
RSA key fingerprint is c5:60:91:d7:fb:06:85:6b:a0:49:9d:0c:f0:fb:3c:e5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bogotobogo.com,173.254.28.78' (RSA) to the list of known hosts.
k@bogotobogo.com's password: 

The ssh is checking to make sure that we are connecting to the right host. That way if someone tries to trick us into logging into their machine instead, and sniff our SSH session. In such a case, we will have some warning.

After the yes, it will prompt us for our password on the remote system. If the username that we specified exists and we type in the remote password for it correctly then the system should let us in:

k@bogotobogo.com [~]# 

On our local machine, let's generate a key by typing ssh-keygen -t dsa:

k@laptop:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/k/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/k/.ssh/id_dsa.
Your public key has been saved in /home/k/.ssh/id_dsa.pub.
85:33:16:9d:cb:77:31:d7:35:f5:d3:3a:52:62:f3:bd k@laptop
The key's randomart image is:
+--[ DSA 1024]----+
|        .. .   .*|
|         oo   o *|
|        =...+ .=o|
|       . +o..=.o.|
|        S  ...+ .|
|             . ..|
|               E |
|                 |
|                 |
+-----------------+
k@laptop:~$ 

It prompted us for the location of the keyfile. Unless we have already created a keyfile in the default location, we usually accept the default by pressing 'enter'.

Then, it will ask us for a passphrase and ask us to confirm it. We may want to use something much longer and unique sentence which makes the passphrase harder to guess.

When we generate a key, we are actually generating two key files. One private key and one public key, which is different from the private key. The private key should always stay on our local computer and we should take care not to lose it. The public key can be put on the machines we want to connect to in a file called .ssh/authorized_keys. The public key is safe to be viewed by anybody and mathematically cannot be used to derive the private key. It's just like if I give someone a number 2,147,483,647 and asked him/her to find the numbers and operations I used to generate that number.

Whenever we connect via ssh to a host that has our public key loaded in the authorized_keys file, it uses our private key and public key to determine if we should be granted access to the host. It will ask us for our key passphrase, however, this is our local ssh process that is asking for our passphrase, not the ssh server on the remote side. It is asking to authenticate us according to data in our private key. Using key based authentication instead of system password authentication may not seem like much of a gain at first, but there are other benefits that we can see later section of this page.

We can install public key to a remote host in two ways: manual or using ssh-copy-id:

1. Manual:
   We just use scp to copy our public key which is in ~/.ssh/id_dsa.pub to the remote machine. The scp is a file transfer program that uses ssh:

   k@laptop:~$ scp ~/.ssh/id_dsa.pub k@bogotobogo.com:.ssh/authorized_keys
   k@bogotobogo.com's password: 
   id_dsa.pub                                                                                           100%  598     0.6KB/s   00:00    
   k@laptop:~$ 
   

   After authentication, it will transfer the file to our remote host.
   So, from now on, when we ssh to the remote machine, it should ask us for our key passphrase instead of our password. If it doesn't, it could be that the permissions and mode of the authorized_keys file and .ssh directory on the remote host need to be set more restrictively:

   $ chmod 700 ~/.ssh
   $ chmod 600 ~/.ssh/authorized_keys
   

   Fortunately, in our case, we do not have any permission issue:

   k@laptop:~$ ssh k@bogotobogo.com
   Enter passphrase for key '/home/k/.ssh/id_dsa': 
   k@bogotobogo.com [~]# 
   

2. Using ssh-copy-id
   

   k@laptop:~$ ssh-copy-id k@bogotobogo.com
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   Enter passphrase for key '/home/k/.ssh/id_dsa': 
   Enter passphrase for key '/home/k/.ssh/id_dsa': 
   
   /usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
   
   k@laptop:~$
   

   We got warning because it's been already installed by manually.