4. Configuring the Secure Shell (SSH) v1 Server
This chapter describes how to configure and maintain the SSH for OpenVMS Secure Shell (SSH) v1 server.
This is the server side of the software that allows secure interactive connections to other computers. The SSH server has been developed to discriminate between SSH v1 and SSH v2 protocols, so the two protocols can coexist simultaneously on the same system.
SSH1 and SSH2 Differences
SSH1 and SSH2 are different, and incompatible, protocols. The SSH1 implementation is based on the V1.5 protocol, and the SSH2 implementation is based on the V2 protocol. While SSH2 is generally regarded to be more secure than SSH1, both protocols are offered by SSH for OpenVMS, and although they are incompatible, they may exist simultaneously on an OpenVMS system. The SSH for OpenVMS server front-end identifies what protocol a client desires to use, and will create an appropriate server for that client.
|
Note: You must install the DEC C 6.0 backport library on all OpenVMS VAX v5.5-2 and v6.0 systems prior to using SSH. This is the AACRT060.A file. You can find the ECO on the SSH for OpenVMS CD in the following directory: VAX55_DECC_RTL.DIR.
|
Restrictions:
When using SSH1 to connect to a VMS server, if the VMS account is set up with a secondary password, SSH1 does not prompt the user for the secondary password. If the VMS primary password entered is valid, the user is logged in, bypassing the secondary password.
When using SSH1 to execute single commands (in the same manner as RSHELL), some keystrokes like CTRL+Y are ignored. In addition, some interactive programs such as HELP may not function as expected. This is a restriction of SSH1. If this behavior poses a problem, log into the remote system using SSH1 in interactive mode to execute the program.
Understanding the Secure Shell Server
Secure Shell daemon (SSHD) is the daemon program for SSH that listens for connections from clients. The server program replaces rshell and telnet programs. The server/client programs provide secure encrypted communications between two untrusted hosts over an insecure network. A new daemon is created for each incoming connection. These daemons handle key exchange, encryption, authentication, command execution, and data exchange.
Servers and Clients
A SSH server is an OpenVMS system server that acts as a host for executing interactive commands or for conducting an interactive session. The server software consists of two processes (for future reference, “SSHD” will refer to both SSHD_MASTER and SSHD, unless otherwise specified):
· SSHD_MASTER, recognizes the differences between SSH v1 and SSH v2 and starts the appropriate server. If the request is for SSH v1, then a new SSH v1 server is run; if the request is for SSH v2, then a new SSH v2 server is run.
· SSHD, a copy of which is spawned for each time a new connection attempt is made from a client. SSHD handles all the interaction with the SSH client.
A client is any system that accesses the server. A client program (SSH) is provided, but any SSH client that uses SSH version 1 protocol may be used to access the server. Examples of such programs are FISSH, MultiNet SSH, and TCPware SSH on OpenVMS systems; TTSSH, SecureCRT, F-Secure SSH Client, and PuTTY on Windows-based systems; and other SSH programs such as OpenSSH on UNIX-based systems.
Security
Each host has a host-specific RSA key (normally 1024 bits) that identifies the host. Additionally, when the SSHD daemon starts, it generates a server RSA key (normally 768 bits). This key is regenerated every hour (the time may be changed in the configuration file) if it has been used and is never stored on disk. Whenever a client connects to the SSHD daemon,
· SSHD sends its host and server public keys to the client.
· The client compares the host key against its own database to verify that it has not changed.
· The client generates a 256 bit random number. It encrypts this random number using both the host key and the server key, and sends the encrypted number to the server.
· The client and the server start to use this random number as a session key which is used to encrypt all further communications in the session.
The rest of the session is encrypted using a conventional cipher. Currently, IDEA (the default), DES, 3DES, Blowfish, and ARCFOUR are supported.
· The client selects the encryption algorithm to use from those offered by the server.
· The server and the client enter an authentication dialog.
· The client tries to authenticate itself using any of the following methods:
o .rhosts authentication
o .rhosts authentication combined with RSA host authentication
o RSA challenge-response authentication
o password-based authentication
|
Note: RHOSTS authentication is normally disabled because it is fundamentally insecure, but can be enabled in the server configuration file, if desired.
|
System security is not improved unless the RLOGIN and RSHELL
services are disabled. When the client authenticates itself successfully, a
dialog is entered for preparing the session. At this time the client may
request things such as: 
· forwarding X11 connections
· forwarding TCP/IP connections
· forwarding the authentication agent connection over the secure channel
Finally, the client either requests an interactive session or execution of a command. The client and the server enter session mode. In this mode, either the client or the server may send data at any time, and such data is forwarded to/from the virtual terminal or command on the server side, and the user terminal in the client side. When the user program terminates and all forwarded X11 and other connections have been closed, the server sends command exit status to the client, and both sides exit.
Break-in and Intrusion Detection
Care must be exercised when configuring the SSH clients and server to minimize problems due to intrusion records created by OpenVMS security auditing. The SSH user should consult the system manager to determine the authentication methods offered by the SSH server. The client should then be configured to not attempt any authentication method that is not offered by the server.
If a client attempts authentication methods not offered by the server, the OpenVMS security auditing system may log several intrusion records for each attempt to create a session to that server. The result being that the user could be locked out and prevented from accessing the server system without intervention from the server's system manager.
The authentication methods to be offered by the server are determined by the configuration keywords RhostsAuthentication, RhostsRSAAuthentication, RSAAuthentication, and PasswordAuthentication. The number of intrusion records to be logged for any attempted SSH session is determined by the StrictIntrusionLogging configuration keyword.
When StrictIntrusionLogging is set to YES (the default), each method that is tried and fails causes an intrusion record to be logged:
· When Rhosts, RhostsRSA or RSA authentications are attempted and fail, one intrusion record will be logged for each failed method.
· When password authentication is attempted, one intrusion record will be logged for each failed password.
Example 1
The server is set up to allow Rhosts, RSA, and password authentication; also, up to three password attempts are allowed. If all methods fail, five intrusion records are logged:
1 for the failed Rhosts
1 for the failed RSA
3 for the failed password attempts, one per attempt
When StrictIntrusionLogging is set to NO, it has the effect of relaxing the number of intrusions logged. Overall failure of all authentication methods simply counts as a single failure, except for password authentication. The following rules apply:
· When password authentication is attempted, one intrusion record is logged for each failed password.
· When any of Rhosts, RhostsRSA, or RSA authentication fails, and password authentication is not attempted, exactly one intrusion record is logged, as opposed to one for each failed method.
· When any of Rhosts, RhostsRSA, or RSA authentication fails, but password authentication is attempted and succeeds, the only intrusion record(s) logged is one for each failed password attempt.
Example 2
The server is set up to allow Rhosts, RSA, and password authentication; also, up to three password attempts are allowed. If all methods fail, three intrusion records are logged:
0 for the failed Rhosts
0 for the failed RSA
3 for the failed password attempts, one per attempt
Example 3
The server is set up to allow Rhosts, RSA, and password authentication; also, up to three password attempts are allowed. Rhosts and RSA fail, but password authentication is successful after 1 failed password. Therefore, one intrusion record is logged:
0 for the failed Rhosts
0 for the failed RSA
1 for the failed password attempt
Example 4
The server is set up to allow Rhosts, RhostsRSA, and RSA authentication, but not password authentication. If all methods fail, one intrusion record is logged.
Example 5
The server is set up to allow Rhosts, RhostsRSA, and RSA authentication, but not password authentication. Rhosts and RSA authentication both fail, but RhostsRSA succeeds. No intrusion records are logged.
Expired Passwords
The SSH v1 protocol does not provide a method for changing an expired VMS password. When an expired password is encountered by the SSH1 server, it will do one of two things.
1.
If the logical
name MULTINET_SSH_ALLOW_EXPIRED_PW is defined for
allowing access for passwords that have exceeded the UAF value for PWDLIFETIME, or if the logical name MULTINET_SSH_ALLOW_PREEXPIRED_PW
is defined for allowing access for users that have a pre-expired password, the
server will allow the user to log in. In the logical name table LNM$SSH_LOGICALS, the logical name MULTINET_SSH_pid_PWDEXP (where pid is the
process ID for the user process) will be defined. The system manager can look for this logical to be defined, and if so, take action such as executing the DCL SET PASSWORD command.
2. If the appropriate logical is not set as described above, the user will be denied access to the system. In that case, the user must log in interactively via another mechanism such as telnet and change the password, or the system manager must reset the password.
When a user is allowed access to the system with an expired password, the LOGIN_FLAGS for the process will reflect this. The values of the LOGIN_FLAGS will be as follows:
· new mail has been received (JPI$M_NEW_MAIL_AT_LOGIN)
· the password is about to expire (JPI$M_PASSWORD_WARNING)
· the password has expired (JPI$M_PASSWORD_EXPIRED)
The DCL lexical function F$GETJPI may be used to examine these flags, as can the $GETJPI(W) system service or LIB$GETJPI RTL function. When an expired password value is detected, the user may then execute a SET PASSWORD command in the command procedure run for the account.
For example:
$!
$! Login_flags:
$! 1 = new mail messages waiting (JPI$M_NEW_MAIL_AT_LOGIN)
$! 4 = password expired during login (JPI$M_PASSWORD_EXPIRED)
$! 5 = password expires within 5 days (JPI$M_PASSWORD_WARNING)
$!
$ flags = f$getjpi("", "LOGIN_FLAGS")
$ new_flags = (flags/2)*2
$ if new_flags .ne. flags then write sys$output "New mail waiting"
$!
$!Note - new_flags is used below because it has the NEW_MAIL_AT_LOGIN$
$! bit stripped. The rest of the possible values are all
$! discrete; i.e., you can't have combinations of them at the
$! same time.
$!
$ if new_flags .eq. 4 then write sys$output "Password expired during login"
$ if new_flags .eq. 5 then write sys$output "Password expires within 5 days"
$!
Configuration File
SSHD reads configuration data from MULTINET:SSHD_CONFIG. The file contains keyword value pairs, one per line. The following keywords are possible. Keywords are case insensitive
|
Keyword |
Value |
Default |
Description |
|
AllowForwardingPort |
Port list |
|
Permit forwarding for the specified ports |
|
AllowForwardingTo |
Host/port list |
|
Permit forwarding for hosts |
|
AllowGroups |
List |
|
Access control by UAF rights list entries |
|
AllowHosts |
Host list |
|
Access control by hostname |
|
AllowShosts |
Host list |
|
Access control by hostname |
|
AllowTcpForwarding |
Y/N |
Y |
Enable TCP port forwarding |
|
AllowUsers |
User list |
|
Access control by username |
|
DenyForwardingPort |
Port list |
|
Forbid forwarding for ports |
|
DenyForwardingTo |
Host/port list |
|
Forbid forwarding for hosts |
|
DenyGroups |
Rights list |
|
Deny access for UAF rightslist identifiers |
|
DenyHosts |
Host list |
|
Deny access for hosts |
|
DenySHosts |
Host list |
|
Deny access for hosts |
|
DenyUsers |
User list |
|
Access control by username |
|
FascistLogging |
Y/N |
Y |
Verbose logging |
|
Hostkey |
Filename |
Ssh_host_key. |
Host key filename |
|
IdleTimeout |
Time |
0 (infinite) |
Set idle timeout |
|
IgnoreRhosts |
Y/N |
N |
Ignore local rhosts |
|
IgnoreRootRhosts |
Y/N |
Y |
Ignore system rhosts |
|
KeepAlive |
Y/N |
Y |
Send keepalives |
|
ListenAddress |
IP address |
0.0.0.0 |
Listen on given interface |
|
LoginGraceTime |
Time |
600 |
Time limit for authentication in seconds |
|
PasswordAuthentication |
Y/N |
Y |
Permit password authentication |
|
PermitEmptyPasswords |
Y/N |
N |
Permit empty (blank) passwords |
|
PermitRootLogin |
Y/N |
N |
SYSTEM can log in |
|
QuietMode |
Y/N |
N |
Quiet mode |
|
RandomSeed |
Filename |
Random_seed |
Random seed file |
|
RhostsAuthentication |
Y/N |
N |
Enable rhosts authentication |
|
RhostsRSAAuthentication |
Y/N |
Y |
Enable rhosts with RSA authentication |
|
RSAAuthentication |
Y/N |
Y |
Enable RSA authentication |
|
StrictIntrusionLogging |
Y/N |
Y |
Determine how intrusion records are created by failed authentication attempts |
|
StrictModes |
Y/N |
N |
Strict checking for directory and file protection |
|
SyslogFacility |
Syslog level |
“DAEMON” |
Syslog log facility |
|
VerboseLogging |
Y/N |
Y |
Verbose logging (also known as FacistLogging) |
|
X11Forwarding |
Y/N |
Y |
Enable X11 forwarding |
|
X11DisplayOffset |
#offset |
10 |
Limit X displays for SSH |
Starting the SSH Server for the First Time
Follow these instructions to configure the SSH server. You must define the MULTINET logicals by using:
$ @SYS$STARTUP:PSCSSH$STARTUP LOGICALS
1. Use the CNFSSH utility to configure the SSH server. It is recommended that the host keys be generated when executing the CNFSSH procedure, by answering Y to the question “Do you want to generate the SSH1 host key now?”
2. Use SSHKEYGEN to create the file SSH_HOST_KEY in the SSH_DIR: directory if it has not been created as a result of executing @MULTINET:CNFSSH CONFIGURE.
$ MULTINET SSHKEYGEN/SSH1/HOST
Initializing random number generator...
Generating p: ...++ (distance 64)
Generating q: .......................................++ (distance 516) 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 37
1210318365576698697865367869291969476388228444969905611864276308
9072776904462744415966821020109463617644202397294642277946718549
4404442577594868297087171013359743853182442579923801302020844011
5343754909847513973160249324735913146330232410424936751015953611
18716872491123857940537322891584850459319961275605927
SYSTEM@gg1.prr.com
Your public key has been saved in
MULTINET_ROOT:[MULTINET.PSCSSH.SSH]SSH_HOST_KEY.PUB
3. Edit the default configuration file at SSH_DIR:SSHD_CONFIG (if you wish to change the default settings). This default configuration is the same as contained in the file MULTINET:SSHD_CONFIG.TEMPLATE.
|
Note: As delivered, the template file provides a reasonably secure SSH environment. However, Process Software recommends this file be examined and modified appropriately to reflect the security policies of your organization.
|
4. Restart SSH. This creates the SSH server process and defines the SSH logical names.
$ SSHCTRL RESTART
$ SHOW PROCESS "SSHD Master"
7-MAR-2022 09:03:06.42 User: SYSTEM Process ID: 00000057
Node: PANTHR Process name: "SSHD Master"
Terminal:
User Identifier: [SYSTEM]
Base priority: 4
Default file spec: Not available
Number of Kthreads: 1
Devices allocated: BG1:
BG2:
$ SHOW LOGICAL/SYSTEM SSH*
(LNM$SYSTEM_TABLE)
"SSH_DIR" = "MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH]"
"SSH_EXE" = "MULTINET_COMMON_ROOT:[MULTINET.PSCSSH.SSH]"
"SSH_LOG" = "MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.LOG]"
"SSH_MAX_SESSIONS" = "100"
"SSH_TERM_MBX" = "MBA36:"
Changing the SSH1 Configuration File After Enabling SSH1
If you make a change to the SSH1 configuration file after you have enabled SSH1, you must restart SSH for these changes to take effect.
$ SSHCTRL RESTART
|
Note: When issuing the RESTART command for SSH, all active SSH server sessions are terminated. Active client sessions are not affected.
|
Connection and Login Process
To create a session, SSHD does the following:
1. SSHD_MASTER process sees the connection attempt. It creates an SSHD v1 or v2 process, depending on the protocol version presented to it by the client. SSHD_MASTER then passes necessary information to the SSHD process, such as the server key and other operating parameters.
2. SSHD process performs validation for the user.
3. Assuming the login is successful, SSHD process creates a pseudoterminal for the user (an FTAnn: device). This device is owned by the user logging in.
4. SSHD process creates an interactive process on the pseudoterminal, using the username, priority, and privileges of the user logging in. If a command was specified, it is executed and the session is terminated.
5. SSH generates the file SSHD.LOG in the directory MULTINET_ROOT:[MULTINET.SSH] for each connection to the SSH server. Many connections result in many log files. Instead of purging the files on a regular basis, use the following DCL command to limit the number of versions:
$ SET FILE /VERSION_LIMIT=x MULTINET_ROOT:[MULTINET.SSH]SSHD.LOG
|
Note: The value for /VERSION_LIMIT must not be smaller than the maximum number of simultaneous SSH sessions anticipated. If the value is smaller, SSH users may be prevented from establishing sessions with the server.
|
FILES
MULTINET:HOSTS.EQUIV
Contains host names, one per line. This file is used during .rhosts authentication. Users on those hosts are permitted to log in without a password, provided they have the same username on both machines. The hostname may also be followed by a username. Such users are permitted to log in as any user on the remote machine (except SYSTEM). Additionally, the syntax +@group can be used to specify netgroups. Negated entries start with a dash (-). If the client host/user is matched in this file, login is permitted provided the client and server usernames are the same. Successful RSA host authentication is required. This file should be world-readable but writeable only by SYSTEM.
It is never a good idea to use usernames in hosts.equiv. It means the named user(s) can log in as anybody, which includes accounts that own critical programs and directories. Using a username grants the user SYSTEM access. The only valid use for usernames is in negative entries.
MULTINET:SHOSTS.EQUIV
Processed as MULTINET:HOSTS.EQUIV. May be useful in environments that want to run both rshell/rlogin and ssh.
MULTINET:SSH_HOST_KEY
Contains the private part of the host key. This file does not exist when MultiNet is first installed.
The SSH server starts only with this file. This file must be created manually using the command:
$ MULTINET SSHKEYGEN /SSH1 /HOST
This file should be owned by SYSTEM, readable only by SYSTEM, and not accessible to others.
To create a host key with a name that is different than what SSHKEYGEN creates, do one of the following:
· Generate with MULTINET SSHKEYGEN /SSH1 /HOST and simply rename the file.
· Generate a public/private key pair using SSHKEYGEN without the /HOST switch, then copy and rename the resulting files appropriately.
By default the logical name SSH_DIR points to the MULTINET_SPECIFIC_ROOT:[MULTINET] directory.
Refer to the MultiNet User’s Guide, Chapter 8, for more details about SSHKEYGEN.
MULTINET:SSH_HOST_KEY.PUB
Contains the public part of the host key. This file should be world-readable but writeable only by SYSTEM. Its contents should match the private part of the key. This file is not used for anything; it is only provided for the convenience of the user so its contents can be copied to known hosts files.
MULTINET:SSH_KNOWN_HOSTS
SYS$LOGIN[1]:[.SSH]KNOWN_HOSTS
Checks the public key of the host. These files are consulted when using rhosts with RSA host authentication. The key must be listed in one of these files to be accepted. (The client uses the same files to verify that the remote host is the one you intended to connect.) These files should be writeable only by SYSTEM (the owner). MULTINET:SSH_KNOWN_HOSTS should be world-readable, and SYS$LOGIN:[.SSH]KNOWN_HOSTS can, but need not be, world-readable.
SSH2:SSH_RANDOM_SEED
SYS$LOGIN:[.SSH]RANDOM_SEED
Contains a seed for the random number generator. This file should only be accessible by system.
MULTINET:SSHD_CONFIG
Contains configuration data for SSHD. This file should be writeable by system only, but it is recommended (though not necessary) that it be world-readable.
AUTHORIZED_KEYS
In the user’s SYS$LOGIN[.SSH] directory, this file lists the RSA keys that can be used to log into the user's account. This file must be readable by system. It is recommended that it not be accessible by others. The format of this file is described below.
SYS$LOGIN:.SHOSTS
In the user’s SYS$LOGIN:[.SSH] directory, this file permits access using SSH only. For SSH, this file is the same as for .rhosts. However, this file is not used by rlogin and rshell daemon.
SYS$LOGIN:.RHOSTS
This file contains host-username pairs, separated by a space, one per line. The given user on the corresponding host is permitted to log in without a password. The same file is used by rlogin and rshell. SSH differs from rlogin and rshell in that it requires RSA host authentication in addition to validating the hostname retrieved from domain name servers. The file must be writeable only by the user. It is recommended that it not be accessible by others. It is possible to use netgroups in the file. Either host or username may be of the form +@groupname to specify all hosts or all users in the group.
AUTHORIZED_KEYS File Format
The SYS$LOGIN:[.SSH]AUTHORIZED_KEYS file lists the RSA keys that are permitted for RSA authentication. Each line of the file contains one key (empty lines and lines starting with a # are comments and ignored). Each line consists of the following fields, separated by spaces:
|
Key |
Description |
|
bits |
Is the length of the key in bits. |
|
comment |
Not used for anything (but may be convenient for the user to identify the key). |
|
exponent |
Is a component used to identify and make up the key. |
|
modulus |
Is a component used to identify and make up the key. |
|
options |
Optional; its presence is determined by whether the line starts with a number or not (the option field never starts with a number.) |
|
Note: Lines in this file are usually several hundred characters long (because of the size of the RSA key modulus). You do not want to type them in; instead, copy the IDENTITY.PUB file and edit it. The options (if present) consist of comma-separated option specifications. No spaces are permitted, except within double quotes. Option names are case insensitive.
|
The following RSA key file AUTHORIZED_KEYS option specifications are supported:
Allowforwardingport=”ports”
Can be followed by any number of port numbers, separated by spaces. Remote forwarding is allowed for those ports whose number matches one of the patterns.
You can use * as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_y’ to specify greater than, less than, or inclusive port range. By default, all port forwardings are allowed.
The quotes (“ “) are required. For example: allowforwardingport “2,52,2043”
Allowforwardingto=”host_port_list”
Can be followed by any number of hostname and port number patterns, separated by spaces. A port number pattern is separated from a hostname pattern by a colon. For example: hostname:port
Forwardings from the client are allowed to those hosts and port pairs whose name and port number match one of the patterns.
You can use * and ? as wildcards in the patterns for host names. Normal name servers are used to map the client’s host into a fully-qualified host name. If the name cannot be mapped, its IP address is used as the hostname.
You can use * as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_y’ to specify greater than, less than, or inclusive port range. By default, all port forwardings are allowed.
command=”command”
Specifies the command to be executed whenever this key is used for authentication. The user-supplied command (if any) is ignored. You may include a quote in the command by surrounding it with a backslash (\). Use this option to restrict certain RSA keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Notice that the client may specify TCP/IP and/or X11 forwardings unless they are prohibited explicitly.
Denyforwardingport=”ports”
Can be
followed by any number of port numbers, separated by spaces. Remote forwardings
are disallowed for those ports whose number matches one of the patterns.
You can use * as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater than, less than, or inclusive port range.
Denyforwardingto=”host_port_list”
Can be followed by any number of hostname and port number patterns, separated by spaces. A port number pattern is separated from a hostname by a colon. For example: hostname:port_number_pattern
Forwardings from the client are disallowed to those hosts and port pairs whose name and port number match one of the patterns.
You can use * and ? as wildcards in the patterns for host names. Normal name servers are used to map the client’s host into a fully-qualified host name. If the name cannot be mapped, its IP address is used as a host name.
You can use * as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater than, less than, or inclusive port range.
from=”pattern-list”
In addition to RSA authentication, specifies that the fully-qualified name of the remote host must be present in the comma-separated list of patterns. You can use * and ? as wildcards.
The list may contain patterns negated by prefixing them with ! - if the fully-qualified host name matches a negated pattern, the key is not accepted.
This option increases security. RSA authentication by itself does not trust the network or name servers (but the key). However, if somebody steals the key, the key permits login from anywhere in the world. This option makes using a stolen key more difficult because the name servers and/or routers would have to be comprised in addition to just the key.
idle-timeout=time
Sets the idle timeout limit to a time in seconds (s or nothing after the number), in minutes (m), in hours (h), in days (d), or in weeks (w). If the connection has been idle (all channels) for that time, the process is terminated and the connection is closed.
no-agent-forwarding
Forbids authentication agent forwarding when used for authentication.
no-port-forwarding
Forbids TCP/IP forwarding when used for authentication. Any port forward requests by the client will return an error. For example, this might be used in connection with the command option.
no-X11-forwarding
Forbids X11 forwarding when used for authentication. Any X11 forward requests by the client will return an error.
SSH_KNOWN_HOSTS File Format
The MULTINET:SSH_KNOWN_HOSTS and SYS$LOGIN:[.SSH]KNOWN_HOSTS files contain host public keys for all known hosts. The global file should be prepared by the administrator (optional), and the per-user file is maintained automatically; whenever the user connects an unknown host its key is added to the per-user file. Each line in these files contains the following fields: hostnames, bits, exponent, modulus, comment. The fields are separated by spaces.
Hostnames is a comma-separated list of patterns (* and ? act as wildcards). Each pattern is matched against the fully-qualified host names (when authenticating a client) or against the user-supplied name (when authenticating a server). A pattern may be preceded by ! to indicate negation; if the hostname matches a negated pattern, it is not accepted (by that line) even if it matched another pattern on the line.
Bits, exponent, and modulus are taken directly from the host key. They can be obtained from MULTINET:SSH_HOST_KEY.PUB. The optional comment field continues to the end of the line, and is not used. Lines starting with # and empty lines are ignored as comments. When performing host authentication, authentication is accepted if any matching line has the proper key.
It is permissible (but not recommended) to have several lines or different host keys for the same names. This happens when short forms of host names from different domains are put in the file. It is possible that the files contain conflicting information. Authentication is accepted if valid information can be found from either file.
|
Note: The lines in these files are hundreds of characters long. Instead of typing in the host keys, generate them by a script or by copying MULTINET:SSH_HOST_KEY.PUB and adding the host names at the front.
|
SSH Logicals
These logicals are used with the SSH server in the system logical name table.
$ SHOW LOGICAL/SYSTEM *SSH*
SSH_DIR
Points to the directory where the SSH1 configuration, master server log file, and host key files are kept. Normally, this is MULTINET_SPECIFIC_ROOT:[MULTINET]. It is defined in START_SSH.COM.
SSH_EXE
Points to the directory where SSH executables are kept. Normally, this is MULTINET_COMMON_ROOT:[MULTINET]. It is defined in START_SSH.COM.
SSH_LOG
Points to the directory where the log files are kept. Normally, this is MULTINET_SPECIFIC_ROOT:[MULTINET.LOG]. It is defined in START_SSH.COM.
SSH_TERM_MBX
Mailbox used by SSHD_MASTER to receive termination messages from SSHD daemon processes. Do not change this logical name. This is created by the SSHD_MASTER process.
MULTINET_SSH_ACC_REJ_LOG_FILE
If the user has set a log file to log connection accept and reject messages, this logical will be defined and will provide the name of the log file. This logical is set by using the SET LOG-FILE keyword in MULTINET CONFIGURE/SERVER, and should not be modified directly by the user.
MULTINET_SSH_ALLOW_EXPIRED_PW
Allows logging in to an account when the account's password has expired due to pwdlifetime elapsing. This applies to all users and circumvents normal VMS expired-password checking, and therefore should be used with caution. An entry is made into the SSH_LOG:SSHD.LOG file when access is allowed using this logical name.
When access is allowed by way of this logical, the logical name table LNM$SSH_LOGICALS contains a logical name constructed as MULTINET_SSH_pid_PWDEXP (where pid is the PID for the process). The system manager can use this to execute, for example, the DCL SET PASSWORD command in the site SYLOGIN.COM file.
MULTINET_SSH_ALLOW_PREEXPIRED_PW
Allows logging in to an account when the password has been pre-expired. This applies to all users and circumvents normal VMS expired-password checking, and therefore should be used with caution. An entry is made into the SSH_LOG:SSHD.LOG file when access is allowed using this logical name.
When access is allowed by way of this logical, the logical name table LNM$SSH_LOGICALS contains a logical name constructed as MULTINET_SSH_pid_PWDEXP (where pid is the PID for the process). The system manager can use this to execute, for example, the DCL SET PASSWORD command in the site SYLOGIN.COM file.
MULTINET_SSH_DISPLAY_SYS$ANNOUNCE
The SSH v1 protocol does not allow for the display of SYS$ANNOUNCE prior to logging in. If this logical is set, the contents of SYS$ANNOUNCE is displayed immediately after successful authentication and prior to the display of the contents of SYS$WELCOME.
MULTINET_SSH_ENABLE_SSH1_CONNECTIONS
Set to enable SSH V1 sessions.
MULTINET_SSH_KEYGEN_MIN_PW_LEN
Defines the minimum passphrase length when one is to be set in SSHKEYGEN. If not defined, defaults to zero.
MULTINET_SSH_LOG_ACCEPTS
When set, causes the server to log successful connection requests as either an OPCOM message or a line in a log file. Note that a successful connection request doesn't equate to a successful authentication request.
MULTINET_SSH_LOG_MBX
Points to the OpenVMS mailbox used to log connection accept and reject messages. This must not be modified by the user.
MULTINET_SSH_LOG_REJECTS
When set, causes the server to log rejected connection requests as either an OPCOM message or a line in a log file.
MULTINET_SSH_MAX_SESSIONS
Set this to the maximum number of concurrent SSH sessions you want to allow on the server system. If MULTINET_SSH_MAX_SESSIONS is not defined, the default is 1000. Setting MULTINET_SSH_MAX_SESSIONS to zero (0) causes an error. The value must be between 1 and 1000. The suggested place to set this is in START_SSH.COM. You must restart SSH for these changes to take effect.
MULTINET_SSH_PARAMETERS_n
These values are set by SSH for OpenVMS and must not be modified by the user.
MULTINET_SSH_USE_SYSGEN_LGI
If defined, causes SSHD to use the VMS SYSGEN value of LGI_PWD_TMO to set the login grace time, overriding anything specified in the command line or the configuration file.