If you use either the -l (loop mode) or -t (tree mode) flag, you cannot also specify the -m (maximum repetitions) flag or the -n (nonrepeaters) flag. The latter flags are incompatible with loop mode and tree mode.

Incorrect use of the -n and -m flags results in the following types of messages:

$ snmp_request mynode.co.com public getbulk -v2c -n 20 -m 10 -t 1.3.6.1.2.1 Warning: -n reset to 0 since -l or -t flag is specified. Warning: -m reset to 1 since -l or -t flag is specified. 1.3.6.1.2.1.1.1.0 = mynode.company.com

3.10.7 Duplicate Subagent Identifiers

With this version of TCP/IP Services, two subagents can have the same identifier parameter. Be aware, however, that having two subagents with the same name makes it difficult to determine the cause of problems reported in the log file.

3.10.8 Community Name Restrictions

The following restrictions on community names are imposed by TCPIP$CONFIG.COM:

• Do not specify community names that include a space character.
• A quotation mark (") specified as part of a community name might be handled incorrectly. Check the validity of the name with the SHOW CONFIGURATION SNMP command, and if necessary, correct the name with the SET CONFIGURATION SNMP command.

The following notes pertain to eSNMP programming and subagent development.

• In the documentation, the terms "extension subagent", "custom subagent", and "user-written subagent" refer to any subagent other than the standard subagents for MIB-II and the Host Resources MIB, which are provided as part of the TCP/IP Services product.
• In the [.SNMP] subdirectory of TCPIP$EXAMPLES, files with the .C, .H, .COM, .MY, and .AWK extensions contain additional comments and documentation.
• The TCPIP$SNMP_REQUEST.EXE, TCPIP$SNMP_TRAPSND.EXE, and TCPIP$SNMP_TRAPSND.EXE programs are useful for testing during extension subagent development.
• For information about prototypes and definitions for the routines in the eSNMP API, see the TCPIP$SNMP:ESNMP.H file.

This section contains the following information:

• SSH-related security advisories ( Section 3.11.1)
• SSH general notes and restrictions ( Section 3.11.2)
• UNIX features that are not supported by SSH ( Section 3.11.3)
• SSH command syntax notes and restrictions ( Section 3.11.4)
• SSH authentication notes and restrictions ( Section 3.11.5)
• SSH keys notes and restrictions ( Section 3.11.6)
• SSH session restrictions ( Section 3.11.7)
• SSH messages notes and restrictions ( Section 3.11.8)
• SSH remote command notes and restrictions ( Section 3.11.9)
• SSH batch mode restrictions ( Section 3.11.10)
• X11 port forwarding restrictions ( Section 3.11.11)
• File transfer restrictions (all file sizes) ( Section 3.11.12)
• File transfer restrictions (large files) ( Section 3.11.13)

Computer Emergency Readiness Team (CERT®) advisories are issued by the CERT Coordination Center (CERT/CC), a center of Internet security expertise located at the Software Engineering Institute, a federally-funded research and development center operated by Carnegie Mellon University. CERT advisories are a core component of the Technical Cyber Security Alerts document featured by the United States Computer Emergency Readiness Team (US-CERT), which provides timely information about current security issues, vulnerabilities, and exploits.

CERT and HP Software Security Response Team (SSRT) security advisories might be prompted by SSH activity. CERT advisories are documented at the following CERT/CC web site:

http://www.cert.org/advisories.

Table 3-1 provides brief interpretations of several SSH-related advisories:

Table 3-1 CERT/SSRT Network Security Advisories

Advisory	Impact on OpenVMS
CERT CA-2003-24	OpenSSH only; OpenVMS is not vulnerable.
CERT CA-2002-36	A worst case consequence of this vulnerability is a denial of service (DoS) for a single connection of one of the following types: Server process handling a connection from a malicious client Client process connecting to a malicious server In either case, a malicious remote host cannot gain access to the OpenVMS host (for example, to execute arbitrary code), and the OpenVMS server is still able to receive a new connection.
CERT-2001-35	OpenVMS is not vulnerable. Affects SSH Version 1 only, which is not supported.
CERT CA-1999-15	RSAREF2 library is not used; OpenVMS is not vulnerable.
SSRT3629A/B	OpenVMS is not vulnerable.

3.11.2 SSH General Notes and Restrictions

This section includes general notes and restrictions that are not specific to a particular SSH application.

• The UNIX path /etc is interpreted by the OpenVMS SSH server as TCPIP$SSH_DEVICE:[TCPIP$SSH].
• The following images are not included in this release:
  • TCPIP$SSH_SSH-CERTENROLL2.EXE
    This image provides certificate enrollment.
  • TCPIP$SSH_SSH-DUMMY-SHELL.EXE
    This image provides access to systems where only file transfer functionality is permitted.
  • TCPIP$SSH_SSH-PROBE2.EXE
    This image provides the ssh-probe2 command, which sends a query packet as a UDP datagram to servers and then displays the address and the SSH version number of the servers that respond to the query.

This section describes features that are expected in a UNIX environment but are not supported by SSH for OpenVMS.

• The server configuration parameter PermitRootLogin is not supported.
• The client configuration parameter EnforceSecureRutils is not supported.
• There is no automatic mapping from the UNIX ROOT account to the OpenVMS SYSTEM account.
• The SSH1 protocol suite is not supported for terminal sessions, remote command execution, and file transfer operations. Parameters unique to SSH1 in the server and client configuration files are ignored.

This section includes notes and restrictions pertaining to command syntax.

• From a non-OpenVMS client, if you use OpenVMS syntax for names (such as device names), enclose the names in single quotation marks to prevent certain characters from being interpreted as they would be on a UNIX system.
  For example, in the following command, UNIX interprets the dollar sign ($) as a terminator in the device name SYS$SYSDEVICE:[user], resulting in SYS:[user].

  # ssh user@vmssystem directory SYS$SYSDEVICE:[user]

  
  To avoid this problem, enter the command using the following format:

  # ssh user@vmssystem directory 'SYS$SYSDEVICE:[user]'

This section includes notes and restrictions pertaining to SSH authentication.

• This version of SSH does not support Kerberos-based authentication.
• The location of the SHOSTS.EQUIV file has been moved from TCPIP$SSH_DEVICE:[TCPIP$SSH] to TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2].
• If hostbased authentication does not work, the SSH server may have failed to match the host name sent by the client with the one it finds in DNS/BIND. You can check whether this problem exists by comparing the output of the following commands (ignoring differences in case of the output text):
  • On the server host:

    $ TCPIP TCPIP> SHOW HOST client-ip-address

  • On the client host:

    $ write sys$output - $_ "''f$trnlnm("TCPIP$INET_HOST")'.''f$trnlnm("TCPIP$INET_DOMAIN")'"

    
    If the two strings do not match, you should check the host name and domain configuration on the client host. It may be necessary to reconfigure and restart TCP/IP Services on the client host.

