Manage Your Server Accounts Securely with Key-based Authentication
by W. Jason Gilmore
April 20, 2010
Save time and unnecessary hassle by using key-based authentication to manage multiple server accounts.
As your portfolio grows, you'll likely need to carry out Web site and server maintenance and updates in accordance with the service agreements you made with your clients. Doing so will require you to juggle an increasing number of server accounts, a task which can be tedious and fraught with frustration --particularly given the number of other everyday accounts and passwords you're already forced to track.
Many developers deal with the problem by simply using the same password for every account, a decision that can prove disastrous if an attacker compromises even a single server and accesses the user accounts. So you're really caught between a rock and a hard place, forced to either maintain a lengthy list of unique and complex passwords, or betting on the impenetrability of your clients' servers and reusing a single password as necessary.
Or are you?
As neither choice sounds particularly appealing, you might consider an alternative approach, which not only completely removes the need for you to maintain a password list, but also actually eliminates the need for you to provide any password whatsoever when logging in!
Introducing Key-based Authentication
When logging into a server using the SSH protocol, you'll be challenged to provide an account username and password. Should the provided information match what's on record with the server, you are granted secure access to a shell and can begin carrying out tasks in accordance with the permissions associated with your account. A concept known as key-based authentication gives you the ability to forego the provision of an account username and password, thanks to a technique known as public key cryptography.
I won't attempt to explain the rather heady mathematics that make public key cryptography possible. In a nutshell, key-based authentication implements public key cryptography in a manner that replaces the need for the client to provide a username and password with two files containing the client's public and private keys. The process works by placing the client's public key on the remote server. When the client attempts to log in to the remote server, the server encrypts a message using the public key and sends it to the client as a challenge. The client attempts to use the stored private key to decrypt the message. If successful, the client is granted access to the server, otherwise it is denied.
Thankfully, a slick command-line utility removes the complexity surrounding the generation of public and private keys, while the SSH daemon's built-in features hide the gory details of the client/server message encryption and decryption procedure.
You may have noticed that I've been careful to use the term client rather than user because key-based authentication is actually useful for much more than simplifying the login process. It's also commonly used to provide scripts with password-less access to a remote server. These scripts are handy for tasks such as server backups and server monitoring. Therefore, there's often no user at all actually triggering the login process, but rather a request hailing from a client machine responsible for triggering the scripting task.
Configuring Key-based Authentication
Configuring key-based authentication is a relatively straightforward process, with the first step usually involving the creation of the account's public and private keys. To generate your key-pair, first create a directory named .ssh in your home directory:
%>mkdir .ssh
Next, enter the .ssh directory and execute the following command, which will generate the keys:
%>ssh-keygen
The command will report that the key-generation process has begun, and you'll be prompted to specify the name of the file where the key will be stored. This is a tad confusing, because the prompt does not indicate which key (public or private) it means. It's actually referring to both, because the provided filename (which defaults to id_rsa) will actually be the base filename for both keys. The only difference between the two is that the public key filename will use the extension .pub. Unless you have special requirements, using the default is fine.
Defining a Passphrase
When the filename has been specified, the command will next ask you to enter a passphrase. Many tutorials will suggest you leave the passphrase blank, as doing so will allow you to subsequently login to the remote server without having to enter the passphrase. This might seem like an attractive option, but if an attacker ever compromised your client machine, he would have unfettered access to any remote server in which you've configured key-based authentication!
That suggestion doesn't strike me as a particularly sound approach, so instead I'm going to explain how you can configure key-based authentication to use a passphrase yet not require you to enter it every time you login to a remote server. I know that sounds paradoxical, but bear with me! Enter and confirm your passphrase using a string that would be difficult for somebody to guess.
When you enter the string, the ssh-keygen command will report that the public and private keys have been created. Presuming you used the default filename, the private key will be stored in a file named id_rsa, and the public key in id_rsa.pub. Never give others access to your private key; they will be able to masquerade as you and log into any remote server to which you have access!
Installing the Public Key
Next, you should copy the public key to a directory named .ssh residing in the account's home directory on the remote server. You can copy the key however you please, whether by SFTP, SCP or some other way. Of course, if the .ssh directory doesn't already exist, you'll need to create it first. For instance, you can copy user webuser's public key from your local machine to the server identified by 192.168.1.103 using the following scp command:
Next, you're going to add this key to a list of authorized keys located in a file named authorized_keys. This is easy to do using the cat command (from within the remote server's .ssh directory):
%>cat id_rsa.pub >> authorized_keys
Finally, delete the id_rsa.pub file from the server, as you no longer need it.
Access the Remote Server
With the public key installed on the remote server, you should be able to login to the server by providing only the passphrase:
%>ssh webuser@192.168.1.103
Enter passphrase for key '/home/webuser/.ssh/id_rsa':
webuser@192.168.1.103:~$
You're in! Even if the tutorial concluded now, this approach is a major step forward because you can securely use a single passphrase in conjunction with key-based authentication to log in to remote servers. Just remember to ask the system administrator to disable your remote password for that account, otherwise an unexpected back door could be left in place. However, remember the goal: allowing for secure password-less authentication. So, one more configuration step is required to complete the task.
Introducing ssh-agent
Previously, I suggested using a passphrase because otherwise an attacker who steals your unencrypted private key would be able to enter any remote server where your public key has been configured. You can add a passphrase to your private key while still foregoing the need to enter it every time you access a remote server by caching the passphrase using the ssh-agent daemon. To cache your passphrase, start the ssh-agent like this (presuming you use the Bash shell, otherwise adjust the command accordingly):
%>ssh-agent bash
Next, execute the ssh-add command to cache the passphrase:
%>ssh-add
Enter passphrase for /home/webuser/.ssh/id_rsa:
Identity added: /home/webuser/.ssh/id_rsa (/home/webuser/.ssh/id_rsa)
Now try logging in to your remote server. You'll see no passphrase is required! In order to continue logging in without using the passphrase, you'll need to make sure the ssh-agent is started when you log in to your local machine. You can accomplish this in a variety of ways depending on the operating system, so consult online resources for more information about your particular situation.
Conclusion
Configuring key-based authentication is one of those tasks that takes only a few minutes to complete, yet can save you literally hours of time over the course of a year. Take the time to investigate this powerful mechanism further.
