• Login
• Become a member
• RSS
• Part of the TechTarget network

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 

      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
-----BEGIN RSA PRIVATE KEY-----
MIICWQIBAAKBgQDgAsGmyfF3XqXFVfhLCkw/ml6yF7JnpX5M9NzxEsAeX/aiA+HE
n/gd32SXNVe58lepgVECOdwd8HeMGr14feNnYrmXLLkY0rqvDib3LC2+un4lksCJ
rd4lMcQ+omXGNihKLjVVdtBOyk1pt3NqQyGZ2eLhq2lz1kDg/WU5feGaSwIBIwKB
gGzOI4uGqHvO4s2QKCRyt1IXx5hUpxxmU0nzRr48Tq+q9CLOr3zCulenBPj8pvPq
vN1NcH1sj3xBmSbLKNQf43pzKSmUluBL/FGYgursLrc5pk72cBQNfYisWqch9qIs
ZWaBKBavn3nk2y8e4r0unicCiBUX52upaUKdgnzBFRBTAkEA9Fkz/IpeSjfk4FCU
kFCN7faDm6a+N6Wm/EfMKTOqHDKnpZM+XHZGIkC+/4CQlQdn0ASk6kAWeWJoAkQd
BC1qVQJBAOqxSdEWOAowBBH2Bnle5L9ASrBvR9Lqvyz+C1Fjguu7dSRenRov0XaF
pA7y27eJSyLGEVO2UoecWT5fwUaI0h8CQFPGz/7QWteeIpYM/7xzY9yPCI0jOecx
exSq5umODnARXgziBsCdlGOD6bavvIrd97UI6BXM1IFjkV/c1r+aitsCQH9njnjR
jCLJm888aeodkh6t32cX1ohwzi5eBiTeP8HMKaYHedsEA/6DD+rbm9ipndEMb85b
qSULu2sAyAG3/QkCQEZojhAG0qyQ6ssAoItHi6ml++PaBAZTY+nw/c73CbViAWNF
YapKzxIJdBRSBR4EyS2auaDSwkbJ9F5OlIdylrw
-----END RSA PRIVATE KEY-----

ctg701#: more ssh_host_rsa_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA4ALBpsnxd16lxVX4SwpMP
5pesheyZ6V+TPTc8RLAHl/2ogPhxJ/4Hd9klzVXufJXqYFRAjncHfB3jBq9eH3jZ
2K5lyy5GNK6rw4m9ywtvrp+JZLAia3eJTHEPqJlxjYoSi41VXbQTspNabdzakMhm
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
ssh-dss AAAAB3NzaC1kc3MAAACBAPXUUu+FamOVbt9II5LWgJzMhtHbJ
z8XVKlvagELpIxMItlpe0T+n0eb7rcIzX3SMVRPZNudJiJBL7CiPDGJQuufiPPAG
TtjVHcY4yZfK2CYu3SRTweT4LdybOG6xYBOiX+X582W8gTjSlowVax6Kvdu3kkol
VDbLJSPRSTc76p/AAAAFQDQGpI0P60lm2dqdBklsY/ZJmGjtQAAAIEAofBIs5rNn
iPMDYCFIMA2YkAhOmNUKTDbElRV0EAmof6Hx9ElgXCaH4J+btlj8ZeaUFE+CeSIR
A75EXNDF8oOy1M+LiSvq884aKBLqHwkOYbgSPXNIcjLsttsT7+jRzFlptl3MIgn6
P5e/KdCzYNN9HgsPaOE5jgTl168xQYQm8YAAACBALKDw1AHx5bMr27kQZPQzisFx
+CDSfZnsevkfsunwTCQLrZO4iiL5MMkZ0Map2xeUsVvO1lA52ompSmIIMvn78dq/
PwXZ04pSzVI90piCzoB2WZZENgxhQ9ciVt+SLy6Q/tbKutmopSF+uoZyNfST4Qe/
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.

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

Join the conversationComment

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.