• If the user default directory in the SYSUAF user record is specified with angle brackets (for example, <user-name>) instead of square brackets ([user-name]), hostkey authentication fails. To solve this problem, change the user record to use square brackets.
• The pairing of user name and UIC in the OpenVMS rights database, as displayed by the AUTHORIZE utility's SHOW /IDENTIFIER command, must match the pairing in the SYSUAF record for that user name. If the pairings do not match, the following message error is displayed when the user attempts to establish an SSH session:

  Received signal 10, SIGBUS: invalid access to memory objects.

  
  To solve this, use the AUTHORIZE utility to correct the pairing of user name and UIC value in the OpenVMS rights database.

This section includes notes and restrictions pertaining to SSH keys.

• SSH client users can copy their own customized version of the SSH2_CONFIG. file and modify the value of the variable StrictHostKeyChecking . By setting the value of this variable to "no," the user can enable the client to automatically copy the public key (without being prompted for confirmation) from an SSH server when contacting that server for the first time.
  A system manager can tighten security by setting the StrictHostKeyChecking variable to "yes" in the systemwide SSH2_CONFIG. file, and forcing users to use only the systemwide version of the file. In this case, to copy the public key from the server, users (and the system manager) must use another mechanism (for example, a privileged user can manually copy the public key). To enforce this tighter security response, the system manager can perform the following steps:
  1. Edit TCPIP$SSH_DEVICE:[TCPIP$SSH]SSH2_CONFIG. to include the following line:

     StrictHostKeyChecking yes

  2. Restrict user access to TCPIP$SSH_DEVICE:[TCPIP$SSH]SSH2_CONFIG. For example:

     $ SET SECURITY/PROTECTION=(G,W) TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSH2_CONFIG.;

  3. Edit the SYS$STARTUP:TCPIP$SSH_CLIENT_STARTUP.COM command procedure to install the SSH server image with the READALL privilege. In the following example, change the existing line to the replacement line, as indicated:

     . . . $ image = f$edit("sys$system:tcpip$ssh_ssh2.exe","upcase") $! call install_image 'image' "" <== existing line $ call install_image 'image' "readall" <== replacement . . .

  4. Enable the SSH client, as described in the HP TCP/IP Services for OpenVMS Guide to SSH.

     Note Steps 2 and 3 involve modification of system files. Therefore, it may be necessary to repeat the modifications after a future update of TCP/IP Services.

