MAINFRAME > Administrator > Security

Implementing Cryptographic Keys

Protect your Linux server from root password-guessing attacks.

Protect your Linux server from root password-guessing attacks.

Take one look at /var/log/secure on an Internet-connected server and you’ll immediately understand the need for securing your root account. The bad guys are constantly attempting root and other user names to attempt to login to your server using SSH or some other protocol. If you use a simple password, it’s only a matter of time before a password-guessing attack compromises your server. What can you do?

You can use cryptographic keys for the SSH root login. You’ll need PuTTY, PuTTYGen, a local computer running Windows and a remote computer running Linux or UNIX. In this example, the remote files are:


The best practice is to disallow SSH logins by root, thus eliminating a big part of the risk. The problem is that doing so also eliminates a lot of convenience for system administrators and complicates the use of tools such as WinSCP for file copy from your Windows desktop or laptop to your Linux or UNIX server.

A fairly simple solution is to use public/private key pairs for authentication. The public key is stored on the Linux/UNIX server and the private key is stored on your local Windows computer. When you attempt to connect to the Linux/UNIX server from your Windows computer, authentication is done with the key pair instead of a password. Password authentication is actually disabled for root, so no amount of password guessing will work for authentication. Here’s how to do it:

  • Start by downloading the PuTTY Windows installer from Run the installer on your local Windows computer.
  • Now, you must generate the key pairs. The PuTTY Windows installer you just ran installs an application called PuTTYgen that you can use to generate the keypairs. The installer probably placed PuTTYgen (and the other PuTTY applications) in Start>All Programs>PuTTY.
  • When you run PuTTYgen for the first time, you must generate a new key pair. At the bottom of the PuTTYgen window are three parameter choices including SSH-1 (RSA), SSH-2 RSA and SSH-2 DSA. SSH-2 RSA is the default choice with a default key length of 1024 bits. Longer key lengths are more secure, but require more processing power. 1024 bits is an acceptable compromise at this time, but may not be acceptable in the future as computer processing power continues to increase.
  • Click the Generate button to produce your public and private keys. (You must move your mouse pointer over the blank area at the top of the screen to generate some randomness for use in producing the key pair. Just move your mouse pointer in a circular motion over the blank area until the progress bar reaches the far right side and PuTTYgen generates the keys.)
  • You can now save the private key on your local laptop or desktop computer and copy the public key to the remote Linux/UNIX server.
  • Enter and confirm a pass phrase to protect the private key in the two fields in PuTTYgen.
  • Click Save Private Key button and select a location on your local hard drive. (Remember to protect your private key by storing it securely!) I also like to save my public key as a text file to simplify using it in the future.
  • Copy the gibberish text that is the public key (at the top of the PuTTYgen window) and paste it into /root/.ssh/authorized_keys on your server (You might have to create the .ssh directory and you’ll probably have to create the authorized_keys file. Note: the .ssh directory is a hidden directory whose name starts with a period.). If you saved your public key as a text file in the previous step, you can simply copy the contents of that file to /root/.ssh/authorized_keys.
  • On your Linux/UNIX server, inspect /etc/ssh/sshd_config to ensure that RSA authentication and public key authentication are both allowed by modifying three lines in the sshd_config. Depending on your system, you’ll have to change "no" to "yes" or uncomment the lines to allow the authentication. Also, ensure the path to the authorized_keys file is set to "%h/.ssh/authorized_keys" and uncomment the line. (I found the three lines at approximately line 43 on a RedHat system and approximately line 29 on a Debian system.) When you’re done, the lines should look like this:
    RSAAuthentication yes
    PubkeyAuthentication yes
    AuthorizedKeysFile %h/.ssh/authorized_keys
  • In order for the changes to be read into RAM, you must restart SSHD.
  • If you attempt to log on now with the username root and the root password, the logon attempt will be denied.
  • You must now configure PuTTY to use the public/private key pair for authentication. Open PuTTY, in the left-hand menu area expand SSH and select “Auth.” On the right-hand side of the window, browse to the location where you stored your private key or simply enter it in the field below “Private key file for authentication:” Again, in the left-hand menu, select “Session” (at the top of the list). On the right-hand side of the screen, enter the IP address or host name of your Linux server and click the Open button.
  • When PuTTY connects to the server, enter “root” for the username. You’ll be prompted for the pass phrase you configured for your private key. Enter the correct passphrase and you should be logged on to your server as root.

The benefit of performing the preceding steps is: It’s nearly impossible for an attacker to guess your password and log on to your server as root. In order for the attacker to masquerade as root, she or he would have to have your private key and know the passphrase associated with it.

Don R. Crawley is author of “The Accidental Administrator: Linux Server Step-by-Step Configuration Guide” and president of a Seattle-based IT training firm. Don can be reached at (206) 988-5858 or

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


Implementing Cryptographic Keys

Protect your Linux server from root password-guessing attacks.

Network Security

The zEnterprise System changes firewall requirements.

Data Lockdown

Use DB2 and z/OS to prevent security breaches.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters