HP-UX Secure Shell Getting Started Guide HP-UX 11i v1, HP-UX 11i v2, and HP-UX 11i v3 (5900-3142, June 2013)

Instead, the server directly reads the user ID and password from the /etc/passwd file. For more
information on the UsePAM directive, see Appendix A (page 63).
Public-Key Authentication
HP-UX Secure Shell uses public-key authentication for strong and secure authentication. Public-key
authentication enables users to connect to a remote server without sending their password over
the network. In this type of authentication, a client system needs a private key and a passphrase
to authenticate itself to the server.
Public-key authentication uses the following types of keys (referred to as a key pair or an asymmetric
key pair):
• Private key – A private key can be used only by its owner and must not be revealed to others.
It can be encrypted with a passphrase to give it an extra layer of security.
• Public key – The public key is placed on the remote server to which users attempt to access.
Following are the important features of a key pair:
• The key pair is asymmetric. Messages encrypted with a public key can be decrypted only by
the matching private key of the pair. Similarly, messages encrypted with a private key can
be decrypted only by the matching public key of the pair.
• It is impossible to derive the private key using the matching public key.
To send a secure message to the server, the client must encrypt the message using the public key
and send the encrypted message over the network. The encrypted message can be decrypted only
by the owner of the matching private key. This enables the client to prove its identity to the server.
Public-key authentication is more secure than password-based authentication.
Following are the steps used in public-key authentication when the server authenticates the client:
1. The server generates a key pair, which includes the public key and the private key.
2. The server shares the public key with the client by copying the public key into the appropriate
directory on the client.
3. The client encrypts a message with the server’s public key.
4. The client sends the encrypted message to the server.
Following are the steps used in public-key authentication when the client authenticates the server:
1. The server encrypts a message using its private key.
2. The server sends the encrypted message and the clear-text message to the client. A clear text
message is a unencrypted message.
3. The client decrypts the encrypted message with the server’s public key and matches the
decrypted message with the clear-text message. If the keys match, the client accepts the server’s
identity.
Table 10 lists the default public key and private key file names generated for different key formats,
and their default locations on the client.
Table 10 Key File Name for RSA and DSA Key Format
Public KeyPrivate KeyKey Format
$HOME/.ssh/identity.pub$HOME/.ssh/identityRSA-1
$HOME/.ssh/id_rsa.pub$HOME/.ssh/id_rsaRSA
$HOME/.ssh/id_dsa.pub$HOME/.ssh/id_dsaDSA
$HOME/.ssh/id_ecdsa.pub$HOME/.ssh/id_ecdsaECDSA
The SSH-1 protocol supports only the RSA-1 algorithm. The SSH-2 protocol supports RSA, RSA1,
DSA, and ECDSA algorithms. You can generate an RSA key pair, a DSA key pair, and an ECDSA
Public-Key Authentication 27