HP TCP/IP Services for OpenVMS Guide to SSH |
Customizing the SSH Run-Time Environment |
|
|
| |
Customizing an Authentication Method
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:
AllowedAuthentications keyword must contain the word password (or omit the line). For example:AllowedAuthentications passwordPasswordGuesses keyword in this configuration file. For example: PasswordGuesses 4Customizing
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:
AllowedAuthentications to include the word hostbased. For example: AllowedAuthentications hostbasedDefaultDomain to be the fully qualified domain name for the local host.
For example, if the fully qualified domain name for the local host
is color.art.com:DefaultDomain color.art.comCustomizing
Host-Based Authentication on the Server ![]()
Set the value of AllowedAuthentications to include the word hostbased. For example: AllowedAuthentications hostbased IgnoreRhosts keyword to no. For example: IgnoreRhosts nono is the default, it can also be left commented out, as
in #IgnoreRhosts no. Note that this parameter applies to both the RHOSTS.
and SHOSTS file.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. 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)
Customizing
Public-Key Authentication ![]()
Public-key authentication requires the following configuration
actions on both sides of the connection: client and server hosts.
To install keys, you need two files:
username.SSH2]IDENTIFICATION, which identifies your private-key
file.username.SSH2]AUTHORIZATION, which contains information about
all public keys (the names of the corresponding files) that can
be used by remote clients to identify themselves to the server.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 ![]()
AllowedAuthentications keyword to include word publickey. For example:AllowedAuthentications publickey, passwordusername.SSH2], if one does not exist. SSH_KEYGEN utility, as described in Chapter 5 . This action creates
the public private key files:username.SSH2]ID_DSA_1024_A. contains your private key, which
you must protect so that only you can access it. To protect the
file, use the DCL command SET FILE/PROTECTION. For example:$ SET FILE/PROTECTION=(S,W,G,O:RW) ID_DSA_1024_A.[username.SSH2]ID_DSA_1024_A.PUB contains your public key, which you can copy to other
hosts. Ensure that this file is available for world read access.-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.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:IdKeyMEUSER-MYHOST_MYDOMAIN_COMCustomizing
Public-Key Authentication on the Server ![]()
AllowedAuthentications keyword in the server configuration file to include the word
publickey. For example: AllowedAuthentications publickey[username.SSH2] (if one does not exist). KEY username-hostname.PUB MEUSER-MYHOST_MYDOMAIN_COM.Add this line to the AUTHORIZATION file:KEY MEUSER-MYHOST_MYDOMAIN_COM.PUBusername.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.
|
|