This chapter takes you through the SSH for OpenVMS product installation procedure and certain post-installation tasks. It is for the OpenVMS system manager, administrator, or technician responsible for product installation.
To prepare for installation, see Chapter 1, Before You Begin.
Note! Once you have installed SSH for OpenVMS, you need to reinstall it after you have done a major OpenVMS upgrade.
To install SSH for OpenVMS:
1 Load the software.
2 Run the VMSINSTAL procedure.
3 Install other products, if needed, and perform post-installation tasks.
SSH for OpenVMS is shipped to you on CD-ROM media.
There are three steps to loading the SSH for OpenVMS software:
1 Log in to the system manager's account.
2 If SSH for OpenVMS is currently running, shut it down:
$ SSHCTRL SHUTDOWN
If you are installing on a VMScluster, shut down SSH for OpenVMS on each node in the cluster.
3 Physically load the distribution media onto the appropriate device.
• In a VMScluster environment, if you want to access the media from more than one node, enter the following:
$ MOUNT/CLUSTER/SYSTEM device SSH022
• On a standalone system, or if you want to prevent multiple users from accessing the software, enter the following:
$ MOUNT device SSH022
Note! If you install SSH for OpenVMS on a VMS cluster that has a common system disk, install the software on only one node in the cluster. If reinstalling or upgrading SSH for OpenVMS, first shut down SSH for OpenVMS on all nodes in the cluster.
Be sure to configure SSH for OpenVMS on all systems in a VMS cluster that has a common system disk, even though it only needs to be installed once.
VMSINSTAL is the OpenVMS installation program for layered products. VMSINSTAL prompts you for any information it needs. Table 2-1 shows the steps to follow.
|
Step |
For this task... |
Enter this response... |
|
1 |
Make sure that you are logged in to the system manager’s account, and invoke VMSINSTAL |
@SYS$UPDATE:VMSINSTAL |
|
2 |
Determine if you are satisfied with your system disk backup |
Return or Y (Yes) or N (No) |
|
3 |
Determine where the distribution volumes will be mounted |
The disk (and directory) where you want the software to be mounted. |
|
4 |
Enter the products you want processed from the first distribution volume set |
MULTINET051 (if installing on VAX or AXP) MULTINET_I64051 (if installing on I64) |
|
5 |
Enter the installation options you wish to use (such as obtaining the Release Notes) |
Return for no options or N for Release Notes. |
|
6 |
Specify the directory where you want the files installed. |
Return if accepting default of SYS$SYSDEVICE:[MULTINET] |
|
7 |
Specify the directory where you want the system-specific files installed |
Return if accepting default of [<nodename>];e.g, [ROSES] |
$ @sys$update:vmsinstal multinet051 dka600:[multinet051]
OpenVMS AXP Software Product Installation Procedure V7.3-2
It is 7-MAY-2005 at 13:24.
Enter a question mark (?) at any time for help.
%%VMSINSTAL-W-ACTIVE, The following processes are still active:
TCPIP$NTP_1
* Do you want to continue anyway [NO]? y
* Are you satisfied with the backup of your system disk [YES]?
The following products will be processed:
MULTINET V5.1
Beginning installation of MULTINET V5.1 at 13:24
%VMSINSTAL-I-RESTORE, Restoring product save set A ...
%VMSINSTAL-I-RELMOVED, Product's release notes have been moved to SYS$HELP.
* Where do you want to install SSH for OpenVMS [SYS$SYSDEVICE:[MULTINET]]:
* What do you want to call the system-specific directory [MYSYS]:
%VMSINSTAL-I-SYSDIR, This product creates system disk directory _MYSYS$DKA0:[MULTINET.MYSYS].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory _MYSYS$DKA0:[MULTINET.AXP_COMMON].
%VMSINSTAL-I-RESTORE, Restoring product save set Y ...
SSH for OpenVMS
MultiNet (R)
ALL RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES
This licensed material is the valuable property of Process Software.
Its use, duplication, or disclosure is subject to the restrictions set
forth in the License Agreement.
Other use, duplication or disclosure, unless expressly provided for in the license agreement, is unlawful.
Installing SSH for OpenVMS V2.2 Rev A
* Do you want to install the online documentation [YES]?
The HTML documentation requires 950 blocks.
* Do you want to install the HTML documentation [YES]?
The PDF documentation requires 2,260 blocks.
* Do you want to install the PDF documentation [YES]?
The SSH for OpenVMS software will be installed with these
selected components:
* Online documentation
- HTML Documentation
- PDF Documentation
* Would you like to change your selections [NO]?
* Do you want to purge files replaced by this installation [YES]?
* Configure SSH for OpenVMS after installation [NO]? y
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$COMMON_ROOT:[MULTINET].
The installation will now proceed with no further questions.
%VMSINSTAL-I-RESTORE, Restoring product save set 27 ...
%MULTINET-I-INSTALLING, Installing SSH for OpenVMS files
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$COMMON_ROOT:[MULTINET.PSCSSH].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH.LOG].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.HOSTKEYS].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.KNOWNHOSTS].
%MULTINET-I-CREATING, Creating SSH for OpenVMS startup file
*****************************************************************
* *
* *
* *
* To start SSH for OpenVMS, add the following line to your *
* *
* SYSTARTUP_VMS.COM file after you have configured SSH for *
* *
* OpenVMS: *
* *
* *
* $ @SYS$STARTUP:PSCSSH$STARTUP *
* *
* *
*****************************************************************
*%MULTINET-I-INSTALLING, Installing the online documentation files
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$SPECIFIC_ROOT:[MULTINET.PSCSSH.DOCUMENTS].
%VMSINSTAL-I-SYSDIR, This product creates system disk directory MU$COMMON_ROOT:[MULTINET.PSCSSH.DOCUMENTS].
%MULTINET-I-INSTALLING, Installing SSH for OpenVMS HELP library
%MULTINET-I-DELETING, Deleting obsolete MultiNet files
%VMSINSTAL-I-MOVEFILES, Files will now be moved to their target directories...
SSH for OpenVMS Version V2.2A 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 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]? y
Do you want to enable the SSH2 server [NO]? y
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 keygeneration when the SSHD_MASTER process is starting.
Enter the number of bits in the RSA key [768]:
You may specify an alternate configuration file for the SSH1 server. If you have already specified an alternate configuration 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 []:
You may specify an alternate configuration file for the SSH2 server. If you have already specified an alternate configuration 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 []:
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, 0]: 2
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 []:
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]:
You may specify the number of seconds a user has to enter a password during user authentication (default = 600). In addition, you may allow thisto 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]?
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]:
Do you want any messages logged by the SSH server at all [YES]?
Do you want verbose logging by the SSH server [NO]? y
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]:
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 will 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 record 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] y
Do you want to log rejected sessions [NO] y
You are currently logging to OPCOM.
Do you want to change the log file [NO]?
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]? y
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]? y
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]? y
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]?
What you want the minimum passphrase length to be for SSH2 [0-1024, 0]?
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 [YES]?
Initializing random number generator...
Generating p: .............++ (distance 154)
Generating q: ..++ (distance 34)
Generating q: ..............++ (distance 246)
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 35 13346338328257309153665734167613815548072936373049679049091856411472190787741770981682556387606408708693819476727190675152630004116939693143405091821528961962112264380896459652061811640073726834541585626906012629874599147047690547027366195251687737905227203091199516456022993413976084484441625719193392968523 DILBERT@mysys.whoknows.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 [YES]?
Generating 1024-bit dsa key pair
6 OOo.oOo.oOo.
Key generated.
1024-bit dsa, system@lima.bean.com, Fri May 07 2005 13:44:18
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 Guide before starting SSH.
Refer to the "Monitoring and Controlling SSH" chapter of the SSH for
OpenVMS Administration and User Guide for information on starting SSH.
Installation of MULTINET V5.1 completed at 13:45
Adding history entry in VMI$ROOT:[SYSUPD]VMSINSTAL.HISTORY
Creating installation data file: VMI$ROOT:[SYSUPD]MULTINET051.VMI_DATA
VMSINSTAL procedure done at 13:45
After installing SSH for OpenVMS on one node of a VMScluster with a common system disk, you must perform the following steps on each additional cluster node that shares the common system disk:
1 Log in (telnet/set host/etc.) to the next node of the cluster.
2 Create the MULTINET logicals by using the following command:
$ @SYS$STARTUP:PSCSSH$STARTUP LOGICALS
3 Make the node-specific SSH root and configure SSH for this node:
$ @MULTINET:SSH_MAKE_ROOT
4 Start SSH for OpenVMS:
$ @SYS$STARTUP:PSCSSH$STARTUP
5 Repeat steps 1-4 for each remaining node of the cluster except for the one where SSH was originally installed.
SSH for OpenVMS has no files which can be shared between cluster systems of different architectures.