• If you do not specify the key file in the SSH_ADD command, and SSH_ADD finds no INDENTIFICATION. file, it adds only the first private key it finds in the [username.SSH2] directory.
• Do not use the SSH_KEYGEN -e option (used to edit the comment or passphrase of the key). This option does not work.
• With this release, the default size of keys generated by the SSH_KEYGEN utility is 2048 bits (for earlier releases, the default size was 1024 bits). Consequently, generation of keys takes longer --- sometimes five to ten times longer. On slow systems, or during SSH configuration, key generation may seem to be hanging when it is not. No progress indicator is displayed. During SSH configuration, the following messages indicate the keys are being generated:

  Creating private key file: TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]HOSTKEY Creating public key file: TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]HOSTKEY.PUB

This section includes restrictions pertaining to SSH sessions.

• In an SSH session on the OpenVMS server, the originating client host name and the user name or port identification are not available. For example, in a TELNET session, the OpenVMS DCL command SHOW TERMINAL displays the following information about a UNIX client:

  Remote Port Info: Host: unixsys.myco.com Port:2728

  
  Likewise, information about an OpenVMS client appears as:

  Remote Port Info: Host: mysys.com Locn:_RTA4:/USER

  
  Neither of these lines are displayed in a similar SSH session.

• Starting SSH sessions recursively (for example, starting one SSH session from within an existing SSH session) creates a layer of sessions. Logging out of the innermost session may return to a layer other than the one from which the session was started.
• Cutting and pasting from SSH terminal sessions on an OpenVMS server can cause data truncation. When this happens, the following error message is displayed:

  -SYSTEM-W-DATAOVERUN, data overrun

• You cannot shut down an OpenVMS system from an SSH session, such as by executing the command:

  $ @SYS$SYSTEM:SHUTDOWN.COM

  
  The phase of shutdown that stops user processes disconnects the SSH session.

• SSH escape sequences are not fully supported. For example, you may have to enter the Escape . (escape character followed by a space and a period) exit sequence twice for it to take effect. On exit, the terminal is left in NOECHO and PASTHRU mode.
• On certain non-OpenVMS clients, after attempting to exit from an SFTP session, you must press Enter an extra time to return to the operating system prompt.

This section includes notes and restrictions pertaining to SSH session messages.

• Normally, the translation of the system logical name SYS$ANNOUNCE is displayed after authentication is complete. In this version of SSH, no automated mechanism exists for displaying this text as a prelogin banner.
  To provide a prelogin banner from a text file, create the file SSH_BANNER_MESSAGE. containing the text to be displayed before login.
  To enter multiple lines in the banner text, make sure each line ends with an explicit carriage-return character except the last line.
  Save the banner message file in the TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2] directory, with privileges that allow it to be read by the user account [TCPIP$SSH].
  If you do not use the default file name and location for the message banner file, define them using the BannerMessageFile option in the TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG. file. Specify the location and file name of your banner message file as the argument to the option using one of the following formats:

  BannerMessageFile TCPIP$SSH_DEVICE:[TCPIP$SSH]BANNER1.TXT BannerMessageFile /TCPIP$SSH_DEVICE/TCPIP$SSH/BANNER2.TXT BannerMessageFile /etc/banner3.txt

  
  Note that the argument may be in either OpenVMS or UNIX format and is not case sensitive. (If multiple definitions for the same option are included in the configuration file, the last one listed will take effect.)

