Setting Up and Debugging SSH Authorized Keys

Introduction

While the use of SSH authorized keys is fairly widespread, the ability to diagnose and solve problems and use optional features may be less common. This article describes the basic approach to setting up a trust relationship between two accounts using these keys, and it also covers how to debug issues and how to employ additional optional security measures.

SSH can be configured to allow certain users on certain hosts to connect without a password. This is done by placing a user's public SSH key into the .ssh/authorized_keys file in the destination user's home directory. (Note that the file name looked for by sshd defaults to the American spelling.) This can be done for the same host or for a different host.

Note : You can use this procedure without having to install a third-party version of SSH if your systems run the Solaris 9 or 10 Operating System. If you download and install SSH (for example, from sunfreeware.com), this procedure should work on the Solaris 2.6 OS and later; it might work on earlier versions, although that was not tested. Also, you should use a recent version of SSH.

Security Considerations

When setting up a trust relationship, remember that if the source host is compromised, the hosts that trust it are as good as compromised also. Here are some considerations:

• Avoid relationships that grant root access on a system (even from root on another system). If granting root access is absolutely necessary, at least restrict it to paired production and disaster recovery servers.
• Consider the direction of the trust; a development system should not be able to open shells on a production system. Avoid having one system that is able to open shells on many other systems.
• Discourage trust relationships for "real" users until first ensuring that they have a pass-phrase on their key. The main use of keys without pass-phrases should be for automating transfers and job communication between system accounts (for example, accounts that you cannot directly log in to).
• If you are using password aging, keep in mind that a trust relationship will circumvent any enforced password changes. If you are also employing account expiry based on the date of the last password change, you might find users getting locked out without warning.

Initial Setup

If the user in question doesn't have a key pair set up yet (that is, there's no id_dsa.pub file present), you can create one by running the following command:

ssh-keygen -t dsa

If you want to use this key for a non-interactive connection, do not provide a pass-phrase.

Anything encrypted using either of the two keys produced by this command can be decrypted only by the corresponding paired key.

To set up a trust relationship using this key pair, start with the user from which you intend to connect using SSH and copy the contents of $HOME/.ssh/id_dsa.pub.

Then, on the host to which you intend to connect using SSH, become the intended user and add the string you copied to $HOME/.ssh/authorized_keys.

These keys are exactly one line each; beware of accidentally introducing newline characters in the middle of your key.

Using a system like this means you can later revoke the access by removing that key from the authorized_keys file. Any existing connections will remain open, but all new ones will no longer be accepted without another form of authentication. This method also allows for applications and scripts to initiate shells and file transfers on the remote account without requiring that you hardcode passwords or provide passwords to development teams.

One downside of this method, however, is that if someone can obtain a copy of the trusted user's private SSH key ( id_dsa), that person could use it to impersonate that user and gain access to the remote account.

There is an optional entry you can add to the start of any of these authorized keys that will restrict sshd to allow only connections from a given host, somewhat reducing the scale of the risk.

Add the following as a prefix to a given key in the authorized_keys file:

from="<IP address of originating host>, <reverse lookup of IP address>"

If this is omitted, a key-based authentication will be accepted if the keys match, regardless of the source.

Troubleshooting

If you find SSH is still prompting for a password, check the following things on the destination host:

• File permissions on the authorized_keys file must not allow group or other to edit the file.
• Permissions on the destination user's $HOME/.ssh/ directory must not allow group or other to create files in this directory.
• Permissions on the destination user's home directory must not allow group or other to create files or directories in this directory.
• The destination user's account must not be locked. For system accounts that should not allow direct logins, the shadow file password entry should be NP, not *LK*.
• The public keys in the authorized_keys file should be one line for each key; make sure a key doesn't contain linefeeds anywhere.
• The IP address in the from= entry must be the correct IP address for the originating host, as seen by the destination host. If it's being translated by Network Address Translation (NAT), it must the IP address on the outbound side of the NAT.
• Check the sshd configuration file (usually /etc/ssh/sshd_config). Specifically, check that PubKeyAuthentication is set to yes and that AuthorizedKeysFile matches the file name you are using.

If all else fails, start a new instance of sshd in debug mode:

sshd -p <free port> -d -d

Now watch the output during an attempt at connecting. (Specify your alternate port on the SSH command line with the -p <port> option.) This will show you which check is failing.

Once done, stop the debug version of sshd by pressing Ctrl-C.

If it appears that the SSH client is not even attempting to use keys, rerun SSH with the -v flag (multiple -v flags increase verbosity), and watch the process to see that it is correctly locating the keys. If it is not, check the SSH default configuration file (usually /etc/ssh/ssh_config). Specifically, look at the IdentityFile entries (you can add more than one) to make sure your SSH client knows where to find your private key.