OpenSSH Key Management: RSA/DSA certification (reprint)

Many of us use good OpenSSH as a replacement for old telnet and rsh commands, and OpenSSH are not only secure but also encrypted.

One of the more appealing features of OpenSSH is its ability to authenticate users with RSA and DSA authentication protocols based on a pair of complementary digital keys. RSA and DSA certification promises to establish a connection to a remote system without having to provide a password, which is one of its main charms. While this is fascinating, OpenSSH's new users often configure RSA/DSA in a fast but imperfect way, resulting in a large security hole in the process, despite the password-free login.

What is RSA/DSA certification?

SSH, especially OpenSSH (completely free of SSH implementations), is an incredible tool. Similar to Telnet or rsh, the SSH client can also be used to log on to the remote machine. All that is required is that the remote machine is running sshd, the SSH server process. However, unlike Telnet, the SSH protocol is very secure. Encrypt the data flow, ensure the integrity of the data flow, and even secure and reliable authentication it uses a specialized algorithm.

However, although SSH is really great, there is still an SSH feature component that is often overlooked, misused, or simply misunderstood. This component is OpenSSH's RSA/DSA key authentication system, which can replace the standard Secure Password authentication system used by the OpenSSH default.

The OpenSSH RSA and DSA authentication protocol is based on a pair of specially generated keys, called private keys and public keys, respectively. The advantage of using these key-based authentication systems is that in many cases it is possible to establish a secure connection without having to enter the password manually.

Although the key-based authentication protocol is fairly secure, when users are not fully aware of the security implications of these simplified operations, there is a problem when using some simplified operations for convenience. In this article, we will discuss in detail how to correctly use RSA and DSA authentication protocols, so that we do not risk any unnecessary security risks. In my next article, I'll show you how to use ssh-agent to hide a private key that has been decrypted, as well as an introduction to keychain, which is the front end of Ssh-agent and provides many conveniences without sacrificing security. If you've always wanted to master OpenSSH's more advanced authentication features, then please read on.

How the RSA/DSA key works

The following is a general overview of how the RSA/DSA key works. Let's start with an imaginary scenario, assuming that we want to use RSA authentication to allow a local Linux workstation (called Localbox) to open a remote shell on Remotebox, Remotebox is a machine from our ISP. At this point, when we try to connect to Remotebox with our SSH client, we get the following hints:

%

SSH [email protected]

[email protected] ' s password:

What we see here is an example of the default way that SSH handles authentication. In other words, it asks us to enter the password for this account on Remotebox drobbins. If we enter our password on the Remotebox, SSH will use the Secure Password Authentication protocol to send our password to Remotebox for verification. However, unlike the Telnet scenario, where our password is encrypted, it will not be intercepted by people who have seen our data connections. Once Remotebox has verified the password we provided with its password database, we will be allowed to log in if successful, and a remotebox shell prompt will welcome us. Although SSH's default authentication method is fairly secure, RSA and DSA certifications have created some new potential opportunities for us.

However, unlike SSH Secure Password authentication, RSA authentication requires some initial configuration. We only need to perform these initial configuration steps once. After that, the RSA authentication between Localbox and Remotebox is effortless. To set up RSA authentication, we first have to generate a pair of keys, a private key, and a public key. These two keys have some very interesting properties. The public key is used to encrypt the message, and only the person who owns the private key can decrypt the message. The public key can only be used for encryption, and the private key can only be used to decrypt messages encoded by a matching public key. The RSA (and DSA) authentication protocol uses these special properties of key pairs for secure authentication and does not require any confidential information to be transmitted online.

To apply RSA or DSA authentication, we need to perform a one-time configuration step. We copy the public key to the Remotebox. There is a reason why public keys are referred to as "public". Because it can only be used to encrypt the messages that are given to us, we don't need to worry too much about it falling into the hands of others. Once our public key has been copied to Remotebox and for Remotebox sshd to be able to locate it and put it in a dedicated file (~/.ssh/authorized_keys), we use RSA authentication to login to Remotebox was ready.

