1. Assign a local login (operator) and enable (manager) password.

   At a minimum, HP recommends that you always assign at least a manager password to the switch. Otherwise, under some circumstances, anyone with Telnet, web, or serial port access could modify the switch configuration.

   To configure local passwords:

   You can configure both the operator and manager password with one command.

   Syntax:

   Configuring local passwords

2. Generate the switch public and private key pair.

   A public and private host key pair must be generated on the switch. The switch uses this key pair along with a dynamically generated session key pair to negotiate an encryption method and session with an SSH client trying to connect to the switch.

   The host key pair is stored in the switch flash memory, and only the public key in this pair is readable. The public key should be added to a 'known hosts' file (for example, $HOME/.ssh/known_hosts on UNIX systems) on the SSH clients which should have access to the switch. Some SSH client applications automatically add the switch public key to a 'known hosts' file. Other SSH applications require you to manually create a known hosts file and place the switch public key in the file. See the documentation for your SSH client application for more details.

   (The session key pair mentioned above is not visible on the switch. It is a temporary, internally generated pair used for a particular switch/client session, and then discarded.)

   NOTE: When generating a host key pair on the switch, the switch places the key pair in flash memory and not in the running-config file. Also, the switch maintains the key pair across reboots, including power cycles. Consider this key pair to be 'permanent' and avoid re-generating the key pair without a compelling reason. Otherwise, you must re-introduce the switch public key on all management stations you have set up for SSH access to the switch using the earlier pair. Removing (zeroing) the switch public/private key pair renders the switch unable to engage in SSH operation and automatically disables IP SSH on the switch. To verify whether SSH is enabled, execute show ip ssh. However, any active SSH sessions will continue to run, unless explicitly terminated with the CLI kill command. To generate or erase the switch public/private host key pair:

   Because the host key pair is stored in flash instead of the running-config file, it is not necessary to use write memory to save the key pair. Erasing the key pair automatically disables SSH.

   Syntax:

   crypto key generate <autorun-key[rsa]|cert[rsa] <keysize>|[ssh][dsa|rsa]bits <keysize>>

   Installs authentication files for ssh or https server, or for autorun.

   Install RSA key for autorun. See 'Configuring Autorun on the Switch' in the Management and Configuration Guide for more information.

   Install RSA key for https certificate.

   Use your SSL enabled browser to access the switch using the switch IP address or DNS name (if allowed by your browser). See the documentation provided with the browser application for more information.

   Install host key for ssh server. Specify the key type as DSA or RSA.

   Specify the key size (in bits).

   zeroize <ssh|cert|autorun[rsa]>

   Erases the switch public/private key pair and disables SSH operation.

   Displays switch public key. Displays the version 1 and version 2 views of the key.

   See SSH client public-key authentication for information about public keys saved in a configuration file.

   Displays hashes of the switch public key in phonetic format, see “Displaying the Public Key:”.

   Displays fingerprints of the switch public key in hexadecimal format, see “Displaying the Public Key:”.

   Example:

   To generate and display a new key:

   Example of generating a public/private host key pair for the switch

   To compare the switch key to the key stored in your client's known-hosts file, note that the formatting and comments need not match.

   NOTE: 'Zeroizing' the switch key automatically disables SSH (sets ip ssh to no). Thus, if you zeroize the key and then generate a new key, you must also re-enable SSH with the ip ssh command before the switch can resume SSH operation.

   Configuring key lengths:

   The crypto key generate ssh command allows you to specify the type and length of the generated host key. The size of the host key is platform-dependent as different switches have different amounts of processing power. The size is represented by the <keysize> parameter and has the values shown in . The default value is used if keysize is not specified.

   RSA/DSA values for various HP networking switches

   Platform	Maximum RSA Key Size (in bits)	DSA Key Size (in bits)
   5400/3500/6200/8200/2900	1024, 2048, 3072 Default: 2048	1024
   4200/2900/2810/2610/2510	1024, 2048 Default: 2048	1024
   5300/2800/3400/2600	896	512

