Host Key: This key is the unique ID of the SSH server. It is a persistent key. It is asymmetric. The private key...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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:
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.
|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
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