Friday, 8 May 2015

Public Key Authentication in SSH Server

Public Key Authentication (User Authentication):

In password based authentication, you prove your identity by proving that you know the correct password. And giving the correct password to the server. If the server is 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). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who doesnot have that key. But anybody who has your public key can verify that a particular signature is genuine.

You generate a key pair on your own computer, and copy the public key to the server. Then, when the server asks you to prove your identity, you generate a signature using your private key. The server verifies that signature using your public key and allows you to log in. The private key never leaves the client machine, and therefore cannot be stolen (from the server) or guessed like a password can.

If your private key is stored unprotected on your computer, then anybody who hacks your computer will gain access to your private key. For this reason, the private key is usually encrypted when it is stored on your machine, using a passphrase. At the time of login, to generate the signature, you have to enter the passphrase to decrypt the private key. 

1) Generate key pair on your own computer
[batul@meru ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/batul/.ssh/id_rsa):
Created directory '/home/batul/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/batul/.ssh/id_rsa.
Your public key has been saved in /home/batul/.ssh/
The key fingerprint is:
The key's randomart image is:
+--[ RSA 2048]----+
|      ..o.*=o    |
|       o * +.    |
|        = B.  .  |
|         *.o o   |
|        S o.o .  |
|         .....   |
|           o     |
|            E    |
|                 |

2) Copy the key to the server to the file '/home/batul/.ssh/authorized_keys'
[batul@meru ~]$ ssh-copy-id
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is d2:1c:09:01:5b:d4:a9:e0:7b:2b:19:6a:7f:23:6d:c0.
Are you sure you want to continue connecting (yes/no)? yes
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh ''"
and check to make sure that only the key(s) you wanted were added.

3) Log in to the server
[batul@meru ~]$ ssh
Enter passphrase for key '/home/batul/.ssh/id_rsa':
Last login: Fri May  8 19:48:28 2015
[batul@oserver1 ~]$

Verifying the Host Key ( Server Authentication)

When you connect to a server for the first time, you will see a message as shown below:
[batul@meru ~]$ ssh
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is d2:1c:09:01:5b:d4:a9:e0:7b:2b:19:6a:7f:23:6d:c0.
Are you sure you want to continue connecting (yes/no)? yes

This is a feature of the SSH protocol. It is designed to protect you against spoofing attack (secretly redirecting your connection to a different computer so that you send your password to the wrong machine). Using this technique, an attacker can learn your password.

To prevent this attack, the client stores the public key of the server in the '.ssh/known_hosts' file in the user's home directory. When the client connects to the server, the server sends a signature created with it's private key to the client. The client verifies the signature with the server's public key, and then proceeds with user authentication. In case, the verification fails, you get the message as shown below:

[batul@meru ~]$ ssh
key_read: uudecode AAAAE2VjZHNhLNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBG4a7mA8YAKR7Xtv9NYxyZCU81aHvsmig9RKXgaduxlDYOuDIcwfTN4FH74u6pn5seyYY+qGhmu+B7Hq8JV89WM=
The ECDSA host key for has changed,
and the key for the corresponding IP address
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
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 ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/batul/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/batul/.ssh/known_hosts:2
ECDSA host key for has changed and you have requested strict checking.
Host key verification failed.

However, when you connect for the first time, the client has no way to know whether the host key is the right one or not. So it shows the warning as shown above (in the first example) and asks whether you want to trust this host key or not. If you select "Yes", the client saves the host key in the '.ssh/known_hosts' file and proceeds with user authentication..

You can also manually save the host key in the '.ssh/known_hosts' file.

No comments:

Post a Comment