Friday, February 26, 2010

OpenSSH daemon hardening ( Part 2 ) - How to use RSA/DSA Keys

[Note: This is a draft version of the post; it'll be revised as soon as possible]

Introduction


In my previous post, I explained you how to configure OpenSSH for improving its security. By the way, if your SSH service is available on the Internet and accessible by any IP address (e.g. You connect your client on the internet with a dynamic IP address and/or you want reach your server from anywhere...), it can be more exposed to brute force attacks! So a new "hardening procedure" is necessary! 

In this case, a good idea is the use of RSA/DSA Keys, instead of a couple of  "username/password".

RSA/DSA Keys may be considered a sort of "long and complex" password, which replace the classical "login", and identify in unique manner the owner of the credential.

I talk about DSA/RSA because the setup procedure is the same, but  you have the oppurtunity to choose two different types of key generation algorithm with OpenSSH:

RSA ( http://en.wikipedia.org/wiki/Rsa )

DSA ( http://en.wikipedia.org/wiki/Digital_Signature_Algorithm )



How does the RSA/DSA keys authentication method works?


RSA/DSA Keys authentication scheme follows this logic:

1) The sysadmin (You...) generates a pair of RSA/DSA Keys on his system (one is the "private key" and the other one is the "public key")
2) After that, his public RSA/DSA key will be published (copied) to the home directory of the remote server account that will be used for RSA/DSA authentication (The system admin will repeats this step for each server he wants to manage/access)
3) Only the owner of a private key (the sysadmin) can have access to systems containing his public rsa/dsa key
4) If the sysadmin connects to a server specifying on his pc client the rsa keys path, he will have "direct" access to the called system without inserting any password. Indeed his openssh client will search the private key of the sysadmin and uses it for accessing the remote server in the same manner of the classical login... But in the case... the machines handshake (client with server) will be done automatically by using keys.

Why this method is better than username/password login?

The answer is simple...

1) No brute force attacks with dictionary can be done (no passwords...)
2) The RSA/DSA keys are complex by themselves, no needs to create/remember/store complex password
3) The Private and Public key can be carried on a pendrive (protect them by encryptation and passphrase!!!)
4) It is possible to automatize exchange of data between servers via SSH (by using two couples of RSA/DSA Keys) without "human" intervention

The negative aspect...

One and only one... If you loose your private key you are fired!!! (Back up them on CDROM)
In this case... The only way to access to the system is by doing a login using the physical keyboard of the real system... Than you can change the rsa public key...


Let's Start!


In real world... Follow these steps:

1) Go into your client GNU/Linux console and login with the user you usually use. On the command prompt write:

ssh-keygen -t dsa


Note: If a passphrase is required, if you press enter you don't need to insert an "unlock" password before have access to your keys. If you choose to use passphrase you must write that every time you need to connect with RSA authentication method to a remote system. (Replace "dsa" word with "rsa" if you want to use RSA algorithm.)

Anyway, if you have installed your GNU/Linux system on a PenDrive, for security reason it is important to insert the passphrase.




2) A pair of dsa_keys will be generated. One public and one private. It will be called id_dsa.pub and id_dsa rispectively and you will find them into the .ssh hidden directory (inside your home directory...)

3) Now it's time to copy your public key to the home directory of the user you have access on the remote server. Use the scp command to do that.

scp /home/youruser/.ssh/id_dsa.pub yourremoteuser@server:/home/yourremoteuser

For example:


scp /home/angel/.ssh/id_dsa.pub admin@testserver.net:/home/admin

4) Now you must connect to your remote server (with your account on that machine) and add the RSA/DSA key to authorized_keys2 file  (a sort of rsa/dsa keys wallet)

For example:

ssh admin@testserver.net
(insert the password)


when you're logged in write:

cat /home/admin/id_dsa.pub >>/home/admin/.ssh/authorized_keys2

and then

chmod 700 .ssh
chmod 600 .ssh/authorized_keys2

(Replace "admin" with your user on remote server...)

5) Logout from the server

6) If you have followed correctly the instructions above you can connect to your server without insert any  password (only a passphrase if you've inserted one during key creation).

On the command line of the client write:

ssh -i /home/yourusername/.ssh/id_dsa username@yourserver.com

Note: add the option "-p port" if the remove server ssh daemon answer to a port different from 22

For example (for the user "admin") you could use:

ssh -p1138 -i /home/angel/.ssh/id_dsa admin@testserver.net

It'll connect the user "angel" to the remote system "testserver.net" with user "admin" by using dsa authentication. The server also uses the port 1138 for the SSH service, so we have got specified the "-p" option.


Another step for improving hardening...

If your remote system is configured for using both authentication method (user/password and rsa keys...), you can force the openssh daemon to accept only rsa authentication.

To do that, change the PasswordAuthentication parameter to no into the /etc/sshd_config file!



One more suggestion!

If you are interested in IT Security, join us at "GNU/Linux Security & Hardening" group on Linkedin



That's all! See you! (If you like my posts, I'll be pleased if you became a follower of my blog and my Twitter!)

Have a nice day!
Angelo Fonzeca

Creative Commons License
Digital Patch Posts by Angelo F. are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Based on a work at digitalpatch.blogspot.com.

No comments:

Post a Comment