Frequently Asked Questions

  • Why is MultiNet on the same CD as SSH for OpenVMS?

    The same images that provide SSH on MultiNet are used for SSH for OpenVMS. When SSH for OpenVMS is installed, only the SSH images, command files, and configuration templates are copied to the system.

    MultiNet, a complete TCP/IP stack for OpenVMS, is present on the CD, but it does not need to be installed to run SSH for OpenVMS. If you would like to try MultiNet to compare its features with HP TCP/IP Services, you can request an evaluation license by contacting our sales department or one of our business partners.

    What SSH clients does your SSH servers work with besides your own?

    A wide variety of SSH clients have been tested with our SSH server at Process Software. You can view the list at

    When I first start-up the SSH server, the master server process does not appear.

    Before starting SSH, you will need to generate host keys using the following commands:


    to generate SSH1 host keys, and


    to generate SSH2 host keys.

    Note that you don't need to generate SSH1 host keys if you're not going to allow SSH1 sessions and the same for SSH2 host keys and sessions.

    Why do I always get SSH v2 connections when I use the SSH for OpenVMS client?

    The SSH for OpenVMS SSH client understands both SSH1 and SSH2 protocols. When the SSH client connects to a server system, the server identifies itself to the client, and part of the identification is the version of the protocol(s) offered by the server. Since SSH v2 is a far more secure protocol, the client will always choose SSH v2 over v1 when both protocols are available. The only way to make an SSH1 connection is to connect to a server that doesn't support the SSH v2 protocol.

    What versions of OpenVMS does SSH for OpenVMS support?

    SSH for OpenVMS supports OpenVMS/VAX version 5.5-2, 6.2, 7.0, 7.1, 7.2, 7.3; OpenVMS Alpha version 6.2, 7.0, 7.1, 7.2-1, 7.2-2, 7.3, 7.3-1

    What versions of HP TCP/IP Services does SSH for OpenVMS support?

    HP TCP/IP Services is supported on any version of OpenVMS supported by SSH for OpenVMS.

    What is the difference between SSH v2 and SSH v1 protocol?

    SSH1 and SSH2 are different, and incompatible, protocols. The SSH v1 implementation is based on the V1.5 protocol and 1.3.7 F-Secure code base, and the SSH2 implementation is based on the V2 protocol and the F-Secure 3.1.0 code base. While SSH v2 is generally regarded to be more secure than SSH v1, both protocols are offered by the SSH for OpenVMS server, and although they are incompatible, they may exist simultaneously on an SSH for OpenVMS system. The server front-end identifies what protocol a client desires to use, and will create an appropriate server for that client.

    Which applications can I secure besides Telnet and the R services?

    Port forwarding allows forwarding of TCP/IP connections to a remote machine over an encrypted channel. A local proxy server is created for a remote TCP/IP service. The service can be one of the Internet protocols: pop, smtp (used by e-mail software), http (used by Web browsers), TCP/IP connection to an RDBMS server, or almost any other TCP/IP based service provided the port is known via a static assignment. The local proxy server listens for a socket on the desired port, forwards the request and data over the secure channel, and instructs the SSH server to make the connection to the specified service on the remote machine. The only noticeable change is that the client software is configured to connect to the local proxy server rather that the remote server.

    Which encryption ciphers are supported?

    SSH Ciphers



    3DES (112 bit)



    Archfour (128 bit)



    BlowFish (128 bit)



    DES (56 bit)



    IDEA (128 bit)



    TwoFish (256 bit)



    AES (128, 192, 256 bit)



    Cast-128 (128 bit)



    When I do an ls command to some SFTP servers (on UNIX systems), the list of files is not alphabetized, but on others it is. Why?

    SFTP2 lists the files in the order that it receives them from the SFTP Server, and the SFTP Server delivers names in the order that they are received from the operating system. If the operating system keeps the names sorted (VMS does), then the list of file names will be in alphabetical order.

    Why do I have problems with version numbers (or wildcards for version numbers) when in VMS mode?

    Displaying multiple versions of files is controlled by the logical [product]_SFTP_VMS_ALL_VERSIONS. If this logical is defined to TRUE, then all versions of files are displayed in directory commands. The default value is FALSE. Version numbers are not included with the filename if only the most recent version is being displayed.

    I connected to a system running an earlier version of Process Software's SFTP-SERVER2 and VMS transfer mode was not automatically negotiated.

    Older versions of the SFTP-SERVER2 do not provide the information that the SFTP2 client needs to see that VMS mode is available unless they have been set to translate by default ($ define [product]_sftp_translate_vms_file_types 7).

    Why is the directory from a VMS system presented in UNIX format when VMS transfer mode is not in use?

    In order to present filenames in a consistent format, they are only displayed as VMS filenames when VMS transfers are in use. When binary or ASCII transfers are in use, filenames are presented in UNIX format.

    Why do the filenames on my VMS system have $ characters in them?

    On ODS-2 disks the filenames are SRI encoded to preserve case and other special characters. For ODS-5, the logical [product]_sftp_use_sri_encoding_on_ods5 controls will cause SRI encoding to be used if it is defined to be TRUE (the default value is FALSE).

    Why doesn't SFTP2 have a TRANSLATE mode like SCP2 does?

    The TRANSLATE_VMS qualifier was a method of providing ASCII (text) transfers when they were not available. It was felt that it was not necessary since SFTP2 has ASCII (text) transfers.

    I am using WinSCP on my PC and it won't work with the VMS system. Why?

    In order for WinSCP to work with the VMS system, the following UNIX commands must be placed in the path: alias, cd, chgrp, chmod, chown, echo, groups, ls, mkdir, mv, pwd, scp, rm, unalias, and unset. The user must have sufficient permissions to execute these UNIX commands. Because VMS doesn't have these commands, WinSCP will not work with the VMS SFTP server. See for additional information.

    I've enabled the SSH server to do SSH1 but not SSH2 and my attempts to use SFTP fail. Why?

    SSH2 must be enabled to use SFTP.

    How do I resolve SFTP and SCP file transfer problems between my OpenVMS system and non-OpenVMS system?

    The original SSH File Transfer Protocol specified binary access to files; though the protocol has been updated to include a text (ASCII) transfer mode, many vendors have not implemented this to date.

    The first implementation of SCP2 and SFTP2 that Process Software offered in MultiNet v4.4, TCPware v5.6, and SSH for OpenVMS v1.0 would perform an automatic conversion of common VMS text file formats to stream-lf (Unix) format. The files types that were translated depended on the value of the logical MULTINET_SFTP_TRANSLATE (or for TCPware use TCPWARE_SFTP_TRANSLATE).

    In MultiNet v4.4, TCPware v5.6, and SSH for OpenVMS v1.0 the default value is that no files are converted. Beginning in MultiNet v5.0, TCPware v5.7-1, and SSH for OpenVMS v2.0, the default value is all files. The down side of this conversion is an “end of file” message for implementations that expect to transfer the exact number of bytes that was reported for the file. Though the file size estimation routine uses a number of items to determine how many bytes will actually be delivered, it is usually high (it is never low). For customers that cannot tolerate the inaccuracies of the estimation there is now an estimate threshold (MULTINET_SFTP_FILE_ESTIMATE_THRESHOLD or for TCPWare use TCPWARE_SFTP_FILE_ESTIMATE_THRESHOLD). The default value of this is 0, so that performance is maintained, as files that are smaller than the threshold are read to get an exact number of bytes.

    In MultiNet v5.1 (or v5.0 plus all ecos), TCPware v5.7-2, and SSH for OpenVMS v2.0 (plus ecos), the SFTP client and server connect the server reports its newline sequence. The SFTP client uses this value during ASCII translations to convert from the local representation to the negotiated representation for the transfer. If no value is specified during the connection, then the default value of linefeed is used. This can be overridden with the MULTINET_SFTP_ NEWLINE_STYLE logical (or for TCPware use TCPWARE_SFTP_ NEWLINE_STYLE). Use of this logical can also have a performance impact as it is possible to have a file that is in stream-lf format read, have carriage returns added, and then have them removed when the file is transferred. Because the SFTP client and server are backward compatible, it is often possible to transfer a file in ASCII mode to a server that does not have this transfer mode available. This depends upon the default newline value being appropriate for the remote system.

    File naming is also another area that may require some additional configuration. VMS ODS2 disks only store file names in uppercase. To preserve the case of the original files we use SRI encoding. The SRI encoding on ODS2 disks can be disabled with the MULTINET_SFTP_ ODS2_SRI_ENCODING (or for TCPware use TCPWARE_SFTP_ ODS2_SRI_ENCODING). (This is also used by our NFS server and FTP server when operating in Unix mode.) ODS5 disks retain case, so SRI encoding is not normally used on these disks. VMS directories contain the extension .DIR, which is not used when directories are used in a file specification and generally not used by other systems. For compatibility sake the SFTP client and server assume that a file without a dot in it is a directory. There are times when the type of the file cannot be properly inferred, and the default value of UNKNOWN can yield to errors in parsing of file specifications. In order to provide a work around for these situations the logical MULTINET_SFTP_DEFAULT_FILE_TYPE_REGULAR (for TCPware use TCPWARE_SFTP_DEFAULT_FILE_TYPE_REGULAR) has been added to cause the SFTP client to assume that a file is a “REGULAR” (instead of a directory) when it cannot determine it from context.

    What logicals do I need to configure when doing SFTP and SCP files transfers between two Process Software OpenVMS systems?

    Transferring files between two VMS systems using Process Software’s SFTP is much easier compared to a VMS and non-VMS system. Our client and server recognize each other automatically and send the necessary file characteristics so that the file can have the same format on the destination system as it had on the source system.

    I need to set up the SFTP2 transfer to work from a batch job. I'm not seeing an equivalent to the /PASSWORD qualifier that we were using with normal FTP and the documentation doesn't seem to speak to the issue. Is there a recommended methodology for supplying the password in batch mode?

    Password authentication cannot be used by SSH, SFTP, or SCP when in batch mode. You will have to use a non-interactive authentication method, most likely public key authentication. To set up public key authentication you will need to create a key pair -

     $ multinet sshkeygen/ssh2/keys=[.ssh2]corbett/nopass
       Generating 1024-bit dsa key pair
       8 .oOo.oOo.ooO
       Key generated.
       1024-bit dsa,, Tue Apr 18 2006 12:48:50
       Private key saved to [.SSH2]CORBETT
       Public key saved to [.SSH2]

    You can create an identification. file in the [.ssh2] directory, or edit the existing one and add an idkey line to it. This instructs the client to use the key specified during authentication -

     $ create [.ssh2]identification.
       idkey corbett

    Copy the public key to the server. I use scp in the example below -

     $ scp [.ssh2] ""
       Password: | 747B | 0.7 kB/s | TOC: 00:00:01 | 100%

    You then have to configure the server to use the public key for authentication. If you are using our server you would put the .pub file in the user's [.ssh2] subdirectory and then add a key line to the [.ssh2]authorization. file like the following -


    If it is a Unix server and is running an OpenSSH server then the key will have to be converted. Here is an example using SSH to convert the key that was just sent over and append it to the user's authorized_keys file -

     $ ssh "" ssh-keygen -i -f >> .ssh/authorized_keys
       Authentication successful.

    The ssh-keygen command might be different depending on the version of the OpenSSH software. Check the man pages for the specific option to convert the key to the OpenSSH format. In the example above it is the -i option:

    -i This option will read an unencrypted private (or public) key
    file in SSH2-compatible format and print an OpenSSH compatible
    private (or public) key to stdout. ssh-keygen also reads the
    SECSSH Public Key File Format. This option allows importing
    keys from several commercial SSH implementations.

    Now you can use SSH, SFTP, or SCP commands without using a password -

     $ ssh "" date
       Authentication successful.
       Tue Apr 18 14:47:40 EDT 2006

    To use SFTP in a command procedure you will probably want to use the /batchfile= qualifier and put the SFTP commands in there. For example -

     $ create sftp.take
       get file.log
       rm file.log
       $ sftp/batch_file=sftp.take ""
       sftp> get file.log
       file.log | 25B | 0.0 kB/s | TOC: 00:00:01 | 100%
       sftp> rm file.log
       sftp> exit

Home > Support > SSH > FAQs