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

Creating and using User (or Public) Keys.

This Content Component encountered an error

In part three 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+N1Lq
jc7Tm+xgmlItR+84sRMTXLiHHPjll9ZgjE8Kiq8xTz5m0xZGGnOIeiBwVw9iBNGRtfdcqkmW804UC2t/
/7xfJ55t7RzU4Mi2/BRBzP3UmudcvLavAAAAFQChZUmdBoNcQvP5O8YiQQoEjzudrwAAAIAiRqjx8ACO
v3WSq+bHejwCESG+OfTQCbsLLrvcArcp1mvwoq4C6DRjI4Wi2ifI3iweZrY+BT8NHKJ78gUE1he0jngZ
xZJOh8ofJuSK8l/2PXRwHPXn8izg5RulIlBOQ2UwXrCG5B61qFH72YZg+2qH3mfTFOQm3pmz3UYDm2aL
7gAAAIA1ceJiYr4wL6OPwaLCcAqxvHNyWwNWzvPfTT/tiYKcdkGzy8wsrybr1mIKs2+LzCzMc/YcYYwk
PDoQ/2nn7q4H7EL47LbnZ7CDX7y0Iyv+CUFrrL8Ucmr/iz/9BeIPhkHdVGNEfB3cvBg9ROUlAAe34PBC
tMt0UQVNmkMPIfN/eA== vking@client

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).

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


This was first published in September 2002

Dig deeper on Network Performance Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close