HP OpenVMS Systems Documentation

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 is displayed in a similar SSH session; however, information for SSH sessions is available in the logical names SYS$REM_ID (username) and SYS$REM_NODE and SYS$REM_NODE_FULLNAME (hostname)
• 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.
• 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.

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 may need to 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 the -B {batchfile} option, SFTP uses the following file by default: SYS$LOGIN:TCPIP$SFTP_BATCHFILE.TXT.
• 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.15.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.

ls can fail when using sftp cd to a logical name from a Tru64 UNIX client.

For a workaround, try the following:

1. cd to the path for the directory in UNIX format, e.g., instead of: cd tcpip$ssh_home , use cd /sys$sysdence/tcpip$ssh .
2. Perform the ls specifying the logical name in the path, e.g., ls /tcpip$ssh_home .

This section includes X11 port forwarding restrictions and problems.

• To use X11 forwarding in native mode, the system must be running DECwindows MOTIF Version 1.3 or higher. In addition, the X Authority utility (xauth) is required on the system. The X11 server uses this utility for authenticating host/user connections. For more information on how to use this utility, see the HP DECwindows Motif for OpenVMS documentation.
• To display a remote X11 client application on your X11 server, you must set the display variable on the X11 client to the address of the X11 server the client is connecting to. You can verify that the variable is set correctly on an OpenVMS system by using the following DCL command:

  $ SHOW LOGICAL DECW$DISPLAY

  
  For WSA display devices, use the SHOW DISPLAY command to see the display variable value.
  To set the display variable on an OpenVMS client to point to your server, use the SET DISPLAY command as in the following example, where 127.127.1.1 is the server node address:

  $ SET DISPLAY/CREATE/NODE=127.127.1.1/TRANSPORT=TCPIP

  
  SSH on OpenVMS supports only local and TCP/IP transports. If you are using a local transport, you have to be at the system where the display is to appear, and that system must be running the X11 server. For local transport, use the following command to set the display:

  $ SET DISPLAY/CREATE/TRANSPORT=LOCAL

  
  On UNIX systems, use the following command to set the display variable to point to a server node with address 16.20.176.33 and using the TCP/IP transports:

  >setenv display 16.20.176.33:0.0

  
  To use local transport, use the following UNIX command:

  >setenv display :0.0

• To set up a standard port forwarding session for X11 on a remote OpenVMS system, HP recommends that you use remote port forwarding; local port forwarding will not work.

This section includes SSH restrictions pertaining to file transfer operations.

• Using the colon character ":" in the pathname for the source and destination filename parameters in an SCP command may cause a delay.
  Due to an overloading of the colon character in SCP syntax to indicate a hostname and in OpenVMS as a path delimiter, what is intended to be an OpenVMS logical name for a device or directory in an SCP file parameter may be checked as a hostname first and passed to a DNS lookup. Normally this is benign, but this could incur an otherwise unexplainable wait in an environment experiencing DNS lookup delays. To avoid the possibility of confusion, use UNIX-style filename syntax.
• On OpenVMS, setting the ForcePTTYAllocation keyword to "yes" in the SSH2_CONFIG. file can result in failures when performing file copy operations. (In other implementations of SSH, setting the keyword ForcePTTYAllocation to "yes" in the SSH2_CONFIG. file has the same effect as using the -t option to the SSH command.)
• When connected to some servers, the client can detect packet benign file transfer protocol packet-length errors. By default, no message is displayed.
  To display warning messages, type the following:

  $ DEFINE/SYS NO TCPIP$SSH_TOLERANT_PROTOCOL STATUS

  
  using either the "NO" or any string starting with an upper- or lowercase N.
  Following is an example of a warning message:

  Warning: packet length mismatch: expected 27, got 8; connection to non-standard server?

  
  To retain the logical name assignment through each reboot, add the DEFINE command to the appropriate startup command procedure.
• VMS Plus Mode:
  When the client and the server are OpenVMS systems running v5.6, they recognize each other as such and implement TCP/IP Services specific SFTP protocol extensions that allow transfer of files in either direction while preserving the key OpenVMS file attributes: record format and record attributes.
  The TCP/IP Services SCP client uses SFTP as the underlying protocol so VMS Plus mode works with SCP as well.
  VMS Plus mode supports only sequential organization files.
  Remember that if a v5.6 system is connected with an older TCP/IP Services system that does not support VMS Plus mode, file attributes will not be preserved. VMS Plus mode can only be used if both sides support it.
• Talking to a system without VMS Plus:
  If one side of the file transfer, client or server, does not support VMS Plus mode for SFTP, file attributes will not be preserved.
  In this mode TCP/IP Services supports reading of any of the following types of sequential organization files:
  • Stream_LF
  • Variable Length
  • VFC
  • Fortran Carriage Control
  • Fixed Length
  • Undefined
  
  Note that which side is the server and which is the client is irrelevant. OpenVMS is simply running on the side that is reading the file. You can, for example, use SFTP client from OpenVMS to put a VFC file to UNIX, or you could use the SFTP client on the UNIX system to get the same file from the OpenVMS system. In either case, the OpenVMS system is reading the file and the Unix file is writing it.
  Copying some VFC files from OpenVMS to systems not running OpenVMS and then back to OpenVMS may result in a file that the OpenVMS DIFFERENCES command shows as different from the original file. This is unpreventable and the file as transferred out and back in is correct in that the TYPE and PRINT commands display it as expected and the output here is the same as that for the original file.
  Copying Fortran CC files from OpenVMS to systems other than OpenVMS will always result in a file that shows differences from the original. This is because on its transfer from OpenVMS to UNIX the Fortran CC attributes were converted to inline ASCII control character sequences that print the lines as the Fortran CC control bytes require. For example, the Fortran character for overstrike results in a pair of carriage returns for the line thus implementing an overstrike.
