Problem solve Get help with specific problems with your technologies, process and projects.

HP-UX Secure Shell: Part 2 - Keys in SSH

Last week went over SSH instalation and terms, this week it's keys.

Host Key: This key is the unique ID of the SSH server. It is a persistent key. It is asymmetric. The private key...

is not encrypted, as you might expect, but rather must be protected by file permissions. On SSH1 implementations you will see one key pair per hostname. On SSH2 implementations there will be one DSA host key pair and one RSA host key pair per socket. Typically, there is only one SSH server running on a host, so it is easy to associate the Host Key with an individual HP-UX system. However, if multiple SSH instances are running on the one system, each instance could have their own Host Key pairs. Let's look at the specific files on the HP-UX SSH server:

The ssh_host_key is a 1024 bit private key for the host. The is the corresponding public key. These 2 keys are only used with SSH1.

It is imperative that the private key be kept secure while the public key is available for distribution. This is accomplished through the permissions on the 2 key files:

-rw-------   1 root       sys        526 Aug  8 08:49 ssh_host_key
-rw-r--r--   1 root       sys        330 Aug  8 08:49

and the permission on the parent directory:

drwxr-xr-x   2 bin        bin       1024 Aug  8 08:50 /opt/ssh/etc

Note that /etc/opt/ssh is linked to /opt/ssh/etc

Found in the same directory is a key pair for both DSA and RSA:

-rw-------   1 root       sys     668 Aug  8 08:50 ssh_host_dsa_key
-rw-r--r--   1 root       sys     601 Aug  8 08:50

-rw-------   1 root       sys     883 Aug  8 08:50 ssh_host_rsa_key
-rw-r--r--   1 root       sys     221 Aug  8 08:50

The host authentication process is only as reliable as the security of the private key. When thinking of a private key imagine a key with a trench coat on, the coat should always be kept closed! The public key on the other hand is distributed fairly freely. (I won't give you anything to imagine for this one). Keep in mind all avenues of access to the private key (file/directory permissions, back up tapes, and root access).

All these keys are built during the installation process. For the sake of learning, we will create a new set of RSA Host Keys. If you already have SSH implemented, you do not want to do this.

ctg701#: ssh-keygen -t rsa -f /opt/ssh/etc/ssh_host_rsa_key
Generating public/private rsa key pair.
/opt/ssh/etc/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): [press return]
Enter same passphrase again: [press return]
Your identification has been saved in /opt/ssh/etc/ssh_host_rsa_key.
Your public key has been saved in /opt/ssh/etc/
The key fingerprint is:
6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b root@ctg701

ctg701#: ll *rsa*
-rw-------   1 root       sys    883 Aug 22 13:59 ssh_host_rsa_key
-rw-r--r--   1 root       sys    221 Aug 22 13:59

Remember, the Host Private Key is never protected with a passphrase. This is why when generating a new Host Key, we pressed return twice instead of entering a password. (This allows the ssh daemon to read the key at startup without waiting for someone to enter the passphrase.) When a new Host Key is generated, the SSH daemon needs to be restarted to use the new key. Take a look at the contents of the keys:

ctg701#: more ssh_host_rsa_key

ctg701#: more
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA4ALBpsnxd16lxVX4SwpMP
dni4atpc9ZA4P1lOX3hmks= root@ctg701

The above public key has a few interesting fields. The first field shows that this is using RSA as its public key algorithm. The last field shows the server name.

A look at the DSA public host key shows the similar format:

ctg701#: more
gFx32UU1TMtDs9QuGnq root@ctg701

But, instead of saying "DSA" it says "DSS". This is because DSA is part of the Digital Signature Standard.

When a client connects to the SSH server, a copy of the Public Host Key gets copied to the client. This is used by the client to verify the server in future sessions. Since each client has a copy of this Public key, you can imagine the mess if you change the Host keys.

In fact, this is an added security feature that prevents someone from mounting a man-in-the-middle attack. If that stored host key should change, SSH on the client will issue all sorts of dire warning.

Key Purpose Type Comments
Host ID of SSH Server Asymmetric Persistent Private not encrypted
Server Used to create Session Key Asymmetric Not Persistent Only used with SSH-1
User ID of SSH Client Asymmetric Persistent Private is encrypted
Session Used to encrypt the session Symmetric
Persistent for the session only
Secret Key

Server Key: These keys are never stored on disk and are generated every "n" seconds. The default being one hour. Server keys are only used with SSH1 and are asymmetric.

User Keys: As the host key identifies the host, the user keys are used to identify the user. These are also asymmetric keys, but the private key is encrypted with a user specified passphrase. These keys are also typically persistent. Users may have more than one key pair.

Session Keys: A session key is generated between the client and server and used for the entire session for encryption. SSH1 uses the Server Key to generate the Session Key. SSH2 generates two session keys (one for server-client, the other client-server). On HP-SSH the Diffie-Hellman key exchange is used with AES as the generator. This symmetric key, also known as the secret key, is used to encrypt the session. This is probably why you are interested in SSH, to use an encrypted session instead of having traffic passed in clear text across the network with services such as telnet. The session keys are handled by the SSH server and the client.

Next week we'll look at examples of using Host Keys in an ssh session.

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.

This was last published in September 2002

Dig Deeper on Network Performance Management



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

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

Please create a username to comment.