Thursday, April 8, 2010

SSH Hardening (Part II)

Previously we looked at ways to harden the SSH service and reviewed a number of options that can be used in the config file. Here we are going to look at public and private keys to make the SSH service more secure and possibly easier to use. With key authentication users will have a private key (on their local client machines) and a private key (on the server which they want to connect to). When the user goes to log into the server the two keys are used (with an optional passphrase) to allow the user to log in. There are a few steps involved with settings this up, and most importantly is knowing where the keys will be located:

~/.ssh/ -> is the location on the client machine where the private key is located
~/.ssh/authorized_keys -> is the location on the server where the public key is located

Lets look at the steps for setting up key authentication. Login to your client machine and execute the following:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tc_user/.ssh/id_rsa): [Press Enter]
Created directory '/home/tc_user/.ssh'.
Enter passphrase (empty for no passphrase): [Enter a STRONG password]
Enter same passphrase again:
Your identification has been saved in /home/tc_user/.ssh/id_rsa.
Your public key has been saved in /home/tc_user/.ssh/id_rsa.pub.
The key fingerprint is:
8f:a2:03:e9:5b:df:52:a4:8d:80:ad:3b:50:01:7e:23 tc_user@localhost.localdomain

Here you can see both the private and public key being generated. You should cd over into ~/.ssh and use ls -l to check and make sure that you are the only user that has read/write access to your private key.

$ cd ~/.ssh
$ ls -l
total 8
-rw------- 1 tc_user tc_user 1743 Apr  8 10:32 id_rsa
-rw-r--r-- 1 tc_user tc_user  411 Apr  8 10:32 id_rsa.pub 
 
Now that your private key is in place and secured from other users viewing it you will need to take your public key and give it to your system admin. We are going to assume that you are the admin, so you will take the public key of the user and copy the contents of it into the users account on the server under the authorized_keys file. You should also secure this file:

$ cat ./id_rsa.pub >> /home/tc_user/.ssh/authorized_keys
$ chmod 600 /home/tc_user/.ssh/authorized_keys

There is one final change that you should make on the server. In the /etc/ssh/sshd_config file change the following two options:

PasswordAuthentication no
PubKeyAuthentication yes

This will prevent users from logging on with anything but their public/private key combination. Reload the SSH server for the settings to take effect. Now you should be all set! Assuming that you are not currently logged into the server remotely, go ahead and log in. You should now be asked for a passphrase (which pertains to your password created above and not your system password).

Command line:
$ ssh -i /home/tc_user/.ssh/id_rsa tc_user@ssh_server_ip

Putty:
Under Connection -> SSH -> Auth specify the private key file and then login normally

In one more post we will look at a final program that can be used to take hardening the SSH service one step further.

2 comments:

  1. Damian,

    i recently found Your blog, google-ing for ssh hardening, and just gave this key authentication (as opposed to sign in with user password) a try.
    One thing i noticed is that i was asked only once for the passphrase, the first time connecting to my server. After that issueing the
    $ ssh -l user -p port ip
    command, i get connected without any further questions.
    I haven't tried sign-off/sign in again to see if it asks again for the passphrase, but maybe that is not even the point..

    Is this really a "more-secure" method? I mean "just in case" my user_box gets compromised, this would theoretically (?) permit access to server_box without any other authentification?

    Do i miss something?
    Can i encourage password authentication at the SAME TIME or it is an OR decision?

    Thank You for Your time.

    ReplyDelete
  2. When you use public key authentication you can set it up to only prompt for a password for your key (to decrypt it). If this is the case when you connect via SSH the first time somewhere the server will cache the fact that you entered the key password. If however you have setup the key with a password as well (done during the keygen command) then every time that you connect to a server the password should be asked. This is considered two factor because you need the key and the password in order to login.

    Make sense?

    ReplyDelete