3. Provide the switch public key to clients.

   When an SSH client contacts the switch for the first time, the client will challenge the connection unless you have already copied the key into the client's 'known host' file. Copying the switch key in this way reduces the chance that an unauthorized device can pose as the switch to learn your access passwords. The most secure way to acquire the switch public key for distribution to clients is to use a direct, serial connection between the switch and a management device (laptop, PC, or UNIX workstation), as described below.

   The public key generated by the switch consists of three parts, separated by one blank space each:

   A public key generated by the switch

   With a direct serial connection from a management station to the switch:

   1. Use a terminal application such as HyperTerminal to display the switch public key with the show crypto host public-key command, see Example of generating a public/private host key pair for the switch.

   2. Bring up the SSH client's 'known host' file in a text editor such as Notepad as straight ASCII text, and copy the switch public key into the file.

   3. Ensure that there are no changes or breaks in the text string. A public key must be an unbroken ASCII string. Line breaks are not allowed (changes in the line breaks will corrupt the Key.) For example, if you are using Windows® Notepad, ensure that Word Wrap (in the Edit menu) is disabled, and that the key text appears on a single line.

      Example of a correctly formatted public key

   4. Add any data required by your SSH client application. For example, before saving the key to an SSH client's 'known hosts' file you may have to insert the switch IP address:

      Example of a switch public key edited to include the switch’s IP address

      For more on this topic, see the documentation provided with your SSH client application.

   Displaying the Public Key:

   The switch provides three options for displaying its public key. This is helpful if you need to visually verify that the public key the switch is using for authenticating itself to a client matches the copy of this key in the client's 'known hosts' file:

   • Non-encoded ASCII numeric string:

     Requires a client ability to display the keys in the 'known hosts' file in the ASCII format. This method is tedious and error-prone due to the length of the keys. See Example of a correctly formatted public key.

   • Phonetic hash:

     Outputs the key as a relatively short series of alphabetic character groups. Requires a client ability to convert the key to this format.

   • Hexadecimal hash:

     Outputs the key as a relatively short series of hexadecimal numbers. Requires a parallel client ability.

   For example, on the switch, generate the phonetic and hexadecimal versions of the switch public key as follows:

   Visual phonetic and hexadecimal conversions of the switch public key

   The two commands shown in Visual phonetic and hexadecimal conversions of the switch public key convert the displayed format of the switch (host) public key for easier visual comparison of the switch public key to a copy of the key in a client's 'known host' file. The switch has only one RSA host key. The 'babble' and 'fingerprint' options produce two hashes for the key--one that corresponds to the challenge hash you will see if connecting with a v1 client, and the other corresponding to the hash you will see if connecting with a v2 client. These hashes do not correspond to different keys, but differ only because of the way v1 and v2 clients compute the hash of the same RSA key. The switch always uses an ASCII version of its public key, without babble or fingerprint conversion, for file storage and default display format.

