Setting Up Host-based Authentication
» Table of Contents |  |  | » Glossary | | | » Index | | |
| | |
| ||
| ||
Host-based authentication requires configuration actions on both client and server hosts.
Set the following configuration parameters:
Specify the value of the AllowedAuthentications parameter to include the word hostbased. For example:
AllowedAuthentications hostbased
Specify the value of the DefaultDomain keyword 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, enter the following:
DefaultDomain color.art.com
Edit the server configuration file as follows:
Set the value of the AllowedAuthentications parameter to include the word hostbased. For example:
AllowedAuthentications hostbased
To enable use of the user-specific SHOSTS. files, set the value of the IgnoreRhosts parameter to no. For example:
IgnoreRhosts no
Because no is the default, the parameter can also be commented out, as follows:
#IgnoreRhosts no
If the IgnoreRhosts parameter is set to no, the SSH server looks up the host name in the user-specific SHOSTS. file. If this parameter is set to yes, the host name is assumed to be in the systemwide SHOSTS.EQUIV fle. See Appendix B for more information.
Edit the systemwide trusted hosts file, TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]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.COM
or
MYHOST.MYLAB.COM smith
If the IgnoreRhosts parameter is set to no, 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.
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]). Name the key file name using the following format:
fully-qualified-hostname_ ssh-dss.pub.
Specify the proper protection for the new file using the /PROTECTION=W=RE qualifier to the COPY command. Without the proper protection, host-based authentication will not work.
For example, if the host name is green and its domain name is color.art.com, copy the client's host public-key file 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)
If you want your own version of the host public key files in addition to the systemwide file, 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.