skip book previous and next navigation links
go up to top of book: HP TCP/IP Services for OpenVMS Guide to SSH HP TCP/IP Services for OpenVMS Guide to SSH
go to beginning of chapter: Customizing the SSH Run-Time Environment Customizing the SSH Run-Time Environment
go to previous page: Authentication Methods Authentication Methods
go to next page: Managing the SSH ServiceManaging the SSH Service
end of book navigation links

Customizing an Authentication Method 



The type of authentication that the SSH client uses is specified by assigning values to the AllowedAuthentications keyword in the client configuration file SSH2_CONFIG. The client tries user authentication methods in the order in which they are listed for the AllowedAuthentications keyword. For example, if hostbased is listed first, the SSH server tries hostbased authentication first.

On the SSH server host, the order in which the authentication methods are listed is not important. On the SSH client, the order is the defining factor. For example, the client lists the following:

AllowedAuthentications hostbased,publickey,password

In this case, the server tries each method in turn (first host based, then public key, then password) and uses the first successful authentication.

If the AllowedAuthentications keyword is missing or has no entries, the server tries the public-key authentication method first, and then the password authentication method. In this case, host-based authentication is not tried.

Customizing Password Authentication 

Password authentication requires only that you set parameters in the SSH client host and server host configuration files. No additional files are required. Password authentication is the default.

Customizing Password Authentication on the Client 

Set the value of the AllowedAuthentications keyword to include the word password (or omit the line). For example:

AllowedAuthentications password

Customizing Password Authentication on the Server 

Set the following:

  1. The value of the AllowedAuthentications keyword must contain the word password (or omit the line). For example:

    AllowedAuthentications password
  2. You can define the number of password attempts allowed by assigning a numeric value to the PasswordGuesses keyword in this configuration file. For example:

    PasswordGuesses 4

    The default is three password attempts.

Customizing Host-Based Authentication 

Host-based authentication requires configuration actions on both client and server hosts.

Customizing Host-Based Authentication on the Client  

Set the value of the following keywords:

Customizing Host-Based Authentication on the Server 

  1. Edit the server configuration file as follows:
  2. Edit the systemwide trusted hosts file, TCPIP$SSH_DEVICE:[TCPIP$SSH]SHOSTS.EQUIV, to add the fully qualified name of every SSH client host that will communicate with the server. You can also enter a specific user name to limit access to that user. For example:MYHOST.MYLAB.COMorMYHOST.MYLAB.COM smithIf the IgnoreRhosts parameter is set to no as in step 1, you can also add the client host and optional user names to the file SYS$LOGIN:SHOSTS. for a specific user.

    If user names are used, those associated with OpenVMS client hosts must be in lowercase; those associated wih UNIX client hosts must match the account name case as it exists on the UNIX host.
  3. In host-based authentication, the client and server hosts authenticate each other. Therefore, the server host must have the client's host public key. Copy the client's host public-key file, CLIENTHOST::TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]HOSTKEY.PUB, to the server directory SERVERHOST::TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2.KNOWNHOSTS], naming the key file name, using the format fully-qualified-hostname_ssh-dss.pub. For example, if the host name is green and its domain name is color.art.com, copy it as follows:
    $COPY SYS$LOGIN:[SSH2.KNOWNHOSTS]green_color_art_com_ssh-dss.pub -
    _$ SERVERHOST::TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2.KNOWNHOSTS]- 
    _$ green_color_art_com_ssh-dss.pub/PROTECTION=(W=RE) 
  4. If you want your own version of the host public key files (in addition to the systemwide file specified in step 3), copy the file into your [username.SSH2.KNOWNHOSTS] directory. If the same file exists in both directories, the SSH server uses the user-specific key-name file in your user directory.

Customizing Public-Key Authentication 

Public-key authentication requires the following configuration actions on both sides of the connection: client and server hosts.

  1. Create public/private key pairs on the client host. For more information, see the section Customizing Public-Key Authentication on the Client.
  2. Install your public key in your accounts on all server hosts to which you want to connect. Your user account on each server host might have many public keys for accessing it in different ways.

To install keys, you need two files:

Both are ASCII text files that contain keywords and assigned values. These files are parsed by the client and the server, allowing each server host to identify the public key of the user who is connecting to the server. The following two sections describe the steps you should perform.

Customizing Public-Key Authentication on the Client  

  1. Edit the client configuration file by setting the value of the AllowedAuthentications keyword to include word publickey. For example:

    AllowedAuthentications publickey, password
  2. Create the subdirectory [ username.SSH2], if one does not exist.
  3. From the user account, run the SSH_KEYGEN utility, as described in Chapter 5 . This action creates the public private key files: These file names are generated by default if you do not specify a file name with the SSH_KEYGEN utility. This default name includes identification of the default key generation algorithm, which is usually DSA (Digital Signature Algorithm) or RSA (Rivest, Shamir, and Adleman). Note that DSA is the default on OpenVMS; RSA is an option.

    The SSH_KEYGEN command allows specification of a custom key name (and, optionally, suppression of the passphrase with the -P flag). Also, you can rename these files for convenience. For example, if multiple keys are necessary, the public key to be used with a particular SSH server host can be renamed to file names in the format: username-serverhostname.PUB (public key) and username-serverhostname. (private key). Using this convention makes it easier to copy designated public key files to the appropriate server hosts.

    The examples in step 4 assume that the public and private key files have been either generated as or renamed to the file MEUSER-MYHOST_MYDOMAIN_COM.*.
  4. Create a file called [username.SSH2]IDENTIFICATION. and add a line that identifies the name of your private key. For example, if this key file name were used:

    MEUSER-MYHOST_MYDOMAIN_COM.

    This line would be added:IdKeyMEUSER-MYHOST_MYDOMAIN_COM

Customizing Public-Key Authentication on the Server 

  1. Set the value of the AllowedAuthentications keyword in the server configuration file to include the word publickey. For example:

    AllowedAuthentications publickey
  2. Create the subdirectory [username.SSH2] (if one does not exist).
  3. Create the file [username.SSH2]AUTHORIZATION.
  4. Add entries in the [username.SSH2]AUTHORIZATION file as necessary. Each entry is a single line that identifies the user's client public key file name. The format of the entry is: KEY username-hostname.PUB

    For example, if the user's public key file name is:MEUSER-MYHOST_MYDOMAIN_COM.Add this line to the AUTHORIZATION file:

    KEY MEUSER-MYHOST_MYDOMAIN_COM.PUB
  5. To authenticate you as the user, the server host must access the public key file, which you created on the client host. For more information about public keys on the client, see Customizing Public-Key Authentication on the Client. Copy this file to your account directory on the server host [username.SSH2] as username-hostname.PUB. Note that the file name must be the same as the one listed on the line with the keyword KEY.

go to previous page: Authentication Methods Authentication Methods
go to next page: Managing the SSH ServiceManaging the SSH Service