These are also user keys. The identity name is the default name for use with the SSH-1 protocol. Although the SSH-1 protocol is flawed and it is recommended not to use, it is still a superior implementation over telnet. If you are using SSH-1, plan on migrating to SSH-2. If you are just starting out with SSH, start with SSH-2.

Your private key is to be kept private! (Remember the key in the trench coat). Do not share your private key or the passphrase assigned to it. Let's see what one of these public keys looks like:

In Part 2 of this series we discussed the host keys. As you can see here, the public key created for this user is the same format. The first field is the algorithm used for this key (DSS or DSA) and the last field is the identifier of the key's owner (vking@client).

Once the keys are created, the user needs to place the public key on the SSH server(s). Copy the user's public key to the authenticated_keys file for the user on the server. (Note: you may also see a file named authenticated_keys2, this is the default for SSH-2. OpenSSH will use both keys and keys2. In the HP SSH configuration file "#AuthorizedKeysFile .ssh/authorized_keys" is the default setting).

In a real world situation, you would always append to the authorized_keys file to add a new key. The authorized_keys file may contain more than one identity. Now that we have an entry in the authorized_keys file on the server side, let's initiate a new ssh session:

This time the client is prompted for the passphrase for the key. If the passphrase is correct, the user will be authenticated and the user authentication process is complete.

However, there is a way that will allow you to enter the passphrase just once. On the client this information can be added to the ssh authorization agent. This is accomplished by using the following two commands and entering the passphrase:

By default the ssh-add command will attempt to add the key to the authorization agent for the id_rsa, id_dsa, and identity keys. Each should have a passphrase. The ssh-add command will prompt the user for the passphrase. This same passphrase will be used for each key. If the passphrase fails, it will prompt the user to enter another passphrase. In the above example we were only prompted for a passphrase once since both the rsa and dsa keys have the same passphrase. An identity key pair does not exist so a message was displayed indicating this.

Now that we have loaded our user key into the authentication agent, the ssh session to the server is successful and the user was not prompted for a password!

So, why was the UNIX password not prompted for? A look at the detail of the session shows that the publickey authentication passed. Since this authentication passed, there is no need to try the next authentication method (which would be the UNIX login password prompt). SSH authentication is not like PAM authentication. Once authentication is passed it will not attempt other additional methods.

Examining the output from the session shows it is first checking the RSA key followed by the DSA key. If you recall, we only copied the DSA public key to the authorized_keys file. Since the RSA key was not in this file, this authorization failed. Only keys that have been added to the agent will be tried.

Why was vking allowed to login as jrice without a password? 1). In jrice's authorized_keys file is the public key for vking and 2). vking's authenticated identity was in the authentication agent.

Those familiar with security will immediately start waving a red flag over this. Why? Because if a user's permissions are not set correctly on directories and/or files, another user could possibly write to this file and add their own public key to the authorized_keys file. This is true, if permissions are set incorrectly, a user could add their public key. However, ssh is smart enough to check the permissions before allowing access. In this example, I have only changed the permissions on jrice's authorized_keys file.

client: ssh jrice@ctg701
jrice@ctg701's password:

The user is prompted for the UNIX login password because the publickey authentication failed. The following message is written to the syslog:

The default sshd configuration setting is "StrictModes yes" and as you can see from this exercise, it is very important that it remains set to "yes". There are many configuration settings, both for the client and server. These will be covered in the next article in this series.

Chris Wong is a technical consultant and trainer for Cerius Technology Group, Inc. in Bellevue, WA. She is the author of the HP Press book HP-UX 11i Security. http://newfdawg.com

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy