HP-SSH Part 2

HP-UX Secure Shell: Part 2: User (Public Key) Authentication

By Chris Wong

In Part 1 of this series we covered the default host authentication and the default user authentication (UNIX login password). In this article we will discuss creating and using user keys, also known as public keys.

User keys are used to identify an individual user account.  To start, the user must create their own user key pair by using the ssh-keygen command.

Since we are only using SSH-2 (because SSH-1 has several security related flaws), the user creates two sets of key pairs. The first for RSA:

client: ssh-keygen -t rsa -f /home/vking/.ssh/id_rsa

Generating public/private rsa key pair.

Enter passphrase (empty for no passphrase): [mypassphrase8]

Enter same passphrase again: [mypassphrase8]

Your identification has been saved in /home/vking/.ssh/id_rsa.

Your public key has been saved in /home/vking/.ssh/id_rsa.pub.

The key fingerprint is:

17:02:9e:e8:3f:5a:c9:aa:f3:e9:58:39:02:69:54:2e vking@client

-rw------- 1 vking users 951 Aug 25 19:29 id_rsa

-rw-r--r-- 1 vking users 222 Aug 25 19:29 id_rsa.pub

and the second for DSA:

client: ssh-keygen -t dsa -f /home/vking/.ssh/id_dsa

Generating public/private dsa key pair.

Enter passphrase (empty for no passphrase): [mypassphrase8]

Enter same passphrase again: [mypassphrase8]

Your identification has been saved in /home/vking/.ssh/id_dsa.

Your public key has been saved in /home/vking/.ssh/id_dsa.pub.

The key fingerprint is:

aa:f1:57:9e:cb:f7:80:d7:70:b2:11:60:40:0c:7a:c3 vking@client

-rw------- 1 vking users 736 Aug 25 19:32 id_dsa

-rw-r--r-- 1 vking users 602 Aug 25 19:32 id_dsa.pub

A point that is often misunderstood is that the passphrase is not the key. Rather it is the key that is used to encrypt (or protect) the private key.

On some systems you may also see files named:

-rw------- 1 vking users 951 Aug 23 10:10 identity

-rw-r--r--   1 vking   users  222 Aug 23 10:10 identity.pub

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:

client: more id_dsa.pub

ssh-dss AAAAB3NzaC1kc3MAAACBAIBe3f2B8z5PHUP6/RM89iF0DzNEVCBg8AtO/VjY/zHaqOgkU/Db54E+N1Lqjc7Tm+xgmlItR+84sRMTXLiHHPjll9ZgjE8Kiq8xTz5m0xZGGnOIeiBwVw9iBNGRtfdcqkmW804UC2t//7xfJ55t7RzU4Mi2/BRBzP3UmudcvLavAAAAFQChZUmdBoNcQvP5O8YiQQoEjzudrwAAAIAiRqjx8ACOv3WSq+bHejwCESG+OfTQCbsLLrvcArcp1mvwoq4C6DRjI4Wi2ifI3iweZrY+BT8NHKJ78gUE1he0jngZxZJOh8ofJuSK8l/2PXRwHPXn8izg5RulIlBOQ2UwXrCG5B61qFH72YZg+2qH3mfTFOQm3pmz3UYDm2aL7gAAAIA1ceJiYr4wL6OPwaLCcAqxvHNyWwNWzvPfTT/tiYKcdkGzy8wsrybr1mIKs2+LzCzMc/YcYYwkPDoQ/2nn7q4H7EL47LbnZ7CDX7y0Iyv+CUFrrL8Ucmr/iz/9BeIPhkHdVGNEfB3cvBg9ROUlAAe34PBCtMt0UQVNmkMPIfN/eA== vking@client

In Part 1 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).

Make sure you only copy the public key, not the private key.

[ copy from client: /home/vking/.ssh/id_dsa.pub

  to server: /home/vking/.ssh/authorized_keys ]

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:

client: ssh ctg701

Enter passphrase for key '/home/vking/.ssh/id_dsa': mypassphrase8

Last login: Fri Aug 23 10:32:43 2002 from client

ctg701:

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:

client: ssh-agent $SHELL

client: ssh-add

Enter passphrase for /home/vking/.ssh/id_rsa: [mypassphrase8]

Identity added: /home/vking/.ssh/id_rsa (/home/vking/.ssh/id_rsa)

Identity added: /home/vking/.ssh/id_dsa (/home/vking/.ssh/id_dsa)

/home/vking/.ssh/identity: No such file or directory

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!

client: ssh ctg701

Last login: Fri Aug 23 10:37:07 2002 from client

ctg701:

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.

debug1: next auth method to try is publickey

debug1: userauth_pubkey_agent: testing agent key /home/vking/.ssh/id_rsa

debug1: authentications that can continue: external-keyx,gssapi,publickey,passwe

debug1: userauth_pubkey_agent: testing agent key /home/vking/.ssh/id_dsa

debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 4002c8c0 hint -1

debug1: ssh-userauth2 successful: method publickey

debug1: channel 0: new [client-session]

debug1: send channel open 0

debug1: Entering interactive session.

We’ll look at another example to help explain the authorized_keys file. In this example the user named vking will connect to the server, but as a different user, jrice:

client: whoami

vking

client: ssh jrice@ctg701

or you could use this format:

client: ssh -l jrice ctg701

Last login: Fri Aug 23 10:42:42 2002 from client

ctg701: whoami

jrice

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:

Authentication refused: bad ownership or modes for file /home/jrice/.ssh/authorized_keys

SSH will only check for this if a specific sshd configuration parameter is set correctly. If this entry is changed to a far weaker security setting:

StrictModes no

Then the user can successfully login:

client: ssh jrice@ctg701

Last login: Fri Aug 23 11:16:46 2002 from client

ctg701:

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

All Rights Reserved, Copyright 2000 - 2002, TechTarget
SearchHP.com is a search service provided by TechTarget and is completely independent of and not affiliated with Hewlett-Packard Company.