SSH Reference Manual

• have their own private key stored in the safe location
• send over the public key belonging to their private key to the peer system for authentication
• have the public key of the peer system configured in order to be able to verify its authenticity
Dealing with two key pairs for any two partners communicating can be a bit confusing, therefore we go over the two key
pairs in a bit more detail in the next subsections. Please note that
• (A) when operating as SSH daemon, you are accessing your own private key and verifying the remote public
key.
• (B) when operating as SSH client, you also are accessing your own private key and verifying the remote public
key.
• the two key pairs mentioned under (A) and (B) are different resulting in a total of four key pairs being
maintained when operating both as daemon and client. The following list shows all four key pairs and where
they are configured in the comForte SSH implementation (the following subsections will go into a bit more
detail, the names in brackets are repeated there for ease of reference):
o (KEYPAIR1) A key pair used to authenticate the NonStop system to the partner system when the NonStop
system acts as daemon (HOSTKEY parameter of SSH2 process)
o (KEYPAIR2) A key pair used to log on the partner system to the NonStop system when the partner system
is acting as client (PUBLICKEY property of USER entity in user database in daemon mode)
o (KEYPAIR3) A key pair used to authenticate the partner system to the NonStop system when the partner
system is acting as daemon (KNOWNHOST entity of user database in client mode)
o (KEYPAIR4) A key pair used to log on a NonStop user on the partner system when the NonStop system
acts as client (KEY entity of user database in client mode)
In the NonStop SSH2 implemention the local host key (KEYPAIR1 above) is of format DSA (1024 bit), the remote host
keys (KEYPAIR3 above) can be DSA or RSA keys and the local or remote user keys (KEYPAIR4 and KEYPAIR2
above, respectively) can be DSA or RSA keys.
Assuring Host Authenticity
For every encryption protocol it is important for the client to check the servers authenticity. Not doing so enables the so-
called man-in-the-middle attack which allows deciphering of the network traffic even though it is encrypted.
In the SSH protocol, authentication of the server is done by using public key authentication. The server generates a key
pair; the private key of which he keeps to himself while sending the public key over to the client during connection
setup. The client then verifies the public key and in order to be able to, the proper public key has to be configured at the
client once.
Within the comForte implementation
• (KEYPAIR1) When acting as SSH daemon, the host key pair for the SSH2 daemon process is created during
startup of the SSH2 process. It can be controlled with the "HOSTKEY
" parameter described in chapter
"Configuring And Running SSH2".
• (KEYPAIR3) When acting as SSH client, the public key of the remote host is configured by the
KNOWNHOST entity of the user database.
Client logon
The client can also use a key pair to authenticate against the server; in this case the server will use that information
instead of a password supplied by the client. The SSH protocol supports authentication of the client through various
means:
• By providing a username and a password
HP NonStop SSH Reference Manual SSH Protocol Reference • 243