3. Configuring SSH for OpenVMS

 

This chapter describes how to configure the SSHD Master process, which controls access to the SSH servers for the SSH for OpenVMS software.

For a basic configuration, accept the default values for each component, which appear after a prompt. This also helps you step through the process more quickly.

After performing the basic configuration, you must perform the advanced configuration for the SSH1 and SSH2 servers, and for the SSH clients as desired. Chapters 4 through 7 describe the configuration and use of these components.

The SSH Configuration Utility

SSH is the Secure Shell protocol. SSH for OpenVMS provides support for both SSH Version 1 protocol and SSH Version 2 protocol.

Please note that in addition to the configuration performed via CNFSSH as described below, there are configuration files for both the SSH1/SSH2 servers and SSH client which must be modified as appropriate to meet the security requirements of your organization. Refer to chapters 4 and 5 of this manual for details on the configuration files.

You can use the CNFSSH utility to configure the SSH server as shown in the below example.

$ @MULTINET:CNFSSH CONFIGURE

 

SSH for OpenVMS Version V2.4A SSH Configuration procedure

 

This procedure helps you define the parameters needed to get SSH for OpenVMS running on this system.

 

This procedure creates the configuration data file,

MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH]SSH_CONFIGURE.COM,to reflect your system's configuration.

 

For detailed information on the following parameters, refer to the SSH for OpenVMS Administration and User’s Guide.

 

SSH for OpenVMS supports both SSH1 and SSH2 servers.  You may configure

SSH for OpenVMS to support either SSH1 servers or SSH2 servers, or both. Note that the choice of either or both servers has no impact on the SSH for OpenVMS client, which supports both SSH1 and SSH2 remote servers.

 

Do you want to enable the SSH1 server [NO]? YES

Do you want to enable the SSH2 server [NO]? YES

 

For SSH1, you must specify the number of bits in the RSA key.  The range is 512 to 32768 bits, but keys longer than 1024 are generally not much safer, and they significantly increase the amount of CPU time consumed by key generation when the SSHD_MASTER process is starting.

 

Enter the number of bits in the RSA key [768]: RETURN

 

You may specify an alternate configuration file for the SSH1 server. If you have already specified an alternate config file, enter a single space and hit RETURN at the prompt to reset it to the default file name. Enter an alternate SSH1 configuration filename []: RETURN

 

You may specify an alternate configuration file for the SSH2 server. If you have already specified an alternate config file, enter a single space and hit RETURN at the prompt to reset it to the default file name.

 

Enter an alternate SSH2 configuration filename []: RETURN

 

Specify the level of debug for the SSH1 and SSH2 servers.

 

For SSH1, any non-zero value will turn on debug, but there is no "degree of debug".

 

For SSH2, this is a value from 0 to 50, where zero is no debug and 50 is the maximum level of debug.  Note that at levels exceeding debug level 8,there may be a substantial impact on SSH2 server (and possibly, the system,too) performance due to the amount of information logged.

 

Enter the debug level [0 - 50]: RETURN

 

For SSH1, you may enter the name of an alternate RSA host key file.  If you have already specified an alternate host key file, enter a single space and hit RETURN at the prompt to reset it to the default file name.

 

Enter an alternate SSH1 public server host key file []: RETURN

 

Specify the time in seconds after which the server private key is generated. This is only done for SSH1 sessions.

 

Enter the key regeneration time [3600]: RETURN

 

You may specify the number of seconds a user has to enter a password during user authentication (default = 0).  In addition, you may allow this to default to the value used by OpenVMS when a user is logging into a non-SSH session.  To specify an infinite wait time, enter 0 for the timeout value.

 

Do you want to change the default login grace time [NO]? RETURN

 

Specify the address for the SSH server to listen on, if you wish to use an address other than the default listen_address of ANY (0.0.0.0).  Any valid IPV4 or IPV6 address may be specified, or ANY to listen on all addresses.

 

Enter address to listen on [ANY]: RETURN

 

Specify the port for the SSH server to listen on, if you wish to use a port other than the default port of 22.

 

Enter port to use [22]: RETURN

Do you want any messages logged by the SSH server at all [YES]? RETURN

Do you want verbose logging by the SSH server [NO]? RETURN

 

You may specify the maximum number of concurrent SSH sessions to be allowed on the server.  This is the total of both SSH1 and SSH2 sessions. The default is 1000 sessions.

 

Enter maximum number of concurrent SSH sessions [1-1000, 1000]: RETURN

 

In OpenVMS, users with passwords that have expired because the SYSUAF PWDLIFETIME value has been exceeded are allowed to log into the system, and are then forced to change their password.  The SSH1 protocol does not allow for that condition.  Answer "YES" to the following question if you wish to allow users with expired passwords to still log into the system.  They WILL NOT be forced to change their password.

 

Note that the SSH2 protocol is not restricted as the SSH1 protocol is; changing of expired passwords, save for pre-generated passwords, is performed by many SSH2 clients (including the SSH for OpenVMS client).

 

