TCPware FAQ: SSH
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.
$ netcu 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:
$ netcu 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 "tcpware_ssh2_hostkey_dir:hostkey_ecdsa." PublicHostKeyFile "tcpware_ssh2_hostkey_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.
Is there a way to control who can SSH and who can not?
The AllowHosts, AllowSHosts, DenyHosts, and DenySHosts keywords in the TCPWARE:SSHD_CONFIG. file can be used to control what hosts can access the system. See the Configuration File Keywords table in the Administrator's Guide.
What is the difference between SSH v2 and SSH v1 protocol?
SSH1 and SSH2 are different, and incompatible, protocols. While SSH v2 is generally regarded to be more secure than SSH v1, both protocols are offered by the TCPware SSH 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?
The SFTP client 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 TCPWARE_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 server and VMS transfer mode was not automatically negotiated.
Older versions of the SFTP server 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 TCPWARE_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 TCPWARE_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.
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 can I configure TCPware's SSH server to ignore client connection requests from addresses which are not in some sort of "approved" list?
You can use packet filtering to block those. The following set of rules would only allow connections from the 192.42.95.0/24 subnet and the host 198.115.48.1 -
permit tcp 192.42.95.0 255.255.255.0 0 0 eq 22 permit tcp 198.115.48.1 255.255.255.255 eq 22 drop tcp 0 0 0 0 eq 22
Is there a way to identify whether a user's current interactive session is connected via SSH1 rather than SSH2 so that a message can be displayed?
The existence of the TCPWARE_SSH_PID_DEVICE logical (where PID is the PID of the process) in the LNM$SSH_LOGICALS table indicates the connection is via SSH1 rather than SSH2.
Can you change the port the SSH server listens on?
Yes, perform a @TCPWARE:CNFNET SSH and entering the new port number when prompted.
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 TCPware, the logical is TCPWARE_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.