To log in with RSA, we just type ssh [email protected] in the console of Localbox, as we often do. But this time, SSH tells Remotebox sshd that it wants to use the RSA authentication protocol. What happens next is very interesting. The Remotebox sshd generates a random number and encrypts the random number using the public key that we previously copied past. The sshd then sends the encrypted random number back to SSH that is running on the Localbox. Next, the turn of our SSH with the private key to decrypt this random number, and then send it back to Remotebox, actually equals to say: "Look, I do have a matching private key; I can successfully decrypt your message!" Finally, Sshd concludes that since we hold a matching private key, we should be allowed to log in. Therefore, we have a matching private key which authorizes us to visit Remotebox.

Two considerations

There are two important considerations for RSA and DSA certifications. The first is that we really just need to generate a pair of keys. Then we can copy our public key to the remote machines we want to access, and they will be properly authenticated according to our private key. In other words, we don't need to prepare a pair of keys for each system we want to access. As long as a pair is enough.

Another consideration is that the private key should not fall into the hands of others. It is the private key that authorizes us to access the remote system, and anyone who has our private key will be granted the same privileges as ours. Just as we don't want strangers to have the keys to our place, we should protect our private keys from unauthorized use. In the world of bits and bytes, this means that no one is supposed to be able to read or copy our private key.

The developers of SSH certainly know the importance of the private key, and they have added some precautions in SSH and ssh-keygen to prevent misuse of our private key. First, SSH is set to print a large warning message if the file permissions of our key allow anyone other than us to read the key. Second, when we create a public/private key pair with Ssh-keygen, Ssh-keygen asks us to enter a passphrase. If we enter a passphrase, Ssh-keygen will use that passphrase to encrypt our private key so that, even if the private key is stolen, this private key is useless for those who happen to not know the passphrase. With this knowledge, let's look at how to set up ssh to apply RSA and DSA authentication protocols.

A probe into Ssh-keygen

The first step in setting up RSA authentication starts with generating a pair of public/private key pairs. RSA authentication is the initial form of SSH key authentication, so RSA should be available for all versions of OpenSSH, although I recommend that you install the most recent version available, which is openssh-2.9_p2 when I write this post. Here's how to generate a pair of RSA keys:

% Ssh-keygen

Generating public/private RSA1 key pair.

Enter file in which to save the key (/home/drobbins/.ssh/identity):

(Hit Enter)

Enter passphrase (empty for no passphrase):

(Enter a passphrase)

Enter same Passphrase again:

(Enter it again)

Your identification has been saved in/home/drobbins/.ssh/identity.

Your public key has been saved in/home/drobbins/.ssh/identity.pub.

The key fingerprint is:

a4:e7:f2:39:a7:eb:fd:f8:39:f1:f1:7b:fe:48:a1:09 [email protected]

When Ssh-keygen asks to enter the default location for the key, we hit the ENTER key to accept the default/home/drobbins/.ssh/identity. Ssh-keygen will save the private key in this path, and the public key will exist in a file called Identity.pub.

Please also note that Ssh-keygen also prompted us to enter a passphrase. At that time we entered a good passphrase (seven-bit or more characters that were unpredictable). Ssh-keygen then uses this passphrase to encrypt our private key (~/.ssh/identity) so that our private key will become useless to those who do not know the passphrase.

The pursuit of a fast compromise solution

When we specify a passphrase, although this allows Ssh-keygen to protect our private key from misuse, it also brings a little inconvenience. Now, whenever we try to connect to the [email protected] account with SSH, SSH prompts us to enter the passphrase so that it can decrypt our private key and use our private key for RSA authentication. In addition, instead of the password for the Drobbins account on the Remotebox, we enter the passphrase required to decrypt the private key on the local machine. Once our private key is decrypted, our SSH client program will handle the rest of it. While the mechanism for using our remote passwords and using RSA passphrase is completely different, we are actually prompted to enter a "secret phrase" for SSH.

#

SSH [email protected]

Enter passphrase for key '/home/drobbins/.ssh/identity ':

(Enter passphrase)