4. Enable SSH on the switch and anticipate SSH client contact behavior.

   The ip ssh command enables or disables SSH on the switch, and modifies parameters the switch uses for transactions with clients. After you enable SSH, the switch can authenticate itself to SSH clients.

   NOTE: Before enabling SSH on the switch you must generate the switch public/private key pair. If not yet done, see Generate the switch public and private key pair. When configured for SSH, the switch uses its host public key to authenticate itself to SSH clients.For SSH clients to authenticate themselves to the switch, configure SSH on the switch for client public-key authentication at the login (operator) level. To enhance security also configure local, TACACS+, or RADIUS authentication at the enable (manager) level. See Step 5.

   SSH client contact behavior:

   At the first contact between the switch and an SSH client, if the switch public key has not been copied into the client, then the client's first connection to the switch will question the connection and, for security reasons, provide the option of accepting or refusing. If it is safe to assume that an unauthorized device is not using the switch IP address in an attempt to gain access to the client's data or network, the connection can be accepted. (As a more secure alternative, the client can be directly connected to the switch serial port to download the switch public key into the client.)

   NOTE:When an SSH client connects to the switch for the first time, it is possible for a 'man-in-the-middle' attack; that is, for an unauthorized device to pose undetected as the switch, and learn the usernames and passwords controlling access to the switch. This possibility can be removed by directly connecting the management station to the switch serial port, using a show command to display the switch public key, and copying the key from the display into a file. This requires a knowledge of where the client stores public keys, plus the knowledge of what key editing and file format might be required by the client application. However, if the first contact attempt between a client and the switch does not pose a security problem, this is unnecessary.

   Enabling SSH on the switch:

   1. Generate a public/private key pair if you have not already done so. See Generate the switch public and private key pair.

   2. Execute the ip ssh command.

   Disabling SSH on the switch:

   Perform either of the following:

   • Execute no ip ssh.

   • Zeroize the switch existing key pair, see “To generate or erase the switch public/private host key pair:” for more details.

     Syntax:

     Enables or disables SSH on the switch.

     [cipher|<cipher-type>]

     Specify a cipher type to use for connection.

     Valid types are:

     • aes128-cbc

     • 3des-cbc

     • aes192-cbc

     • aes256-cbc

     • aes128-ctr

     • aes192-ctr

     • aes256-ctr

     Default: All cipher types are available.

     Use the no form of the command to disable a cipher type.

     Enable/disable secure file transfer capability. SCP and SFTP secure file transfer will not function unless SSH is also enabled.

     [ip-version <4|6|4or6>]

     Select the IP mode to run in. The mode 'ip-version 4' only accepts connections from IPv4 clients. The mode 'ip-version 6' only accepts connections from IPv6 clients. The mode 'ip-version 4or6' accepts connections from both IPv4 and IPv6 clients.

     Default: ip-version 4 or 6

     Allows configuration of the set of MACs that can be selected. Valid types are:

     • hmac-md5

     • hmac-sha1

     • hmac-sha1-96

     • hmac-md5-96

     Default: All MAC types are available.

     Use the no form of the command to disable a MAC type.

     The TCP port number for SSH connections.

     Default: 22.

     Sets the maximum length of time (in seconds) allowed for initial protocol negotiation and authentication.

     Default: 120 seconds

     NOTE:HP recommends using the default TCP port number (22). However, you can use ip ssh port to specify any TCP port for SSH connections except those reserved for other purposes. Examples of reserved port numbers reserved IP ports are 23 (Telnet) and 80 (http). Some other reserved TCP ports on the switch are 49, 80, 1506, and 1513.

     Enabling IP SSH and displaying the SSH configuration

     CAUTION:Protect your private key file from access by anyone other than yourself. If someone can access your private key file, they can penetrate SSH security on the switch by appearing to be you. SSH does not protect the switch from unauthorized access via the WebAgent, Telnet, SNMP, or the serial port. While WebAgent and Telnet access can be restricted by the use of passwords local to the switch, if you are unsure of the security this provides, you may want to disable web-based and/or Telnet access (no web-management and no Telnet). If you need to increase SNMP security, use SNMP version 3 only. To increase the security of your web interface see the section on SSL. For an additional security measure, see the authorized IP managers feature in the Management and Configuration Guide for your switch. To protect against unauthorized access to the serial port (and the Clear button, which removes local password protection), keep physical access to the switch restricted to authorized personnel.

