User Authorization with public keys

In many systems you are able to login with login name and password. In general it is possible to say that most of the passwords are too simple and missing real random generated data. According to this to use password authentication is not secure enough. As well in the case that you are using one user account for more as one user it is not possible based on the password authentication to identify who has been logged on the server.

According to this SSH is supporting user authentication based on keys. In this case Client is not sending password to Server for authentication but the identity of Client as well the identity of Server is validated with using private and public keys of Client and Server.

As first you will need to make sure that your user has account on the destination server.

# useradd user                      # This will create a standard user account on Linux
# passwd user                       # Set password for the new user
Changing password for user user.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

User will use his SSH key’s for Authentication according to this destination/remote

Server need to know his public key. In general user can use more as one public key like several RSA or DSA keys. It is possible to use as well DSA and RSA key for the same server. Just at the connection user will need to choose one of the valid keys. All keys that user would like to use need to be stored at his user account at destination/remote server in “ ~/.ssh/authorized_keys “. It is possible to store one key per line.

$ cat ~/.ssh/id_dsa>> ~/.ssh/authorized_keys                                # Copy your public keys to authorized keys
$ cat ~/.ssh/id_rsa>> ~/.ssh/authorized_keys                                # Copy your public keys to authorized keys
$ ll ~/.ssh/authorized_keys                                                 # Check rights
-rw-------. 1 user user 731 Jan 18 13:35 /home/user/.ssh/authorized_keys

$ ssh-copy-id <user>@<destination_server>

Now the user has copy of his public key stored in autotomized key file of his account on destination server. According to this it shall be possible to log in to the destination server without using password only with using private key for the user.

[user@DD1 ~]$ ssh -i ~/.ssh/id_rsa user@DD2                          # Start SSH conection using -i will use your private key
Enter passphrase for key '/home/user/.ssh/id_rsa':                   # Insert your passphrasse to private key NOT THE PASSWORD
Last login: Sat Jan 18 13:38:29 2014 from DD1
[user@DD2 ~]$

Make sure that your SSH Server is configured to accept Key authentication for users. Make sure that the SSH demon has enabled this configuration (config file: /etc/ssh/sshd_config).

AuthorizedKeysFile     .ssh/authorized_keys         # Location of user key in user home dir
RSAAuthentication yes                               # Enable User Key Authentication
PubkeyAuthentication yes                            # Enable User Public key Authentication

To disable password authentication:

PermitRootLogin no                                  # Disable direct access for root account
ChallengeResponseAuthentication no                  # Disable  s/key (onetime) password Authentication
PasswordAuthentication no                           # Disable password Authentication
UsePAM no                                           # Disable external PAM Authentication

Safe updated config and restart SSH Server

# /etc/init.d/ssh reload

I have mentioned that it is much better to use user key for authentication instead of password. The reason is that it is not possible to hack the connection so easily.

Client will open TCP connection to a SSH Server. In this step Client is asking Server for authentication with his public key. This request is including part of Client’s public key. (It is not the key but only the identification of the public key of client).

In this step SSH Server has this information:
- User name
- Identification of the public key from user

According to this SSH server is checking the list of authorized keys related to user account (in “ ~/.ssh/authorized_keys “).
- In the case that SSH Server is not able to find any public key related to user account and identification. Server will deny access and drop the TCP session.
- In the case that SSH Server is able to find the public key of user:
- - SSH Server will check the authorization for the user and his key’s (if the user has some restriction for connection form some IP’s, … )

In the case that user and his key have passed point 1.) && 2.) SSH Server is going to verify Client and his key’s.
- In this step Server will generate random string (usually 256 bits).
- SSH Server is will encrypt this string with public key of user (create a “hash”).
- SSH Server will send this encrypted “hash” to Client for validating of his identity.

In this step Client has this information:
- Client know that the SSH Server is accepting his Identification of the public key.
- Client know what is the private key related to his public key accepted at SSH Server.
- Client has received encrypted “hash” from SSH server for validating of the client’s account.
- Client has information about opened TCP session to SSH Server.

Based on mentioned information Client is able to send encrypted “validation hash” to SSH Server. This will be done in this steps:
- Client need to decrypted “Hash” that he has received from SSH Server. In this step Client will extract the random string from mentioned “Hash” created in step 3.)
- Client has now random string sent at SSH Server.
- Client has as well information about TCP session to SSH Server.
- Client will take mentioned random string sent at SSH Server, then he will assign the TCP session identification to this string. As result Client will create new string that is possible to validate only on SSH Client or SSH Server site.
- Client will create a MD5 Check Sum from the new created string.

Client will replay (sent) with the MD5 Check Sum create at point 4.) to SSH Server.

In this step SSH Server has this information:
- Random created “Hash” that was used at point 3.)
- Information about TCP session between SSH Client and SSH Server
- MD5 Check Sum sent from SSH Client to SSH Server in step 4.)

According to this information SSH server is able to create same MD5 Check Sum from combination of the random “hash” and TCP session identification. In this step SSH Server will check if “MD5 Check Sum sent at Client (at point 4.) )” and “MD5 Check Sum from SSH Server” do have same value.
- In the case that this check will be OK the Authentication of SSH Client has finished.
- In the case that this check will be NOT OK SSH Server will deny access and drop the session.