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

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 ssh_host_key.pub 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 ssh_host_key.pub

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 

    Requires Free Membership to View

sys 668 Aug 8 08:50 ssh_host_dsa_key -rw-r--r-- 1 root sys 601 Aug 8 08:50 ssh_host_dsa_key.pub -rw------- 1 root sys 883 Aug 8 08:50 ssh_host_rsa_key -rw-r--r-- 1 root sys 221 Aug 8 08:50 ssh_host_rsa_key.pub

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/ssh_host_rsa_key.pub.
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 ssh_host_rsa_key.pub

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_host_rsa_key.pub
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 ssh_host_dsa_key.pub
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.

HostID of SSH ServerAsymmetric PersistentPrivate not encrypted
ServerUsed to create Session KeyAsymmetric Not PersistentOnly used with SSH-1
UserID of SSH ClientAsymmetric PersistentPrivate is encrypted
SessionUsed to encrypt the sessionSymmetric
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. http://newfdawg.com

This was first published in September 2002

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.