5. Configure the switch for SSH authentication.

   Note that all methods in this section result in authentication of the switch public key by an SSH client. However only Option B below results in the switch also authenticating the client's public key. Also, for a more detailed discussion of the topics in this section, see SSH client public-key authentication notes.

   NOTE:HP recommends that you always assign a manager-level (enable) password to the switch. Without this level of protection, any user with Telnet, web, or serial port access to the switch can change the switch configuration. If you configure only an operator password, entering the operator password through telnet, web, ssh or serial port access enables full manager privileges. See Assign a local login (operator) and enable (manager) password.

   Option A: Configuring SSH access for password-only SSH authentication:

   When configured with this option, the switch uses its public key to authenticate itself to a client, but uses only passwords for client authentication.

   Syntax:

   aaa authentication ssh login <local|tacacs|radius|[peap-mschapv2>][<local|none>]

   Configures a password method for the primary and secondary login (operator) access. If you do not specify an optional secondary method, it defaults to none. If the primary method is local, the secondary method must be none.

   aaa authentication ssh enable <local|tacacs|radius>[<local|none>]

   Configures a password method for the primary and secondary enable (manager) access. If you do not specify an optional secondary method, it defaults to none. If the primary method is local, the secondary method must be none.

   Option B: Configuring the switch for client Public-Key SSH authentication

   If configured with this option, the switch uses its public key to authenticate itself to a client, but the client must also provide a client public key for the switch to authenticate. This option requires the additional step of copying a client public-key file from a TFTP or SFTP server into the switch. This means that before you can use this option, you must:

   1. Create a key pair on an SSH client.

   2. Copy the client's public key into a public-key file (which can contain up to 10 client public keys.)

   3. Copy the public-key file into a TFTP or SFTP server accessible to the switch and download the file to the switch.

   For more on these topics, see SSH client public-key authentication notes.

   With steps a-c complete and SSH properly configured on the switch, if an SSH client contacts the switch, login authentication automatically occurs first, using the switch and client public keys. After the client gains login access, the switch controls client access to the manager level by requiring the passwords configured earlier by the aaa authentication ssh enable command.

   Syntax:

   Copies a public-key file into the switch.

   Configures the switch to authenticate a client public key at the login level with an optional secondary password method.

   Default: none

   Syntax:

   aaa authentication ssh enable <local|tacacs|radius> <local|none>

   Configures a password method for the primary and secondary enable (manager) access. If you do not specify an optional secondary method, it defaults to none.

   If the primary access method is local, you can only specify none for a secondary access method.

   NOTE: The configuration of SSH clients' public keys is stored in flash memory on the switch. You also can save SSH client public-key configurations to a configuration file by entering the following commands: include-credentials write memory For more information about saving security credentials to a configuration file, see Saving security credentials in a config file.

   Example:

   Assume you have a client public-key file named Client-Keys.pub (on a TFTP server at 10.33.18.117) ready for downloading to the switch. For SSH access to the switch allow only clients having a private key that matches a public key found in Client-Keys.pub. For manager-level (enable) access for successful SSH clients use TACACS+ for primary password authentication and local for secondary password authentication, with a manager username of '1eader' and a password of 'm0ns00n'. To set up this operation, configure the switch in a manner similar to the following:

   Configuring for SSH access requiring a client public-key match and manager passwords

   SSH configuration and client public-key listing from figure shows how to check the results of the above commands.

   SSH configuration and client public-key listing from figure

6. Use an SSH client to access the switch.

   Test the SSH configuration on the switch to ensure that you have the level of SSH operation needed for the switch. If you have problems, see 'RADIUS-related problems' in the Management and Configuration Guide for your switch.

1. Ssh V2 Keys
2. Ssh V2ray
3. Ssh V2ray
4. Ssh V2 Cisco
5. Ssh V2 Cisco

SSH for OpenVMS V2.4 Admin and User's Guide

The Secure Shell Version 2 Support feature allows you to configure Secure Shell (SSH) Version 2. (SSH Version 1 support was implemented in an earlier Cisco software release.) SSH runs on top of a reliable transport layer and provides strong authentication and encryption capabilities. The only reliable transport that is defined for SSH is TCP. SSH provides a number of desirable features such as authentication, encryption, data integrity, authorization, and forwarding/tunneling. The SSH protocol specification has a number of minor version differences, but there are two major versions of the protocol: SSH1 (SSH version 1.XX) and SSH2 (SSH version 2.00).

This chapter describes how to configure and maintain the SSH for OpenVMS Secure Shell (SSH) server v2.

This is the server side of the software that allows secure interactive connections to 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 version 1.5 protocol, and F-Secure 1.3.7 code base, and the SSH2 implementation is based on the V2 protocol and the WRQ RSIT 6.1.4.0 code base. 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.

The cryptographic library used by MultiNet SSH2 (this does not apply to SSH1 sessions) is compiled from unaltered cryptographic source code from F-Secure which is FIPS 140-2 level 2 compliant, as determined by the Computer Security Division of the National Institute of Science and Technology (NIST).

Note!You must install the DEC C 6.0 backport library on all OpenVMS VAX v6.0 and earlier systems prior to using SSH. This is the AACRT060.A file. You can find the ECO on the MultiNet CD in the following directory: VAX55_DECC_RTL.DIR.

Restrictions:

When using SSH2 to connect to a VMS server, if the VMS account is set up with a secondary password, SSH2 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 SSH2 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 SSH2. If this behavior poses a problem, log into the remote system using SSH2 in interactive mode to execute the program.

Understanding the MultiNet Secure Shell Server

