HP TCP/IP Services for OpenVMS
3.15.7 SSH sessions
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
- 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 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
- 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.
3.15.8 SSH messages
This section includes notes and restrictions pertaining to SSH session
- 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
To provide a prelogin banner from a text file, create the
file SSH_BANNER_MESSAGE. containing the text to be displayed before
To enter multiple lines in the banner text, make sure each
line ends with an explicit carriage-return character except the last
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
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:
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
- 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.
3.15.9 SSH remote commands
This section includes notes and restrictions pertaining to SSH remote
- 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
- 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
To display the output correctly, use the
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
3.15.10 SSH batch mode
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
(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
SSH (remote command execution or port forwarding),
-o batchmode yes
1Double 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.
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
option, SFTP uses the following file by default:
- 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
is "no;" SSH will not prompt for one if the value is
For other notes and restrictions pertaining to
keys, see Section 3.15.6.
- If an
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.
3.15.11 ls fails after cd to a logical name from a Tru64 UNIX client
can fail when using
to a logical name from a Tru64 UNIX client.
For a workaround, try the following:
to the path for the directory in UNIX format, e.g., instead of:
- Perform the
specifying the logical name in the path, e.g.,
3.15.12 SSH X11 port forwarding
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
- 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
$ 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 184.108.40.206 and using
the TCP/IP transports:
>setenv display 220.127.116.11:0.0
To use local transport, use the following UNIX command:
- 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.
3.15.13 SSH file transfer (All File Sizes)
This section includes SSH restrictions pertaining to file transfer
- 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
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
to "yes" in the SSH2_CONFIG. file has the same effect as
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
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
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.
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
- Variable Length
- Fortran Carriage Control
- Fixed Length
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
command shows as different from the original file. This is
unpreventable and the file as transferred out and back in is correct in
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:
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
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
%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.
3.15.14 SSH transferring large files
This section includes restrictions pertaining to transferring large
- 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
3.15.15 SSH server signals internal credentials cache error
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
This can be worked around in either of the following ways:
- Upgrade to Kerberos V3.0 on the SSH server host.
- Use the
flag on the SSH client.
- Turn the GssapiDelegateCredentials configuration switch off on the
Because forwarding of client credentials with
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
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]
- In a SFTP session, the
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
sftp> ls [.ssh_testfiles]*.*;*
sftp> ls [.ssh_testfiles]*
- The SFTP
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
command on a file with an invalid version number and a wildcard
- In an SFTP session, the
command fails when the command is entered with wildcard character "*"
sftp> lrm *.*;*
sftp> lrm BIG_VFC.*;*
- 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
3.15.17 SFTP generates audit warnings with class device
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
3.15.18 BIND Resolver diagnostics creates an SSH packet corruption
When you turn on BIND Resolver Diagnostics using either of the
following methods, you can create an SSH packet corruption:
- Define the logical name
- Add the following line to