SSH for OpenVMS FAQ: General
Setting Up SSH Clients
Before getting into the details, note that SSH setup can be confusing until some basic concepts are understood, and that implementations can vary, so that how setup is done on one system may be different from what is done on another system in terms of files, file formats, and configuration options and methods.
The SSH protocol comes in two forms: SSH1 and SSH2. SSH1 is not used much these days, so we will cover SSH2 user setup here, and assume that the system-level configuration is in place and working and the need is to set up a user account to use SSH for login from this account, or into this account, using SSH. We will further assume that user authentication will be done in both cases using public key authentication, since password authentication requires no real setup, and other forms of authentication are not often used.
Creating an SSH session involves a lot of processing between the client and the server to negotiate host authentication methods, authenticate the host, negotiate encryption and message authentication methods, user authentication options, etc. Most of this is built-in or configured at the system level, but when using public key user authentication, there is some user-account-specific configuration as well.
The basic needs for the user account are:
- The public host key for each host the user will log into. This is to enable authentication of the destination host and is supplied by the host.
- A user-specific public/private key pair to use to authenticate the user to
the server. This is generated with the
SSHKEYGENcommand. - Specification of what private key(s) to attempt authentication with when logging into servers from the user's account.
- Specification of what public/private key pairs can be used to authenticate a user to log into the user's account.
- Optional configuration to adjust client/server negotiations or to specify how to log into specific servers.
This information is kept in the user's login directory, in the [.SSH2]
directory tree. Each of these pieces of information are stored in separate
files. All of the files are text files, and can be edited, copied, read,
e-mailed, etc. as required.
Unless the destination host key has been previously set up for the user's account, the user will need to accept it on the first connection to that host. The destination host will supply its public host key, and the user will be asked whether to accept it. If it is accepted, it will be stored and used on future connections to that host.
The public host key is used by the client to verify that the host connected to is the host that was requested, which will have the matching private key. The user may have been given the host key information via some other method for use in deciding whether to accept the destination host key, or the user may just accept it, assuming that the connection went to the correct host. At some sites the host's public key may be pre-set in the user's account via other methods. Regardless of how the user acquires the destination host's public key, if the host ever changes its host key, the user will be informed of the mismatch on the next connection, and asked to accept the host's new public key.
The public/private key pair for user authentication is generated with the
SSHKEYGEN command. The type of key created must be of a type the server to be
connected to will accept (/keytype=(dsa | rsa | ecdsa | ed25519)). The private
key file is generally stored in the user's [.SSH2] directory, and must be
protected sufficiently, such as (RWD,RWD,,) or the SSH client will not use it.
$ multinet sshkeygen /ssh2 /keytype=ecdsa /bits=521
The public key doesn't need as much protection...since it's public...enough to prevent it being changed is sufficient. More importantly, the public key must be copied to the server being connected to, and set up in the way that that system requires public keys to be, so the server can check it against the client's private key to authenticate the user. How the public key is set up varies between implementations; so check the documentation for that system to learn how to do this. You can move the public key to the server system in whatever way is most convenient, such as e-mail, FTP, cut/paste in a terminal edit session, etc.
For incoming SSH connections, the public key from the remote system is usually
kept in a key file with a .PUB extension, in the user's [.SSH2] directory.
Keys generated on remote systems may require reformatting to be useful to the
local SSH server, if the remote server is running OpenSSH. OpenSSH uses a
different format for public key files than Process's SSH2 implementation does.
SSHKEYGEN has an option for converting keys from OpenSSH form into the form
needed. See the HELP entry for /OPENSSH_CONVERT.
In addition to creating the key files, the client and server on the local system
must be told how they are to be used by way of two files that are, by default,
in the [.SSH2] directory: IDENTIFICATION. and AUTHORIZATION..
The client uses the [.SSH2]IDENTIFICATION. file to know what private key
files to use to identify the user to a server. This file has lines of the form:
idkey private-key-file-name
For example:
idkey ID_RSA_2048_MYHOST.
When an SSH connection arrives at the local server requesting access to the
user's account, the SSH2 server uses the [.SSH2]AUTHORIZATION. file to know what
public keys can be used to authenticate the remote user. It has lines of the
form:
key public-key-file-name
For example:
key ID_RSA_2048_REMHOST.PUB
There are configuration options that can be put into an [.SSH2]SSH2_CONFIG.
file that can change some of this, such as the name of the IDENTIFICATION.
file, if desired, as well as defining options for use with specific hosts, such
as port number to connect to, default username, etc. This can simplify commonly
used SSH command lines for specific hosts. There is documentation for this
here that has more detail and examples.
Due to the variations in design and configuration of various clients and servers, there are often issues that need to be tracked down and corrected. This can involve the keytype, the server port to connect to, protection on private key files, the ciphers supported by the client vs. the ciphers required by the server, host key exchange method mis-match, etc. When there is a problem, the first thing to do is to get some debug output to see what's happening between the client and server.
In many cases adding /verbose to the SSH command is sufficient, but in
others more detail is needed and /debug=4 or /debug=6 may be more
informative. /verbose is equivalent to /debug=2. The higher the
number, the more detailed the output, and going higher than 6 is almost
never required, and only likely to be useful to engineering.
SCP and SFTP both use the same session establishment and authentication steps as SSH, so using SSH while working out connection issues is preferable, as it eliminates the debug outputs related to the other applications and simplifies interpreting the output.
There will often be a line in the output that says what the problem is, such as none of the user's keys being acceptable to the server (usually means the public key isn't set up correctly on the server), or there is an issue finding common key exchange or cipher methods between the client and server.
Updating Older SSH Keys
If you've recently upgraded an SSH client system, and found that you can no longer SSH into your OpenVMS system, the problem may be the host key. As computers get faster and algorithms get better, the crypto keys used to protect systems need to change to make cracking them more difficult. Recent updates of some OSs have deprecated the use of RSA for host keys (DSA was deprecated years ago in a similar way) in favor of ECDSA keys.
To fix this problem you will need to create ECDSA host keys for the SSH server so that RSA and ECDSA keys are both available when SSH clients request connections. If you no longer want clients to be
able to use RSA, you can remove the RSA key, and the associated entries in the sshd2_config. file, when you add the new ECDSA key.
The command to generate a new ECDSA host key is:
$ multinet sshkeygen/ssh2/host/keytype=ecdsa/bit=521
You then need to edit SSH2_DIR:SSHD2_CONFIG. and add the new ECDSA key to the file:
hostKeyFile "SSH2_DIR::hostkey_ecdsa." PublicHostKeyFile "SSH2_DIR:hostkey_ecdsa.pub"
The next time a client logs in they may see the following warning:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This is to be expected, and is not an indication of a problem.
Introduction to SSH User Configuration Files
Process Software SSH client operation is simplified with SSH user configuration files. An individual user can set up a configuration file to customize the connections to SSH server nodes. One advantage of implementing configuration files is a simpler command line so that the user doesn't need to remember customized information pertaining to a specific node's configuration.
The user configuration file can contain configuration keywords that are common for connections to all remote servers (user name, for example). They can also have "stanzas" that contain target node specific keyword values, such as ciphers. This configuration file can be created once and then copied to all nodes where the user has an account.
Customizing the Connections to SSH Server Nodes
To illustrate, let's say that user JACKIE on node FLAT accesses an account named RALPH on node BUS in the domain EXAMPLE.COM. The system administrator on node BUS has changed the port that SSH listens on from the default of 22 to 9998. JACKIE is bored by the default password prompt, ralph's password:, and would prefer something more friendly such as Have a nice day!.
In this example, JACKIE's password prompt can be changed on the VMS command line with the following command:
$ SSH /PORT=9998 /OPTION=(PasswordPrompt="Have a nice day!") /USER=RALPH BUS
An alternate solution would involve JACKIE creating a user configuration file that contains all the values in the preceding command line. The file SSH2_CONFIG. would need to be created in JACKIE's SYS$LOGIN:[.SSH2] directory on node FLAT.
The contents of the file would contain:
MYBUS: host bus.example.com port 9998 passwordprompt "Have a nice day!" user ralph
This would simplify the following command:
$ SSH /PORT=9998 /OPTION=(PasswordPrompt="Have a nice day!") /USER=RALPH BUS
to be:
$ SSH MYBUS
If JACKIE needs to connect to node BUS with the username of NORTON, this could be accomplished with the following DCL command:
$ SSH /USER=NORTON MYBUS
SSH Server Troubleshooting Tips
The server can be started with the following command:$ @SYS$STARTUP:PSCSSH$STARTUP
First check for the presence of the process named SSHD Master (use the command SHOW SYSTEM). This process must exist for SSH connections to be made from other computers.
If the process does not exist after executing the command to start the SSH server, here are some suggestions:
Has a host key been generated? Before starting the SSH server, you will need to generate host keys using the following commands:
$ MULTINET SSHKEYGEN/SSH1/HOST to generate SSHv1 host key, and $ MULTINET SSHKEYGEN/SSH2/HOST to generate SSHv2 host key.
Note that you don't need to generate SSH1 host key if you're not going to allow SSH1 sessions and the same for SSH2 host keys and sessions.
Is the SSH server configured to support SSHv1 or SSHv2 or both? If you are trying to connect to the server using SSHv1 and the server is configured for SSHv2 only, it will not work. Check your configuration to determine which version of SSH connections are enabled.
Finally, look at the server log file SSH_DIR:SSHD_MASTER.LOG for hints of something else that can be causing a problem.
SSH2 Public-Key Server and Assistant
This public-key subsystem for SSH2 provides a method of distributing and managing public keys from one system to another. It can be used to add, remove, and list public keys stored on a remote server. The public-key assistant and server are based upon a recent IETF draft, therefore other implementations of SSH may not yet offer this functionality.
The public-key assistant can be started using the following command string:
$ RUN SSH_EXE:PUBLICKEY_ASSISTANT
Following is a list of public-key assistant commands with brief explanations of what each command does:
ADD key_filename
UPLOAD key_filename
Transfers the key file name to the remote system. The file name specified is expected to be in the SSH2_CONFIG directory from the user’s login directory. For example, ADD ID_DSA_1024_A.PUB will transfer the public key in ID_DSA_1024_A.PUB to the remote system and update the AUTHORIZATION. file on the remote system to include this key name.
CLOSE
Closes the connection to the remote system.
DEBUG {no | debug_level}
Sets debug level (like in SFTP2).
DELETE key fingerprint
Deletes the key that matches the fingerprint specified. It is necessary to do a LIST command before issuing this command in order to get a list of the fingerprints (and for the program to build its internal database mapping fingerprints to keys).
EXIT
Exits the program.
HELP
Displays a summary of the commands available.
LIST
Displays the fingerprint and attributes of keys stored on the remote system. The attributes that are listed will vary with the key, as shown in the following example output:
Fingerprint: xozil-bemup-favug-fimid-tohuk- kybic-huloz-fukuc-kuril-gezah-loxex key type: ssh-dss Comment: 1024-bit dsa, doej@taurus.example.com, Wed Feb 04 2004 21:05:40
OPEN [user@]host[#port]
Opens a connection to the public key server subsystem on the remote host specified. (Similar to the OPEN command in SFTP2.)
VERSION [protocol version]
Sets or displays the version of the protocol to use. The default is version 1, which is the private subsystem specified by VanDyke Software (www.vandyke.com). Version 2 is specified in the IETF draft.
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.
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:
$ MULTINET SSHKEYGEN/SSH1/HOST
to generate SSH1 host keys, and
$ MULTINET SSHKEYGEN/SSH2/HOST
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; and all versions of OpenVMS on Itanium.
What versions of HP TCP/IP Services does SSH for OpenVMS support?
SSH for OpenVMS supports any version of TCP/IP Services supported by HP.
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 the SSH2 implementation is based on the V2 protocol. 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 Cipers | SSHv1 | SSHv2 |
|---|---|---|
| 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 SSH_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 ssh_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 ssh_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 http://winscp.sourceforge.net/eng/requirements.php 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.
In SSH for OpenVMS v2.0 and higher, 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 SSH_SFTP_NEWLINE_STYLE logical. 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 SSH_SFTP_ODS2_SRI_ENCODING. ODS5 disks retain case, so SRI encoding is not normally used on these disks. VMS directories contain the extension UNKNOWN can yield to errors in parsing of file specifications. In order to provide a work around for these situations the logical SSH_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 an 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 - 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]jdoe/nopass Generating 1024-bit dsa key pair 8 .oOo.oOo.ooO Key generated. 1024-bit dsa, jdoe@demo.process.com, Tue Apr 18 2006 12:48:50 Private key saved to [.SSH2]JDOE Public key saved to [.SSH2]JDOE.pub
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 jdoe Ctrl+Z
Copy the public key to the server. SCP is used in the example below:
$ scp [.ssh2]jdoe.pub "jdoe@gondor.process.com::jdoe.pub" Keyboard-interactive: Password: jdoe.pub | 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:
key jdoe.pub
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 "jdoe@gondor.process.com" ssh-keygen -i -f jdoe.pub >> .ssh/authorized_keys Keyboard-interactive: Password: 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 "jdoe@gondor.process.com" 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 Ctrl+Z $ sftp/batch_file=sftp.take "jdoe@gondor.process.com" sftp> get file.log file.log | 25B | 0.0 kB/s | TOC: 00:00:01 | 100% sftp> rm file.log sftp> exit
I am setting up sftp with a remote non-VMS system. How do I convert the key format?
Here is some information on public key authentication when the remote side is running OpenSSH.
The keys used by OpenSSH and SSH for OpenVMS are in different formats. You will need to convert the keys to the correct format to use them.
On the Linux side you can use the ssh-keygen -e option to convert OpenSSH keys to the RFC 4716 key file format used by SSH for OpenVMS. Here is an example that converts the default id_rsa.pub key and then copies it to the SSH for OpenVMS system:
# ssh-keygen -ef .ssh/id_rsa.pub > rfc4716.pub # scp rfc4716.pub user@node.example.com:ssh2/rfc4716.pub
Once this is done the authorization file for the user would need to have a key line added to it to use the new key. For example:
key rfc4716.pub
Going the other way you can use the -i option to convert the RFC 4716 to OpenSSH key file format. Here is an example of setting this up:
- Create a new key pair with:
$ mu sshkeygen/ssh2/key=key_for_scp
- Create a
[.ssh2]identification.file that looks like:$ type [.ssh2]identification. idkey key_for_scp $
- Use SCP to copy the key_for_scp.pub file to the other system:
$ mu scp2 [.ssh2]key_for_scp.pub >@server_name::.ssh/key_for_scp.pub"
- Convert the key from RFC 4716 format to an OpenSSH key file and appended it to the authorization file:
$ mu ssh/user=user server_name "ssh-keygen -i -f .ssh/key_for_scp.pub >> .ssh/authorized_keys2"
How can SSH access to an arbitrary account be denied?
Assuming you want to deny all SSH access for an account (i.e., interactive use, remote command execution, and file transfers), you can grant an identifier to the accounts you want to allow access to (or deny access to, depending on how many of each there are), then use the DENYGROUP or ALLOWGROUP keywords in the config file. For example, you can have DenyGroups limabeans in the config file, then for the account(s) you want to restrict, add the rights identifier limabeans to it/them.
How can I avoid the SSHD.LOG file version number reaching 32768?
When an SSH connection is formed, the SSHD Master server process creates an
SSH server process and hands off the connection. The SSH server process
creates a pseudo terminal and runs LOGINOUT.EXE on it to create a session process for carrying out the requested command or handling the interactive session. These activities are logged in an SSHD.LOG file by default,
but over time, this can create problems, as the version number eventually
increments to the maximum value of 32768.
Purging the SSHD.LOG files can be problematic, as those with active
connections will be locked and can't be deleted without closing the related
sessions. In some cases connections can stay active for days or weeks.
There is support available for changing the name of the SSHD log file by
defining a logical name to have a value that specifies the form that the log
file names should take. In MultiNet and SSH for OpenVMS, this logical is
MULTINET_SSH_LOG_FILE.
The logical is defined /SYSTEM and /EXECUTIVE. In the logical's equivalence
value, the following tokens can be used, and will be substituted with the
associated meaning at the time a log file is being created:
%D- date in yyyymmdd format%N- system SCS node name%C- an incrementing sequence number
For example:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_SSH_LOG_FILE "SSH_LOG:SSHD_%N_%D-%C.LOG"
This will result in SSHD log files with names such as SSHD_SYSA_20210901-1.LOG
You are not required to use any of the tokens in this renaming mechanism. If you do use them, you can use just those that you require.
Setting up an alternate naming pattern for the log files should remove the version number limit problem if you incorporate at least the date token. The disadvantage of naming the log files this way is that you have to manage (i.e. delete) old files so that they don't fill up the directory/disk over time. A periodic batch job that deletes logs older than some delta time in the past is one solution.
I can't use public key authorization when SYS$LOGIN: involves a search list
This issue only affects users with SYS$LOGIN: having a search list, and where one or more of the search paths is missing an SSH configuration directory.
When using public key authorization to log in with SSH, SFTP, or SCP, the server needs access to the user's SSH configuration directory (SYS$LOGIN:[.SSH] for SSH1 or SYS$LOGIN:[.SSH2] for SSH2 connections) to read the AUTHORIZATION. file and access the user's key files.
In cases where the user's SYS$LOGIN: involves a search list, such as when connecting as SYSTEM, where SYS$LOGIN translates to SYS$SYSROOT:[SYSMGR] and SYS$SYSROOT can translate into SYS$SYSROOT and SYS$COMMON, there can be problems if each of the paths does not contain an SSH configuration directory. SSH can get a "file not found" error, even though there is an SSH configuration directory in at least one of the paths. This stems from how VMS XQP works and is not directly due to SSH requirements.