Secure Shell daemon (SSHD) is the daemon program for SSH2 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 MultiNet SSH 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 existing 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 MultiNet, but any SSH client that uses SSH version 2 protocol may be used to access the server. Examples of such programs are MultiNet SSH, TCPware SSH, 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 VMScluster 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. See the description of the CIPHERS configuration keyword for the encryption methods supported.

• 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 and RSHELL 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 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.

Expired Password Handling

The SSH2 server supports expired password changing for interactive accounts 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 the user 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, the server 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'
$!

When an account in the SYSUAF has an expired password and the system syslogin.com or user’s login.com has a SET TERM command, a warning message will be displayed prior to prompting to change the password as shown in the following example:

Your password has expired; you must set a new password to log in
% SET-W-NOTSET, error modifying DKA0:
-SET-E-INVDEV, device is invalid for requested operation
Old password:

The way to suppress these warning messages would be to check for the appropriate login flag, ignoring any SET TERM commands. For example:

$ flags = $getjpi(', 'LOGIN_FLAGS')
$ new_flags = (flags/2)*2
$ if new_flags.eq.4 then goto skip_the_inquiry

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 AllowedAuthentications and RequiredAuthentications. The number of intrusion records to be logged for any attempted SSH session is determined by the StrictIntrusionLogging configuration keyword. Messenger for facebook dmg.

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.

SSH2 Configuration File

SSHD reads configuration data from its configuration file. By default, this file is SSH2_DIR:SSHD2_CONFIG. 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.

The keywords /MAC and /CIPHER 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).

HostSpecificConfig Notes:

The global server file (SSH_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 foo.bar.com dka0:[sshconfigs]fooconfig.dat

HostSpecificConfig lima.beans.com limaconfig.dat

In the first instance, an incoming connection from 'foo.bar.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 ssh2_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.

UserSpecificConfig Notes:

The global server file (SSH2_DIR:SSHD2_CONFIG) now can use the keyword UserSpecificConfig to allow the 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

Ssh V2 Keys

pattern 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.dat

In the first instance, an incoming connection for user dilbert will use the subconfig file dka0:[sshconfigs]dilbert.dat. In the second example, an incoming connection from user boss at system lima.beans.com will user 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.

KEYBOARD-INTERACTIVE Notes:

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.

ForwardACL Notes

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 address 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). Therefore, you should not rely on the originator address with local forwards, unless you know exactly what you are doing. With remote forwards, 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 fowards 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]TcpForwardingForUsers.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.

MappingFileFormat

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:

Email

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.

Ssh V2ray

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 lor 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 it 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=FooLtd., 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 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. 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

1Use 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.

2Use 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

3Copy the template server configuration file to the ssh2_dir: directory renaming it SSHD2_CONFIG.:

$ COPY MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2]SSHD2_CONFIG.TEMPLATE -
_$ MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2]SSHD2_CONFIG.

4Copy the template client configuration file to the ssh2_dir: directory renaming it SSH2_CONFIG.:

$ COPY MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2]SSH2_CONFIG.TEMPLATE -
_$ MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2]SSH2_CONFIG.

Note!As delivered, the template files provide a reasonably secure SSH environment. However, Process Software recommends these files be examined and modified appropriately to reflect the security policies of your organization.

5Start SSH. This creates the SSH server process and defines the SSH logical names.

$ @SYS$STARTUP:PSCSSH$STARTUP
$ SHOW PROCESS 'SSHD Master'

3-MAR-2005 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:'

Changing SSH2 Configuration File After Enabling SSH2

If you make a change to the SSH configuration file after you have enable SSH, 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:

1SSHD_MASTER sees the connection attempt. It creates an SSHD process, passing the operating parameters to it. SSHD performs validation for the user.

2Assuming 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.

3SSHD 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.

4SSH 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 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 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 writable 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.

Note! This warning also applies to rshell/rlogin.

MULTINET:SHOSTS.EQUIV

Processed as MULTINET:HOSTS.EQUIV. May be useful in environments that want to run both rshell/rlogin and ssh.

MULTINET_SSH2_HOSTKEY_DIR:HOSTKEY

Contains the private part of the host key. This file does not exist when MultiNet is installed. The SSH server starts only with this file. This file must be created manually using the command:

$ MULTINET SSHKEYGEN /SSH2 /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 SSHKEYGEN /SSH2/HOST and simply rename the file(s).