• Some SSH informational, warning, and error message codes are truncated in the display. For example:

  %TCPIP-E-SSH_FC_ERR_NO_S, file doesn't exist

• Some SSH log and trace output messages, and informational, warning, and error messages display file specifications as UNIX path names.
• During certain error conditions or while exiting from an SSH session, SSH displays signal information (as displayed on a UNIX system). For example, pressing Ctrl/C results in the following message:

  Received signal 2, SIGINT: Interactive attention signal.

  
  You can ignore such messages.

• When you log out, the message "Connection to hostname closed." may overwrite the last line of the logout message, as in the following example from an SSH session established with host tst1 :

  $ LOGOUT Connection to tst1 closed.at 7-AUG-2003 14:37:15.01

This section includes notes and restrictions pertaining to SSH remote commands.

• Command lines for remote command execution through SSH are limited to 153 characters.
• After you execute an SSH remote command, you must press the Enter key to get back to the DCL prompt.
• When you execute remote commands on the OpenVMS SSH server, the log file TCPIP$SSH_RCMD.LOG is created in the directory defined by the logical name SYS$LOGIN for your user account. This log file is not purged automatically.
• When you execute remote commands on an OpenVMS SSH client connected to a non-OpenVMS SSH server, output may not be displayed correctly. For example, sequential lines might be offset as if missing a linefeed, as in the following example:

  $ ssh user@unixhost ls -a user's password: Authentication successful. . .. .TTauthority .Xauthority .cshrc .dt .dtprofile

  
  To display the output correctly, use the -t option with the command, as in the following command example:

  $ ssh -t user@unixhost ls -a

• Any OpenVMS command that refreshes the display can have unexpected results when executed as a remote SSH command. For example, the following command exhibits this behavior:

  $ MONITOR PROCESS /TOPCPU

  
  Executed locally, this command displays a bar chart that is continuously updated. When executed as a remote command, it displays each update sequentially. In addition, you cannot terminate the command using Ctrl/C.

This section includes batch mode restrictions.

• Because the SSH, SFTP, and SCP commands are implemented by code ported from UNIX sources, they do not support all of the standard OpenVMS behaviors for SYS$INPUT, SYS$OUTPUT, and SYS$ERROR in command procedures. For example:
  • SYS$INPUT is not the default batch command procedure.
  • Output written to a batch log file or other SYS$OUTPUT file may have an extra <CR> (ASCII decimal 13) or other explicit formatting characters.
  • You can direct SYS$OUTPUT to a file, as in the following example:

    $ ASSIGN OUT.DAT SYS$OUTPUT

• When you run these commands from an interactive command procedure, you should use the explicit UNIX batch mode flags, as listed in the following table:

  For...	Use...
  SSH (remote command execution or port forwarding),	-o batchmode yes
  SCP,	"-B"
  SFTP,	"-B" { batchfile}

  ---

  ¹Double quotation marks (") are required
  

  ---

  
  
• If you use the SSH command in batch mode with an interactive session (that is, not for remote command execution or setting up port forwarding), the batch job hangs.
  If the "-S" option is used in an interactive SSH session, or with an SSH command executed interactively in a DCL command procedure, the terminal session hangs. Ctrl/Y and Ctrl/C will not restore the DCL prompt. To release the hung terminal session, you must restart the SSH client and server.
• For the SFTP command, note the following:
  • If the command is used without a -b {batchfile} or "-B" {batchfile} option, SFTP uses the following file by default: SYS$LOGIN:TCPIP$SFTP_BATCHFILE.TXT.
  • Each line of batchfile, except the last, must end with a line feed ( <LF> , ASCII decimal 10).
• When running in batch mode:
  • The SFTP command displays the final state-of-progress indicator; the SCP command does not.
  • The SSH command will not prompt for a password, password update, or passphrase. If one is required, the batch job fails.
  • The SSH command will not cause a new host key to be saved if the value of StrictHostkeyChecking is "no;" SSH will not prompt for one if the value is "ask."
    For other notes and restrictions pertaining to keys, see Section 3.11.6.
  • If an ls command is contained in the SFTP batch input, and the interactive output requires input from the keyboard to continue, then some of the output lines might be omitted from the batch log file.