33801 Curtis Blvd. Suite 112Eastlake, Ohio 44095
+1 800 618 4427

Using RSA Key Pairs for Fast SSH Connections

Written by: Francis Martin

I manage a large number of Debian Linux servers in our Data Center located on-site  at MarinerTek,  just east of Cleveland, Ohio and several Cloud based Debian boxes.  Jumping from one server to another via SSH can be a tedious process if you have to manually log in each and every time.  There is a better and faster way to move from box to box via OpenSSH.

Using RSA key pairs in combination with ".bashrc" aliases, allows the user to log into servers without entering username & password credentials every time.  Be careful though, this process does create two security risks which I will explain later.

RSA key pairs and how they are used in SSH:

RSA is a cryptographic methodology conceived in 1978 by Ron Rivest, Adi Shamir and Leonard Adleman for the purpose of encrypting data transmitted electronically.  This is one of two data encryption standards supported by OpenSSH (DSA being the other).   The RSA data encryption process relies on the use of two "keys", one public and one private.  Both keys are required to encrypt and decrypt the data contents of an electronic transmission.

Anyone who uses SSH is familiar with the handshake which occurs when you establish a connection to a server  for the first time; "The authenticity of host......can't be established......continue connecting (yes/no)".  When you enter "yes" and proceed to log in, the server you are attempting to access passes a copy of it's "public" RSA key to your system, which is subsequently recorded in your "$HOME/.ssh/known_hosts"  file.  From that moment on all data transmissions for the session you've just established, are encrypted and controlled by the "public/private" key relationship of the two endpoints (you and your destination).

Flipping the Script:

OpenSSH has built in a facility to allow access without passwords for users with predefined RSA key pairs. Whereas in a classic SSH session, the public key is passed from the destination point back to the user attempting to gain access; in a no-password session, an RSA key pair is created by the user wishing to gain access and the public key of that pair is stored in a special file ($HOME/.ssh/authorized_keys) on the destination system.

How it's done:

Here is where we put all this information to practical use.

1. Use the "openssh-keygen" program provided with OpenSSH to generate an RSA Key Pair. The  "-t rsa" in the example indicates that the key pair type should be RSA rather than DSA.

ssh-keygen -t rsa

2. You will be prompted for the name of a file in which to store the key pair and for a passphrase.  Simply hit "enter" for each of these questions. You will now have two new files in "$HOME/.ssh" (id_rsa & id_rsa.pub).

3. Log into the system where you wish to establish no-password access. Upon login you will need to create a "$HOME/.ssh" directory, assuming it doesn't already exist. Once created the permissions must be set to "0700".

mkdir .ssh

chmod 0700 .ssh

4. Exit the remote server. Upon returning to the system from which you intend to access the remote servers via no-password protocols, you must transmit the "public" key which was generated in step #1 to the directory on the destination server which you created in step #2. In this process you will rename the file to "authorized_keys". The OpenSSH Daemon only grants no-password access to authorized public keys stored in any given user's "$HOME/.ssh/authorized_keys" file and only if the "authorized keys" file and "$HOME/.ssh" directory has the correct permissions set, per step #2. In this example SCP is utilized to effect both the transfer of the "id_rsa.pub" file and the renaming process at the destination.

scp .ssh/id_rsa.pub username@servername:.ssh/authorized_keys

5. Test the new no-password access. You should now be able to gain access to the destination instantly upon hitting "enter".

ssh username@servername.domain

Making access even faster:

Assuming everything went as  planned with the establishment of no-password SSH access, there is one more step necessary to speed up the process of logging on via SSH. Using your favorite text editor, add the login command string as an "alias" in your ".bashrc" file.

alias server1='ssh username@server1.domain"

Now, simply typing "server1" an hitting "enter" will instantly grant you access to the destination server.

Security Concerns:

While you have gained much greater efficiency through this process you must keep in mind the following two security concerns to ensure this shortcut doesn't wind up cutting your throat.

1. This new no-password method of logging in works perfectly, every time, for any person who has access to your system. It is critical that you exercise adequate security on your local device to ensure no unauthorized access is gained to sensitive devices through your local system.

2. Ease of use opens the door for catastrophic consequences due to human error. While moving quickly from machine to machine it is often easy to forget exactly which machine you are currently logged into.  The conventional process of manually logging in brings with it the unintended benefit of making the user stop and think about what machine they are presently on and where specifically they are going.  Lowering barriers while creating efficiency, can result in a loss of  "situational awareness" which, depending upon the commands being keyed, can be very dangerous.

Why I wrote this:

There are literally dozens, if not hundreds of pages and blogs on-line offering detailed instructions as to how this process should be accomplished.  I in fact used these sources when I was trying to do this for the first time myself.  What I was unable to find, anywhere, among all these "how-to" pages was the answer to my next question; "why does this work".  At MarinerTek we have initiated a requirement for all senior level engineers to begin actively Blogging and I was looking at what I did every day. I realized I had never actually answered the question of exactly how and/or why this worked.  Like so many things we all do in a typical busy day, this was one pf those little things I just took for granted.  I'm really glad I decided to dig into the mechanics of this simple task. I learned about the three very gifted MIT professors who developed RSA and (if you are interested)  I discovered that Clifford Cocks, a British mathematician working on a top-secret project for the UK Intelligence Agency (Q from James Bond) ,  developed a nearly identical data encryption algorithm to RSA but was unable to take credit due to the sensitive nature of his work.

About MarinerTek I.T. Solutions:

MarinerTek is a VMware and xSQL focused I.T. Solutions firm operating throughout the greater Cleveland area, including northeast Ohio and western Pennsylvania. We are the experts to whom I.T. professionals turn for assistance. MarinerTek is delivering the benefits of VMware server & desktop virtualization to businesses throughout north east Ohio and the greater Cleveland areas looking for greater I.T. stability and reliability, regardless of their size.

MarinerTek also provides custom, xSQL based, application development services. Organizations inevitably amass large quantities of data. SQL Databases are critical for efficient management and accurate retrieval of information from this sea of data in a timely manner. MarinerTek MS-SQL programmers work in both on-site and off-site modes per the requirements of  each engagement. We also offer Cloud  based application development services, leveraging our skill set in Yii Frameworked PHP & mySQL development in Linux environments.

In Conclusion:

This has been an attempt to explain not only how to establish no-password SSH logins with RSA Key Pairs,  but also to summarize in simple terns the answer to the question; why does this actually work.

Reference Material:








MarinerTek, an NWBOC and WBENC certified woman owned small business headquartered in Cleveland, Ohio, specializes in custom software development, mobile application programming, .NET, SQL, SharePoint and SalesForce integration.

Comments are closed.