• Generate without the /HOST switch and then name the file(s) whatever you want.

By default the logical name SSH2_DIR points to the MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2] directory.

Refer to the MultiNet for OpenVMS User’s Guide, Chapter 8, for more details about SSHKEYGEN.

MULTINET_SSH2_HOSTKEY_DIR:HOSTKEY.PUB

Contains the public part of the host key. This file should be world-readable but writable only by SYSTEM. Its contents should match the private part. 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.

SSH2:SSH_RANDOM_SEED
SYS$LOGIN [ In this chapter, the [.SSH] subdirectory in the user’s login directory displays as SYS$LOGIN:[.SSH]] :[.SSH]RANDOM_SEED

Contains a seed for the random number generator. This file should only be accessible by system.

SSH2_DIR:SSHD2_CONFIG

Contains configuration data for the v2 SSHD server. This file should be writable by system only, but it is recommended (though not necessary) that it be world-readable.

SYS$LOGIN:[.SSH2].SHOSTS

Permits access using SSH2 only. For SSH2, 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. SSH2 differs from rlogin and rshell in that it requires RSA host authentication in addition to validating the hostname retrieved from domain name servers (unless compiled with the -with-rhosts configuration option). The file must be writable 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.

SYS$LOGIN:[.SSH2]AUTHORIZATION

This file contains information on how the server verifies the identity of a user.

SYS$LOGIN:[.SSH2.KNOWNHOSTS]xxxxyyyy.pub

These are the public host keys of hosts that a user wants to log in from using 'hostbased' authentication (equivalent to the SSH1's 'RhostsRSAAuthentication'). Also, a user must set up his/her individual .SHOSTS or .RHOSTS file. If the username is the same in both hosts, it is adequate to put the public host key in SSH2_DIR:KNOWNHOSTS and add the host's name to the system-wide SHOSTS.EQUIV or RHOSTS.EQUIV file.

xxxx is the hostname (FQDN) and yyyy denotes the public key algorithm of the key ('ssh-dss' or 'ssh-rsa').

For example flower.plants.com's host key algorithm is 'ssh-dss'. The hostkey would then be 'flower_plants_com_ssh-dss.pub' in the [.SSH2.KNOWNHOSTS] directory.

SSH2 AUTHORIZATION File Format

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. The following keywords may be used:

SSH2 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 master server log file is 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.SSH]. It is defined in START_SSH.COM.

MULTINET_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_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.

Ssh V2ray

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. Specified by the SET LOG-ACCEPT command in MULTINET CONFIGURE/SERVER. Note that the server does not use the information set in the ACCEPT-HOSTS keyword in CONFIGURE/SERVER. Rather, it uses the 'AllowHosts' and 'DenyHosts' keywords in the SSH server configuration file. Also, a successful connection request doesn't equate to a successful authentication request. This logical should not be modified directly 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. Specified by the SET LOG-REJECT command in MULTINET CONFIGURE/SERVER. Note that the server does not use the information set in the REJECT-HOSTS keyword in CONFIGURE/SERVER. Rather, it uses the 'AllowHosts' and 'DenyHosts' keywords in the SSH server configuration file. This logical should not be modified directly by the user.

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) will cause an error. The value must be between 1 and 1000. The suggested place to set this is in START_SSH.COM. SSH must be restarted to use the new value if it is changed.

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_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_PARAMETERS_n

These values are set by MultiNet 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.

MULTINET_SSH_ENABLE_SSH2_CONNECTIONS

Enables SSHD Master to accept SSH V2 sessions.

MULTINET_SSH2_HOSTKEY_DIR

Directory containing the host keys for the SSH V2 server. Normally set to MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2.HOSTKEYS]

Ssh V2 Cisco

MULTINET_SSH2_KNOWNHOSTS_DIR

Directory containing the public keys for known systems. Normally set to MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2.KNOWNHOSTS].

SSH2_DIR

Contains all SSH V2-specific files, such as configuration files. Normally set to MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2]

SSH daemon Files

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.

SSH_LOG:SSHD.LOG

This log file is created by each SSHD daemon.

SSHD_MASTER.LOG

This log file is created by SSHD_MASTER.

SSH_START.COM

Ssh V2 Cisco

This files is used to start SSH.