Configuring the Secure Shell (SSH) V2 Server
This chapter describes how to configure and maintain the SSH for OpenVMS SSH V2 server.
This is the server side of the SSH software that allows secure interactive connections from other computers in the manner of rlogin/rshell/telnet. 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 are different, and incompatible, protocols. The SSH1 implementation is based on the V1.5 protocol and 1.3.7 F-Secure code base, and the SSH2 implementation is based on the V2 protocol and the F-Secure 3.2.0 code base. While SSH2 is generally regarded to be more secure than SSH1, both protocols are offered by the SSH for OpenVMS server, and although they are incompatible, they may exist simultaneously on an SSH for OpenVMS system. The server front-end identifies what protocol a client desires to use, and will create an appropriate server for that client.
When using SSH to connect to a VMS server, if the VMS account is set up with a secondary password, SSH 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 SSH 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 SSH. If this behavior poses a problem, log into the remote system using SSH in interactive mode to execute the program.
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.
An SSH for OpenVMS server is an OpenVMS system that acts as a host for executing interactive commands or for conducting an interactive session. The server software consists of two pieces of software (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 the SSH v1 server is run; if the request is for SSH v2, then the SSH v2 server is run.
• SSHD, a copy of which is spawned for each connection instance. SSHD handles all the interaction with the SSH client.
A client is any system that accesses the server. A client program (SSH) is provided with SSH for OpenVMS, but any SSH client that uses SSH version 2 protocol may be used to access the server. Examples of such programs are SSH for OpenVMS, MultiNet, TCPware; SecureCRT®, and F-Secure SSH Client for Windows®, MacSSH for Macintosh® systems, and other SSH programs on UNIX-based systems.
Each host has a key using DSA encryption and is usually 1024 bits long (although, the user may create a different-sized key, if desired). The same key may be used on multiple machines. For example, each machine in a VMS cluster could use the same key.
When a client connects to the SSHD daemon:
• The client and server together, using the Diffie-Hellman key-exchange method, determine a 256-bit random number to use as the "session key". This key is used to encrypt all further communications in the session.
Note that this key may be renegotiated between the client and the server on a periodic basis by including the RekeyIntervalSeconds keyword in the server configuration file (SSH2_DIR:SSHD2_CONFIG). This is desirable because during long sessions, the more data that is exchanged using the same encryption key, the more likely it is that an attacker who is watching the encrypted traffic could deduce the session key.
• The server informs the client which encryption methods it supports. Currently, AES-128 (the default), Twofish, Blowfish, CAST-128, DES, 3DES, and ARCFOUR are supported by the SSH for OpenVMS system.
• The client selects the encryption algorithm from those offered by the server.
•
The client and the server then enter a user authentication dialog. The server informs the client which authentication methods it supports, and the client then attempts to authenticate the user by using some or all of the authentication methods. The following authentication algorithms are supported:
– public-key (DSA keys)
– hostbased
– password
– keyboard-interactive
– Kerberos V5 (password, kerberos-tgt, kerberos-1, kerberos-tgt-1, kerberos-2, kerberos-tgt-2)
– Certificate
System security is not improved unless the RLOGIN, RSHELL, and TELNET services are disabled.
If the client authenticates itself successfully, a dialog is entered for preparing the session. At this time the client may request things like:
• 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.
The SSH2 server supports expired password changing for interactiveaccounts without the CAPTIVE or RESTRICTED flags set and, via the DCL SET PASSWORD command. When an expired password is detected, the server will behave as if a SET PASSWORD command was specified by the user as a remotely-executed command (e.g., $ ssh foo set password), and theuser will be logged out after changing the password. The user may then log in again using the changed password.
For CAPTIVE or RESTRICTED accounts, or for those accounts where LGICMD is set in the UAF record, the scenario is different. In these cases, theserver can't directly execute SET PASSWORD command, because the command procedure specified in the LGICMD field of the UAF record will override the SSH server attempting to do a SET PASSWORD command. For these types of accounts, the system manager and/or user can use the value of the LOGIN_FLAGS for the process (normal interactive sessions may also examine these flags). For SSH logins, these flags will reflect:
• 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"
$!
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 AllowedAuthentications and RequiredAuthentications. 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. The following rules apply:
• When HostBased or PublicKey authentications are attempted and fail, one intrusion record is logged for each failed method.
• When password authentication is attempted, one intrusion record is logged for each failed password.
Example 1:
The server is set up to allow HostBased and password authentication; also, up to three password attempts are allowed. If all methods fail, four intrusion records are logged:
1 for the failed HostBased
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 HostBased or PublicKey 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 HostBased or PublicKey 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 HostBased and password authentication; also, up to three password attempts are allowed. If all methods fail, three intrusion records are logged:
0 for the failed HostBased
3 for the failed password attempts, one per attempt
Example 3:
The server is set up to allow HostBased and password authentication; also, up to three password attempts are allowed. HostBased and RSA fail, but password authentication is successful after 1 failed password. Therefore, one intrusion record is logged:
0 for the failed HostBased
1 for the failed password attempt
Example 4:
The server is set up to allow HostBased and PublicKey authentication, but not password authentication. If all methods fail, one intrusion record is logged.
Example 5:
The server is set up to allow HostBased and PublicKey authentication, but not password authentication. HostBased authentication fails, but PublicKey succeeds. No intrusion records are logged.
The SSHD Master is configured via CNFSSH. See Chapter 3 of the SSH for OpenVMS Administration and User’s Guide for details on using CNFSSH to configure SSH.
Note! The only supported methods for starting SSH are to use the @SYS$STARTUP:PSCSSH$STARTUP command if SSH isn’t running, or to use the SSHCTRL RESTART command if SSH is currently running.
SSHD reads configuration data from its configuration file. By default, this file is SSH2_DIR:SSHD2_CONFIG. However, it may be modified by setting the ssh2-config-file parameter with CNFSSH. The file contains keyword value pairs, one per line. Lines starting with # and empty lines are interpreted as comments. The following keywords are possible. Keywords are case insensitive.
Note! HP’s TCP/IP services do not use the traditional UNIX rhosts and hosts.equiv files; it uses a proprietary format. Therefore, any information added to HP’s files via the "ADD PROXY" command must also be manually added to the SSH_DIR:RHOSTS and SSH_DIR:HOSTS.EQUIV files in order for it to be used by SSH for OpenVMS.
Table 5-1 SSH2 Configuration File Keywords [SSHD2_CONFIG]
The keywords MACs and Ciphers have discrete values, plus there are values that actually denote a grouping of 2 or more of the discrete values. Each of these values may be put in the configuration file (SSH2_DIR:SSHD2_CONFIG).
Table 5-2 MAC and Cipher Discrete Values
|
MACs |
discrete values: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-sha256@ssh.com, hmac-sha256-96@ssh.com, hmac-ripemd160@ssh.com, hmac-ripemd160-96@ssh.com, hmac-tiger128@ssh.com, hmac-tiger128-96@ssh.com, hmac-tiger160@ssh.com, hmac-tiger160-96@ssh.com, hmac-tiger192@ssh.com, hmac-tiger192-196@ssh.com, none |
|
group ANYMAC consists of: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-256@ssh.com, hmac-sha256-96@ssh.com, hmac-ripemd160ssh.com, hmac-ripemd160-96@ssh.com, hmac-tiger128@ssh.com, hmac-tiger128-96@ssh.com, hmac-tiger160@ssh.com, hmac-tiger160-96@ssh.com, hmac-tiger192@ssh.com, hmac-tiger-192-96@ssh.com | |
|
group ANY consists of: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-sha256@ssh.com, hmac-sha256-96@ssh.com, hmac-ripemd160@ssh.com, hmac-ripemd160@ssh.com, hmac-ripemd160-96@ssh.com, hmac-tiger128@ssh.com, hmac-tiger128-96@ssh.com, hmac-tiger160@ssh.com, hmac-tiger160-96@ssh.com, hmac-tiger192@ssh.com, hmac-tiger192-96ssh.com, none | |
|
group ANYSTD consists of: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, none | |
|
group ANYSTDMAC consists of: hmac-md5, hmac-md5-96, hmac-md5, hmac-md5-96 | |
|
Ciphers |
discrete values: aes128-cbc, 3des-cbc, twofish128-cbc, cast128-cbc, twofish-cbc, blowfish-cbc, aes192-cbc, aes256-cbc, twofish192-cbc, twofish256-cbc, arcfour, des-cbc@ssh.com, rc2-cbc@ssh.com, none |
|
group ANYSTDCIPHER consists of: aes128-cbc, 3des-cbc, twofish128-cbc, cast128-cbc, twofish-cbc, blowfish-cbc, aes192-cbc, aes256-cbc, twofish192-cbc, twofish256-cbc, arcfour | |
|
group ANY consists of: aes128-cbc, 3des-cbc, twofish128-cbc, cast128-cbc, twofish-cbc, blowfish-cbc, aes192-cbc, aes256-cbc, twofish192-cbc, twofish256-cbc, arcfour, des-cbc@ssh.com, rc2-cbc@ssh.com, none | |
|
group ANYCIPHER consists of: aes128-cbc, 3des-cbc, twofish128-cbc, cast128-cbc, twofish-cbc, blowfish-cbc, aes192-cbc, aes256-cbc, twofish192-cbc. twofish256-cbc, arcfour, des-cbc@ssh.com, rc2-cbc.com | |
|
group ANYSTD consists of: aes 128-cbc, 3des-cbc, twofish128-cbc, cast128-cbc, twofish-cbc, blowfish-cbc, aes192-cbc, aes256-cbc, twofish192-cbc, twofish256-cbc, arcfour, des-cbc@ssh.com, rc2-cbc@ssh.com |
A discrete value or a group identifier may be used with MACS and CIPHERS. For example, in the configuration file, the following examples could be used:
|
Ciphers |
ANYCIPHER |
|
Ciphers |
cast, des, twofish |
|
MACs |
ANYMAC |
|
MACs |
hmac-sha1 |
Aliases may be used for some standard ciphers:
|
Alias |
Value |
|
aes |
aes128-cbc |
|
des |
des-cbc |
|
3des |
3des-cbc |
|
cast |
cast128-cbc |
|
twofish |
twofish-cbc |
|
blowfish |
blowfish-cbc |
|
arcfour |
arcfour |
The global server file (SSH2_DIR:SSHD2_CONFIG) now can use the keyword HostSpecificConfig to allow the specification of a configuration file based on the client system. These lines are specified as:
HostSpecificConfig hostname subconfig-file
Hostname will be used to match the client host, as specified under option AllowHosts. The file subconfig-file will then be read, and configuration data amended accordingly. The file is read before any actual protocol transactions begin, and you can specify most of the options allowed in the main configuration file. You can specify more than one subconfiguration file, in which case the patterns are matched and the files read in the order specified. Later defined values of configuration options will either override or amend the previous value depending on which option it is. The effect of redefining an option is described in the documentation for that option. For example, setting Ciphers in the subconfiguration file will override the old value, but setting AllowUsers will amend the value.
The subconfig-file will be assumed by default to exist in the SSH2_DIR directory. However, this may be overridden by specifying a complete directory/file specification. For example:
HostSpecificConfig foobar.com dka0:[sshconfigs]fooconfig.dat
HostSpecificConfig lima.beans.com limaconfig.dat
In the first instance, an incoming connection from "foobar.com" will use the subconfig file dka0:[sshconfigs]fooconfig.dat. In the second example, an incoming connection from "lima.beans.com" will use ssh2_dir:limaconfig.dat.
Unlike sshd2_config, the subconfig files may have configuration blocks, or stanzas, in them. They are used per-host. The subconfiguration heading is interpreted identically to what is described above (i.e., with UserSpecificConfig, the pattern is of the format "hostname").
Note! If the subconfig file cannot be found or cannot be parsed successfully for any reason, access to the system will be denied for the system to which the subconfig file applies.
The global server file (SSH2_DIR:SSHD2_CONFIG) now can use the keyword UserSpecificConfig to allow that specification of a configuration file based on the username of the user who’s logging into the server. These keywords are of the form:
UserSpecificConfig user[%group][@host] subconfig-file
Hostname will be used to match the username, as specified under the option AllowUsers. The file subconfig-file will then be read, and configuration data amended accordingly. The file is read before any actual protocol transactions begin, and you can specify most of the options allowed in the main configuration file. You can specify more than one subconfiguration file, in which case the patterns are matched and the files read in the order specified. Later defined values of configuration options will either override or amend the previous value, depending on which option it is. The effect of redefining an option is described in the documentation for that option. For example, setting Ciphers in the subconfiguration file will override the old value, but setting AllowUsers will amend the value.
Unlike sshd2_config, the subconfig files may have configuration blocks, or stanzas, in them. They are used per-user. The subconfiguration heading is interpreted identically to what is described above (i.e., with UserSpecificConfig, the pattern is of the format "user[%group][@host]".
The subconfig-file will be assumed by default to exist in the SSH2_DIR directory. However, this may be overridden by specifying a complete directory/file specification. For example:
UserSpecificConfig dilbert dka0:[sshconfigs]dilbert.dat
UserSpecificConfig boss@lima.beans.com pointyhair.org
In the first instance, an incoming connection for user dilbert will use the sub config file dka0:[sshconfigs]dilbert.dat. In the second example, an incoming connection from user boss at system lima.beans.com will use ssh2_dir:pointyhair.dat.
Note! If the subconfig file cannot be found or cannot be parsed successfully for any reason, access to the system will be denied for the user to which the subconfig file applies.
At this point, KEYBOARD-INTERACTIVE mode is simply another form of password authentication. The user won’t notice anything different with this mode. In the future, Process Software may implement items such as system passwords, secondary passwords, and true VMS-style password changing using this authentication method. As other clients support the use of the KEYBOARD-INTERACTIVE authentication method for doing password authentication (without using any external callouts from the mechanism such as secureid cards), the server should support those clients.
With this option, you can have more fine-grained control over what the client is allowed to forward, and to where. Format for this option is:
[allow|deny] [local|remote] user-pat forward-pat [originator-pat]
user-pat will be used to match the client user, as specified under the option UserSpecificConfig. forward-pat is a pattern of format host-id[%port]. This has different interpretations, depending on whether the ACL is specified for local or remote forwards. For local forwards, the host-id will match with the target host of the forwarding, as specified under the option AllowHosts. port will match with the target port. Also, if the client sent a host name, the IP addresss will be looked up from the DNS, which will be used to match the pattern. For remote forwardings, where the forward target is not known (the client handles that end of the connection), this will be used to match with the listen address specified by the user (and as such is not as usable as with local forwards). port will match the port the server is supposed to be listening to with this forward. With local forwards, originator-pat will match with the originator address that the client has reported. Remember, if you do not administer the client machine, users on that machine may use a modified copy of ssh that can be used to lie about the originator address. Also, with NATs (Network Address Translation), the originator address will not be meaningful (it will probably be an internal network address). So, you should not rely on the originator address with local forwards, unless you know exactly what you are doing. With remote forwards, on the other hand, originator-pat will match with the IP address of the host connecting to the forwarded port. This will be valid information, as it is the server that is checking that information.
If you specify any allow directives, all forwards in that class (local or remote) not specifically allowed will be denied (note that local and remote forwards are separate in this respect, e.g., if you have one "allow remote" definition, local forwards are still allowed, pending other restrictions). If a forward matches with both allow and deny directives, the forwarding will be denied. Also, if you have specified any of the options [Allow.Deny]TcpForwardingFor[Users.Groups]or AllowTcpForwarding, and the forwarding for the user is disabled with those, an allow directive will not re-enable the forwarding for the user. Forwarding is enabled by default.
When certificates are used in user authentication, one or more mapping files determine whether the user can log to an account with a certificate. The mapping file must contain one or more lines in the following format:
account-id keyword arguments
Keyword must be one of the following: Email, EmailRegex, Subject, SerialAndIssuer, or SubjectRegex.
Arguments are different for each keyword. the following list describes each variation:
arguments: an email address in standard format. If the certificate contains the email address as an alternate name, it is good for logging in as user account-id.
Subject
arguments: a subject name in DN notation (LDAP style). If the name matches the one in the certificate, the certificate is good for logging in as user account-id.
SerialAndIssuer
arguments: a number and an issuer name in DN notation (LDAP style), separated by whitespace. If the issuer name and serial number match those in the certificate, the certificate is good for logging in as user account-id.
EmailRegex
arguments: a regular expression (egrep syntax). If it matches an altername (of type email-address) in the certificate, the certificate is good for logging in as user account-id. As a special feature, if account-id contains a string %subst%, it is replaced by the first parenthesized substring of the regular expression before comparing it with the account the user is trying to log into.
SubjectRegex
Works identically to EmailRegex, except matches the regular expression to the canonical subject name in the received certificate.
Empty lines and lines beginning with # are ignored.
EXAMPLE: MAPPINGFILE
guest email guest@domain.org
guest subject C=Fl,O=Company Ltd., CN=Guest User
guest SerialAndUser 123 C=Fl, O=Foo\,Ltd., CN=Test CA
%subst% EmailRegex ([a-z]+)@domain.\org
%subst% SubjectRegex ^C=Fl,O=Company,CN=([a-z]+)$
The example EmailRegex permits in users with email addresses with domain domain.org and usernames that contain only letters, each user to the account that corresponds to the username part of the email address.
The example SubjectRegex lets in all users with fields C=Fl and O=Company in the subject name if their CN field contains only letters and is the account name they are trying to log into.
Note the ^ and $ at the beginning and end of the regular expression; they are required to prevent the regular expression from matching anything less than the whole string (subject name).
Note also that all characters interpreted by the regular expression parser as special characters must be escaped with a backslash if they are a part of the subject name itself. This also means that the backslash in the SerialAndIssuer example would have to be escaped with another backslash if the same subject name was used in a SubjectRegex rule.
Follow these instructions to configure the SSH server. If SSH isn’t currently running, you must define the MULTINET logicals by using:
$ @SYS$STARTUP:PSCSSH$STARTUP LOGICALS
1 Use the CNFSSH utility to enable the SSH2 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 SSH2 host key now?" For more information, see Chapter 3 in this manual.
2 Use SSHKEYGEN /SSH2/HOST to generate an SSH2 key and to create the server key in the MULTINET_SSH2_HOSTKEY_DIR directory if it has not previously been created as part of the CNFSSH configuration:
$ DEFINE MULTINET_SSH2_HOSTKEY_DIR -
_$ MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.HOSTKEYS]
$ MULTINET SSHKEYGEN /SSH2/HOST
Generating 1024-bit dsa key pair
8 .oOo.oOoo.oO
Key generated.
1024-bit dsa, lillies@flower.plants.com, Mon Mar 03 2003 09:19:47
Private key saved to multinet_ssh2_hostkey_dir:hostkey.
Public key saved to multinet_ssh2_hostkey_dir:hostkey.pub
3 Edit the configuration file at SSH2_DIR:SSHD2_CONFIG (if you wish to change the default settings). This default configuration is the same as contained in the file MULTINET:SSHD2_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 Start SSH. This creates the SSH server process and defines the SSH logical names.
$ @SYS$STARTUP:PSCSSH$STARTUP
$ SHOW PROCESS "SSHD Master"
3-MAR-2003 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*
"MULTINET_SSH2_HOSTKEY_DIR" ="MULTINET_SPECIFIC_ROOT:
[MULTINET.PSCSSH.SSH2.HOSTKEYS]"
"MULTINET_SSH2_KNOWNHOSTS_DIR"=
"MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.KNOWNHOSTS]"
"MULTINET_SSH_ALLOW_EXPIRED_PW"="1"
"MULTINET_SSH_ALLOW_PREEXPIRED_PW"="1"
"MULTINET_SSH_DISPLAY_SYS$ANNOUNCE"="1"
"MULTINET_SSH_ENABLE_SSH1_CONNECTIONS"="1"
"MULTINET_SSH_ENABLE_SSH2_CONNECTIONS"="1"
"MULTINET_SSH_LOG_MBX" = "MBA37"
"MULTINET_SSH_PARAMETERS_0"="/BITS=768/VERBOSE/QUIET/PORT=22"
"MULTINET_SSH_PARAMETERS_1"="/KEY_GEN_TIME=3600"
"MULTINET_SSH_PARAMETERS_2"=""
"MULTINET_SSH_PARAMETERS_3" =""
"SSH2_DIR"=MULTINET__SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2]"
"SSH_DIR"="MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH]"
"SSH_EXE"= MULTINET_COMMON_ROOT:[MULTINET.PSCSSH]"
"SSH_LOG"= MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.LOG"
"SSH_MAX_SESSIONS"="100"
"SSH_TERM_MBX"="MBA36:"
$ SSHCTRL RESTART
Note! When issuing the "RESTART" command for SSH, all active SSH server sessions are terminated. Active client sessions are not affected.
To create a session, SSHD does the following:
1 SSHD_MASTER sees the connection attempt. It creates an SSHD process, passing the operating parameters to it. SSHD performs validation for the user.
2 Assuming the login is successful, SSHD creates a pseudo terminal for the user (an FTAnn: device). This device is owned by the user attempting to log in.
3 SSHD creates an interactive process on the pseudo terminal, using the username, priority, and privileges of the user who is attempting to log in. If a command was specified, it is executed and the session is terminated.
4 SSH generates the file SSHD.LOG 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 SSH_LOG: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.
Note! HP’s TCP/IP services do not use the traditional UNIX rhosts and hosts.equiv files; it uses a proprietary format. Therefore, any information added to HP’s files via the "ADD PROXY" command must also be manually added to the SSH_DIR:RHOSTS and SSH_DIR:HOSTS.EQUIV files in order for it to be used by SSH for OpenVMS.
The following table provides descriptions of the various SSH files:
The Authorization file contains information on how the server verifies the identity of a user. This file has the same general syntax as the SSH2 configuration files, as shown in the following table.
Table 5-4 SSH2 AUTHORIZATION Keywords
|
Keyword |
Description |
|
KEY |
The filename of a public key in the [.SSH2] directory in the user's SYS$LOGIN directory. This key is used for identification when contacting the host. If there are multiple KEY lines, all are acceptable for login. |
|
COMMAND |
This keyword, if used, must follow the KEY keyword above. This is used to specify a "forced command" that executes on the server side instead of anything else when the user is authenticated. This option might be useful for restricting certain public keys to perform certain operations. |
These logicals are used with the SSH server in the system logical name table.
These files are used by or created by SSH when you log into a daemon. These files are not to be altered in any way.
Table 5-6 SSH daemon Files
|
File |
Description |
|
SSH_LOG:SSHD.LOG |
This log file is created by each SSHD daemon. |
|
SSHD_MASTER.LOG |
This log file is created by SSHD_MASTER. |