Last Login:thu June 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!

%

This is where people are often misled into pursuing fast compromises. There are times when people create private keys that are not encrypted just so that they do not have to enter a password. In that case, they simply enter the SSH command and will immediately be authenticated and logged in with RSA (or DSA).

#

SSH [email protected]

Last Login:thu June 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!

%

However, while this is convenient, you should not use it if you do not fully understand the security implications of this approach. If someone breaks into localbox at some point, an unencrypted private key allows them to automatically have access to Remotebox and all other systems that have been configured with this public key.

I know what you're thinking. No password authentication, although a bit risky, can look really tempting. I totally agree. But there's a better way! Trust me, I'll show you how you can enjoy the benefits of no password authentication without sacrificing the security of your private key. In my next article, I'll also show you how to use ssh-agent skillfully (it's the first thing that makes it possible to secure a password-free authentication). Now, let's prepare for using ssh-agent by setting RSA and DSA certifications. Here are step-by-steps instructions.

Generation of RSA key pairs

To set up RSA authentication, we need to perform a one-time step to generate a public/private key pair. Our input is as follows:

% Ssh-keygen

When prompted, accept the default key location (typically ~/.ssh/identity and the ~/.ssh/identity.pub that stores the public key) and provide Ssh-keygen a secure passphrase. Once the Ssh-keygen is complete, you will get a public key and a private key encrypted with a passphrase.

Installation of RSA public key

Next, we need to set up the remote system that is running sshd to use our public RSA key for authentication. Typically, we do this by copying the public key to the remote system as follows:

%SCP ~/.ssh/identity.pub [email protected]:

Since RSA authentication is not fully set up, we are prompted to enter the password on Remotebox. Please do as you like. Then, log in to Remotebox and attach the public key to the file ~/.ssh/authorized_keys, as follows:

%

SSH [email protected]

[email protected] ' s password:

(Enter password)

Last Login:thu June 20:28:47 2001 from localbox.gentoo.org

Welcome to remotebox!

%

Cat Identity.pub >> ~/.ssh/authorized_keys

% exit

Now, after configuring RSA authentication, when we try to connect to Remotebox using SSH, we should be prompted to enter the RSA passphrase (not our password).

%ssh [email protected]

Enter passphrase for key '/home/drobbins/.ssh/identity ':

Well, the RSA certified configuration is complete! If you are not prompted to enter a passphrase, you can experiment with the following scenarios. First, try to login by typing ssh-1 [email protected]. It will allow SSH to apply only the SSH protocol version 1, which may be required if for some reason the remote system defaults to DSA authentication. If it doesn't work, make sure there's no such line rsaauthentication in your/etc/ssh/ssh_config. If so, please add a "#" in front to comment out this line. Alternatively, try contacting your Remotebox system administrator to verify that RSA authentication is enabled on their end and that the settings in/etc/ssh/sshd_config are correct.

Generation of DSA Keys

Version 1 of the SSH protocol uses the RSA key, while the DSA key is used for protocol level 2, which is the latest version of the SSH protocol. All current versions of OpenSSH should be able to use both RSA keys and DSA keys. The DSA key is generated using OpenSSH's ssh-keygen in a manner similar to RSA keys as follows:

%ssh-keygen-t DSA

We will also be prompted to enter a passphrase. Enter a secure passphrase. You will also be prompted to enter the location where you saved the DSA key. Under normal circumstances, the default ~/.SSH/ID_DSA and ~/.ssh/id_dsa.pub are OK. After we have generated the DSA key once, it is time to install our DSA public key on the remote system.

Installation of DSA public key

The DSA public key installation is almost identical to the RSA installation. For DSA, we are going to copy the ~/.ssh/id_dsa.pub file to Remotebox and attach it to the ~/.ssh/authorized_keys2 file on Remotebox. Please note that the name of this file differs from RSA's Authorized_keys file name. Once configured, the passphrase for entering our DSA private key should be able to log in to Remotebox without the need for us to enter a real password on Remotebox.

OpenSSH Key Management: RSA/DSA certification (reprint)