• TCP/IP Services supports only sequential file organization, not relative or indexed files
  To transfer these unsupported files you can package the file(s) into an OpenVMS saveset and transfer that or, depending on how many hops over which SFTP/SCP implementations and operating systems, you may need to use more extreme measures. One way that works consistently (provided that you have FTSV installed) is packaging files into a save set, then using SPOOL COMPRESS to make them into an self-extracting VMS image, then using UUENCODE to transform the image into an ASCII text file.
• Not all variants of UNIX path names are supported when referring to files on OpenVMS clients and servers.
• The SCP and SFTP commands from the following Windows clients have been tested and interoperate correctly with the OpenVMS SSH server:
  • PuTTY
  • SSH Communications
  
  Other versions and other clients may work, depending on protocol implementation and factors such as whether the client can handle OpenVMS-format file specifications.
• When using the SFTP command, pressing Ctrl/C does not display "Cancel" as expected. Also, Ctrl/T does not work as in DCL to display a status line; instead, it switches two adjacent characters, as on UNIX systems. Other problems with character handling have been fixed.
• The SFTP ls command pauses for an extended time after displaying a page of data and then continues with the next page. This occurs because the ssh server is sending back a complete directory listing, which the client filters; therefore, for directories with many files, the delay is due to the client waiting for listing results from the server. This is typical SFTP behavior, and not specific to OpenVMS.
• Using SCP or SFTP command to copy a file back to itself (either in local mode, or by connecting back to the client host) fails with the following error:

  %TCPIP-E-SSH_FC_ERR_INVA, file record format invalid for copy

• The SCP command issued from a client using SSH Version 1 will not work with the OpenVMS SSH server. The OpenVMS server does not support SSH Version 1.

This section includes restrictions pertaining to transferring large files:

• The minimum version of DECC$SHR running on your system must be that which was released with OpenVMS Version 8.2.
• You may need to adjust memory parameters (WSDEF, WSQUO, WSEXTENT, and PGFLQUO) to accommodate the memory requirements of the file copy client and server. The exact value depends on system resources and virtual memory configuration. For more information, see Section 2.3. For ssh filecopy, testing has shown that the main parameter to adjust is PGFLQUO.

If an SSH client attempts to use gssapi-with-mic authentication to the TCP/IP Services for OpenVMS SSH server on a server host that is running Kerberos V2.1 and the SSH client user's TGT is forwardable (a kinit -f has been done) and the GssapiDelegateCredentials flag is set then the SSH server will signal the following error in the server log:

Internal credentials cache error 

This error text may appear on the SSH client user's screen, depending on configuration.

This can be worked around in either of the following ways:

1. Upgrade to Kerberos V3.0 on the SSH server host.
2. Use the kinit without the -f flag on the SSH client.
3. Turn the GssapiDelegateCredentials configuration switch off on the SSH client.

Because forwarding of client credentials with gssapi-with-mic authentication to the OpenVMS SSH server is not supported setting GssapiDelegateCredentials is not necessary.

3.15.16 SFTP general problems and restrictions

This section includes SFTP general notes and restrictions.

• In an SFTP session, the ls command entered with the directory path in a OpenVMS syntax displays or lists the content of the directory in the UNIX syntax. For example:

  sftp> ls [.ssh_testfiles] ./ssh_testfiles ./ssh_testfiles/98277_SLF.Z;1

• In a SFTP session, the ls -R command fails to handle sub-directories if the directory filename includes ODS-5 extended characters.
• The following sftp command with the "*.*" format does not provide the complete list of files:

  sftp> ls [.ssh_testfiles]*.*

  
  However, you can use the following command formats to list all the files:

  sftp> ls [.ssh_testfiles]*.*;* sftp> ls [.ssh_testfiles]*

• The SFTP get command does not parse the correct version number to the file. For example, the following command gets the file with the version number, but the version number is invalid.

  sftp> get TCPIP$FTP_SERVER.LOG;-5000000

• No error message is displayed with an SFTP get command on a file with an invalid version number and a wildcard character.
• In an SFTP session, the lrm command fails when the command is entered with wildcard character "*" as follows:

  sftp> lrm *.*;* Command failed. sftp> lrm BIG_VFC.*;* Command failed.

• The SFTP client exhibits a memory leak. It runs out of memory and generates an error message because of the extensive use of wildcard filenames in the get and put operations.

This restriction applies only to those using AUDIT with class device as in the following command:

$ SET AUDIT/ALARM/ENABLE=ACCESS=ALL/CLASS=DEVICE 

If the SFTP server generates audit warnings for a logical IO to a mailbox when the SFTP user exits SFTP, perform the following step to prevent this from occurring:

$ DEFINE/SYSTEM TCPIP$SSH_SERVER_WAIT_FOR_CHILD 1 

When you turn on BIND Resolver Diagnostics using either of the following methods, you can create an SSH packet corruption:

• Define the logical name TCPIP$BIND_RES_OPTIONS to "debug".
• Add the following line to TCPIP$ETC:RESOLV.CONF :

  options debug