Do you want to allow users with expired passwords to log in [NO]? RETURN

 

In OpenVMS, users with passwords that have been pre-expired by the system manager are allowed to log into the system, and are then forced to change their password.  The SSH1 protocol does not allow for that condition.  Answer "YES" to the following question if you wish to allow users with pre-expired passwords to still log into the system.  They WILL NOT be forced to change their password.

 

Note that the SSH2 protocol is not restricted as the SSH1 protocol is;

changing of expired passwords, save for pre-generated passwords, is performed by many SSH2 clients (including the SSH for OpenVMS client).

 

Do you want to allow users with preexpired passwords to log in [NO]? RETURN

 

The SSH1 protocol does not permit the display of the contents of the SYS$ANNOUNCE logical or file prior to a user logging in.  Answering "Y" to the next question will cause the SSH for OpenVMS client to display the contents of SYS$ANNOUNCE after user authentication is completed but before the contents of SYS$WELCOME are displayed.

 

Do you want to display SYS$ANNOUNCE [NO]? RETURN

 

When generating user keys, a passphrase may be used to further protect the key.  No limit is normally enforced for the length of the passphrase. However, you may specify a minimum length the passphrase may be.

 

What you want the minimum passphrase length to be for SSH1 [0-1024, 0]? RETURN

What you want the minimum passphrase length to be for SSH2 [0-1024, 0]? RETURN

 

You may permit the server to log a brief informational message when a user is allowed or denied access to a system.

 

-For SSH1 connections, an ACCEPT or REJECT event will be simply dependent upon if a user could connect based on the ALLOWGROUP/DENYGROUP settings in the configuration file SSH_DIR:SSHD_CONFIG. The message should be of the form:

 

<date><time>SSH1(accepted)from [192.168.0.1,111)(my.server.com)

 

-For SSH2 sessions, an ACCEPT or REJECT event will be logged when the user is either successfully authenticated or fails authentication. The message will be of the form:

 

<date><time>SSH2(accepted)from user "foo" at [192.168.0.1,111]

(my.server.com)

 

You may specify the name and location of the log file to log accepted and/or rejected connections. If you simply hit RETURN, this information will be logged to OPCOM as opposed to a disk file.

 

By default, this file will be in the SSH_DIR: directory. You may override this by specifying a complete filename, including the directory specification; or by specifying a logical name that translates to a full filename specification.

 

Do you want to log accepted sessions [NO]? YES

Do you want to log rejected sessions [NO]? YES

You are currently logging to OPCOM.

 

Do you want to change the log file? NO

Enter the name of the log file (RETURN = log to OPCOM):

 

The SSH1 host key has not yet been generated.  Answer YES to the following question to generate the key now.  Answer NO to generate the key manually later by issuing the command:

 

    $ MULTINET SSHKEYGEN /SSH1/HOST

 

Generating a host key can take a few minutes on slow systems.

Do you want to generate the SSH1 host key now [Y]? RETURN

Initializing random number generator...

Generating p:  .................++ (distance 238)

Generating q:  ......................................................++

(distance 842) Computing the keys...

Testing the keys...

Key generation complete.

Key file will be MULTINET_ROOT:[MULTINET.PSCSSH.SSH]SSH_HOST_KEY.

Your identification has been saved in

MULTINET_ROOT:[MULTINET.PSCSSH.SSH]SSH_HOST_KEY..

Your public key is:

1024 33

158219526854708373223273549671898538484019382056540756180743251896008268

483672249192572320679336191637197647931252468484924742381769192752175522

804079403652395183296863957945714446720630016910346731983816732024731068

303384286498131699887049314519433804844962219668666235774358798424562229

SYSTEM@rose.example.com

Your public key has been saved in

MULTINET_ROOT:[MULTINET.PSCSSH.SSH]SSH_HOST_KEY.pub

 

The SSH2 host key has not yet been generated.  Answer YES to the following question to generate the key now.  Answer NO to generate the key manually later by issuing the command:

 

    $ MULTINET SSHKEYGEN /SSH2/HOST

 

Generating a host key can take a few minutes on slow systems.

 

Do you want to generate the SSH2 host key now [Y]? RETURN

Generating 1024-bit dsa key pair

    3 o.oOo.oOo.oo Key generated.

1024-bit dsa, dilbert@rose.example.com, Thu Mar 04 2022 08:21:41

Private key saved to multinet_ssh2_hostkey_dir:hostkey.

Public key saved to multinet_ssh2_hostkey_dir:hostkey.pub

 

SSH Configuration completed.

 

Review the additional steps you may need to perform as described in the configuration chapters of the SSH for OpenVMS Administration and User’s Guide before starting SSH.

 

Refer to the "Monitoring and Controlling SSH" chapter of the SSH for OpenVMS Administration and User’s Guide for information on starting SSH.