Previous Page TOC Index Next Page



Chapter 5

Configuring the Secure Shell (SSH) V2 Server

This chapter describes how to configure and maintain the SSH for OpenVMS SSH V2 server.

This is the server side of the SSH software that allows secure interactive connections from other computers in the manner of rlogin/rshell/telnet. The SSH server has been developed to discriminate between SSH v1 and SSH v2 protocols, so the two protocols can coexist simultaneously on the same system.

SSH1 and SSH2 Differences

SSH1 and SSH2 are different, and incompatible, protocols. The SSH1 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 SSH2 is generally regarded to be more secure than SSH1, 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.

Restrictions:

When using SSH to connect to a VMS server, if the VMS account is set up with a secondary password, SSH does not prompt the user for the secondary password. If the VMS primary password entered is valid, the user is logged in, bypassing the secondary password.

When using SSH to execute single commands (in the same manner as RSHELL), some keystrokes like CTRL/Y are ignored. In addition, some interactive programs such as HELP may not function as expected. This is a restriction of SSH. If this behavior poses a problem, log into the remote system using SSH in interactive mode to execute the program.

Understanding the SSH for OpenVMS SSH Server

Secure Shell daemon (SSHD) is the daemon program for SSH that listens for connections from clients. The server program replaces rshell and telnet programs. The server/client programs provide secure encrypted communications between two untrusted hosts over an insecure network. A new daemon is created for each incoming connection. These daemons handle key exchange, encryption, authentication, command execution, and data exchange.

Servers and Clients

An SSH for OpenVMS server is an OpenVMS system that acts as a host for executing interactive commands or for conducting an interactive session. The server software consists of two pieces of software (for future reference, "SSHD" will refer to both SSHD_MASTER and SSHD, unless otherwise specified):

SSHD_MASTER, recognizes the differences between SSH v1 and SSH v2 and starts the appropriate server. If the request is for SSH v1, then the SSH v1 server is run; if the request is for SSH v2, then the SSH v2 server is run.

SSHD, a copy of which is spawned for each connection instance. SSHD handles all the interaction with the SSH client.

A client is any system that accesses the server. A client program (SSH) is provided with SSH for OpenVMS, but any SSH client that uses SSH version 2 protocol may be used to access the server. Examples of such programs are SSH for OpenVMS, MultiNet SSH2 for OpenVMS, TCPware for OpenVMS; SecureCRT®, and F-Secure SSH Client for Windows®, MacSSH for Macintosh® systems, and other SSH programs on UNIX-based systems.

Each host has a key using DSA encryption and is usually 1024 bits long (although, the user may create a different-sized key, if desired). The same key may be used on multiple machines. For example, each machine in a VMS cluster could use the same key.

When a client connects to the SSHD daemon:

The client and server together, using the Diffie-Hellman key-exchange method, determine a 256-bit random number to use as the "session key". This key is used to encrypt all further communications in the session.

Note that this key may be renegotiated between the client and the server on a periodic basis by including the RekeyIntervalSeconds keyword in the server configuration file (SSH2_DIR:SSHD2_CONFIG). This is desirable because during long sessions, the more data that is exchanged using the same encryption key, the more likely it is that an attacker who is watching the encrypted traffic could deduce the session key.

The server informs the client which encryption methods it supports. Currently, AES-128 (the default), Twofish, Blowfish, CAST-128, DES, 3DES, and ARCFOUR are supported by the SSH for OpenVMS system.

The client selects the encryption algorithm from those offered by the server.

The client and the server then enter a user authentication dialog. The server informs the client which authentication methods it supports, and the client then attempts to authenticate the user by using some or all of the authentication methods. The following authentication algorithms are supported:

– public-key (DSA keys)

– hostbased

– password

System security is not improved unless the RLOGIN, RSHELL, and TELNET services are disabled.

If the client authenticates itself successfully, a dialog is entered for preparing the session. At this time the client may request things like:

forwarding X11 connections

forwarding TCP/IP connections

forwarding the authentication agent connection over the secure channel

Finally, the client either requests an interactive session or execution of a command. The client and the server enter session mode. In this mode, either the client or the server may send data at any time, and such data is forwarded to/from the virtual terminal or command on the server side, and the user terminal in the client side. When the user program terminates and all forwarded X11 and other connections have been closed, the server sends command exit status to the client, and both sides exit.

Break-In and Intrusion Detection

Care must be exercised when configuring the SSH clients and server to minimize problems due to intrusion records created by OpenVMS security auditing. The SSH user should consult the system manager to determine the authentication methods offered by the SSH server. The client should then be configured to not attempt any authentication method that is not offered by the server.

If a client attempts authentication methods not offered by the server, the OpenVMS security auditing system may log several intrusion records for each attempt to create a session to that server. The result being that the user could be locked out and prevented from accessing the server system without intervention from the server's system manager.

The authentication methods to be offered by the server are determined by the configuration keywords AllowedAuthentications and RequiredAuthentications. The number of intrusion records to be logged for any attempted SSH session is determined by the StrictIntrusionLogging configuration keyword.

When StrictIntrusionLogging is set to YES (the default), each method that is tried and fails causes an intrusion record to be logged. The following rules apply:

When HostBased or PublicKey authentications are attempted and fail, one intrusion record is logged for each failed method.

When password authentication is attempted, one intrusion record is logged for each failed password.

Example 1:

The server is set up to allow HostBased and password authentication; also, up to three password attempts are allowed. If all methods fail, four intrusion records are logged:

1 for the failed HostBased
3 for the failed password attempts, one per attempt

When StrictIntrusionLogging is set to NO, it has the effect of relaxing the number of intrusions logged. Overall failure of all authentication methods simply counts as a single failure, except for password authentication. The following rules apply:

When password authentication is attempted, one intrusion record is logged for each failed password.

When any of HostBased or PublicKey authentication fails, and password authentication is not attempted, exactly one intrusion record is logged, as opposed to one for each failed method.

When any of HostBased or PublicKey authentication fails, but password authentication is attempted and succeeds, the only intrusion record(s) logged is one for each failed password attempt.

Example 2:

The server is set up to allow HostBased and password authentication; also, up to three password attempts are allowed. If all methods fail, three intrusion records are logged:

0 for the failed HostBased
3 for the failed password attempts, one per attempt

Example 3:

The server is set up to allow HostBased and password authentication; also, up to three password attempts are allowed. HostBased and RSA fail, but password authentication is successful after 1 failed password. Therefore, one intrusion record is logged:

0 for the failed HostBased
1 for the failed password attempt

Example 4:

The server is set up to allow HostBased and PublicKey authentication, but not password authentication. If all methods fail, one intrusion record is logged.

Example 5:

The server is set up to allow HostBased and PublicKey authentication, but not password authentication. HostBased authentication fails, but PublicKey succeeds. No intrusion records are logged.

Configuring SSHD Master

The SSHD Master is configured via CNFSSH. See Chapter 3 of the SSH for OpenVMS Administration and User’s Guide for details on using CNFSSH to configure SSH.

Note! The only supported methods for starting SSH are to use the @SYS$STARTUP:PSCSSH$STARTUP command if SSH isn’t running, or to use the SSHCTRL RESTART command if SSH is currently running.

SSH2 Configuration File

SSHD reads configuration data from its configuration file. By default, this file is SSH2_DIR:SSHD2_CONFIG. However, it may be modified by setting the ssh2-config-file parameter with CNFSSH. The file contains keyword value pairs, one per line. Lines starting with # and empty lines are interpreted as comments. The following keywords are possible. Keywords are case insensitive.

Note! HP’s TCP/IP services do not use the traditional UNIX rhosts and hosts.equiv files; it uses a proprietary format. Therefore, any information added to HP’s files via the "ADD PROXY" command must also be manually added to the SSH_DIR:RHOSTS and SSH_DIR:HOSTS.EQUIV files in order for it to be used by SSH for OpenVMS.

Table 5-1 SSH2 Configuration File Keywords [SSHD2_CONFIG]

Keyword

Value

Default

Description

AllowedAuthentications

List

Publickey, Password

Permitted techniques

AllowGroups

List


Access control by UAF rightslist entries

AllowHosts

Host list


Access control by hostname

AllowShosts

Host list


Access control by hostname

AllowTcpForwarding

Y/N

Y

Enable TCP port forwarding

AllowTcpForwardingForUsers

User list


Per-User forwarding

AllowTcpForwardingForGroups

Rights list


Per-Rightslist ID forwarding

AllowUsers

User list


Access control by username

AllowX11Forwarding

Y/N

Y

Enable X11 forwarding

AuthorizationFile

Filename

Authorization

Authorization file for publickey authentication.

BannerMessageFile

Filename

SYS$ANNOUNCE

Message sent to the client before authentication begins

CheckMail

Y/N

Y

Display information about new mail messages when logging in

Ciphers

Cipher list


Encryption ciphers offered

ClientHostnameDNS



Must match the one in DNS

DenyGroups

Rights list


Deny access for UAF rightslist identifiers

DenyHosts

Host list


Deny access for hosts

DenySHosts

Host list


Deny access for hosts

DenyTcpForwardingForUsers

User list


Forbid forwarding for listed users

DenyTcpForwardingForGroups

Rights list


Forbid forwarding for listed rightslist names

DenyUsers

User list


Access control by username

FascistLogging

Y/N

Y

Verbose logging

ForwardAgent

Y/N

Y

Enable agent forwarding

ForwardX11

Y/N

Y

Enable X11 forwarding

HostbasedAuthForceClientHostnameDNSMatch

Y/N

N

Host name given by client

Hostkeyfile

Filename

Hostkey

Host key filename

IdentityFile

Filename

Identification

Identity filename

IdleTimeout

Time

0 = none

Set idle timeout (in seconds)

IgnoreRhosts

Y/N

N

Ignore local rhosts

IgnoreRootRhosts

Y/N

Y

Ignore system rhosts

KeepAlive

Y/N

Y

Send keepalives

ListenAddress

IP address

0.0.0.0

Listen on given interface

Macs

Algorithm


Select MAC (Message Authentication Code) algorithm

MaxBroadcastsPerSecond

#broadcasts

0

Listen for UDP broadcasts

NoDelay

Y/N

N

Enable Nagel Algorithm

PasswordGuesses

#guesses

3

Limit number of password tries to specified number

PermitEmptyPasswords

Y/N

N

Permit empty (blank) passwords

PermitRootLogin

Y/N

N

SYSTEM can log in

PrintMotd

Y/N

Y

Display SYS$WELCOME when logging in

PublicHostKeyFile

Filename

Hostkey.pub

Host key file location

QuietMode

Y/N

N

Quiet mode

RandomSeedFile

Filename

Random_seed

Random seed file

RekeyIntervalSeconds

#seconds

3600

Frequency of rekeying

RequiredAuthentication

Authentication list


Overrides AllowedAuthentications client must support

RequireReverseMapping

Y/N

N

Remote IP address must map to hostname

RSAAuthentication

Y/N

Y

Enable RSA authentication

StrictIntrusionLogging

Y/N

Y

Determine how intrusion records are created by failed authentication attempts

StrictModes

Y/N

N

Strict checking for directory and file protection

SyslogFacility

Syslog level

"AUTH"

Syslog log facility

UserConfigDirectory

Directory

SYS$LOGIN:

Location of user SSH2 directories

UserKnownHosts

Y/N

Y

Respect user [.ssh2] known hosts keys

VerboseMode

Y/N

N

Verbose mode

X11Forwarding

Y/N

Y

Enable X11 forwarding

The keywords MACs and Ciphers have discrete values, plus there are values that actually denote a grouping of 2 or more of the discrete values. Each of these values may be put in the configuration file (SSH2_DIR:SSHD2_CONFIG).

Table 5-2 MAC and Cipher Discrete Values

MACs

discrete values:

aes, aes128-cbc, aes256-cbc, aes192-cbc, aes128-cbc, hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-ripemd160, hmac-ripemd160-96, sha1-8, sha1, md5-8, md5, ripemd160-8, ripemd160, none


group ANYMAC consists of:

hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-ripemd160, hmac-ripemd160-96, sha1-8, sha1, md5-8, md5, ripemd160-8, ripemd160


group ANY consists of:

hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-ripemd160, hmac-ripemd160-96, sha1-8, sha1, md5-8, md5, ripemd160-8, ripemd160, none


group ANYSTD consists of:

hmac-md5, hmac-md5-96, hmac-sha1, hmac-sha1-96, none


group ANYSTDMAC consists of:

hmac-md5, hmac-md5-96, hmac-sha1, hmac-sha1-96

Ciphers

discrete values:

aes, aes256-cbc, aes192-cbc, aes128-cbc, des, 3des, twofish, blowfish, cast, 3des-cbc, blowfish-cbc, twofish-cbc, arcfour, cast128-cbc, 3des-ecb, 3des-cfb, 3des-ofb, cast128-ecb, cast128-cfb, cast128-ofb, cast128-12-ecb, cast128-12-cbc, cast128-12-cfb, cast128-12-ofb, blowfish-ecb, blowfish-cfb, blowfish-ofb, des-ecb, des-cbc, des-cfb, des-ofb, twofish-ecb, twofish-cfb, twofish-ofb, none


group ANYSTDCIPHER consists of:

aes, aes128-cbc, 3des-cbc, cast128-cbc, blowfish-cbc, twofish-cbc, arcfour, 3des, twofish, blowfish, cast


group ANY consists of:

aes, aes256-cbc, aes192-cbc, aes128-cbc, des, 3des, twofish, blowfish, cast, 3des-cbc, blowfish-cbc, twofish-cbc, arcfour, cast128-cbc, 3des-ecb, 3des-cfb, 3des-ofb, cast128-ecb, cast128-cfb, cast128-ofb, cast128-12-ecb, cast128-12-cbc, cast128-12-cfb, cast128-12-ofb, blowfish-ecb, blowfish-cfb, blowfish-ofb, des-ecb, des-cbc, des-cfb, des-ofb, twofish-ecb, twofish-cfb, twofish-ofb, none


group ANYCIPHER consists of:

aes, aes256-cbc, aes192-cbc, aes128-cbc, des, 3des, twofish, blowfish, cast, 3des-cbc, blowfish-cbc, twofish-cbc, arcfour, cast128-cbc, 3des-ecb, 3des-cfb, 3des-ofb, cast128-ecb, cast128-cfb, cast128-ofb, cast128-12-ecb, cast128-12-cbc, cast128-12-cfb, cast128-12-ofb, blowfish-ecb, blowfish-cfb, blowfish-ofb, des-ecb, des-cbc, des-cfb, des-ofb, twofish-ecb, twofish-cfb, twofish-ofb


group ANYSTD consists of:

aes, aes256-cbc, aes192-cbc, aes128-cbc, 3des-cbc, cast128-cbc, blowfish-cbc, twofish-cbc, arcfour, des, 3des, twofish, blowfish, cast, none

A discrete value or a group identifier may be used with MACS and CIPHERS. For example, in the configuration file, the following examples could be used:

Ciphers

ANYCIPHER

Ciphers

cast, des, twofish

MACs

ANYMAC

MACs

hmac-sha1

Aiases may be used for some standard ciphers:

Alias

Value

aes

aes128-cbc

des

des-cbc

3des

3des-cbc

cast

cast128-cbc

twofish

twofish-cbc

blowfish

blowfish-cbc

arcfour

arcfour

Starting the SSH Server for the First Time

Follow these instructions to configure the SSH server. If SSH isn’t currently running, you must define the MULTINET logicals by using:

$ @SYS$STARTUP:PSCSSH$STARTUP LOGICALS

1 Use CNFSSH to enable the SSH2 server. For more information, see Chapter 3 of the SSH for OpenVMS Administration and User’s Guide.

2 Use SSHKEYGEN /SSH2/HOST to generate an SSH2 key and to create the server key in the MULTINET_SSH2_HOSTKEY_DIR directory if it has not previously been created as part of the CNFSSH configuration:

$ DEFINE MULTINET_SSH_HOSTKEY_DIR -
_$ MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.HOSTKEYS]

$ MULTINET SSHKEYGEN /SSH2/HOST
Generating 1024-bit dsa key pair
8 .oOo.oOoo.oO
Key generated.
1024-bit dsa, lillies@flower.plants.com, Mon Aug 06 2002 09:19:47
Private key saved to multinet_ssh2_hostkey_dir:hostkey.
Public key saved to multinet_ssh2_hostkey_dir:hostkey.pub

3 Edit the configuration file at SSH2_DIR:SSHD2_CONFIG (if you wish to change the default settings). This default configuration is the same as contained in the file MULTINET:SSHD2_CONFIG.TEMPLATE

Note! As delivered, the template file provides a reasonably secure SSH environment. However, Process Software recommends this file be examined and modified appropriately to reflect the security policies of your organization.

4 Start SSH. This creates the SSH server process and defines the SSH logical names.

$ @SYS$STARTUP:PSCSSH$STARTUP
$ SHOW PROCESS "SSHD Master"

7-JUN-2002 09:03:06.42 User: SYSTEM Process ID: 00000057
Node: PANTHR Process name: "SSHD Master"

Terminal:
User Identifier: [SYSTEM]
Base priority: 4
Default file spec: Not available
Number of Kthreads: 1

Devices allocated: BG1:
BG2:

$ SHOW LOGICAL/SYSTEM *SSH*

"MULTINET_SSH2_HOSTKEY_DIR" ="MULTINET_SPECIFIC_ROOT:
[MULTINET.PSCSSH.SSH2.HOSTKEYS]"

"MULTINET_SSH2_KNOWNHOSTS_DIR"=

"MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.KNOWNHOSTS]"

"MULTINET_SSH_ALLOW_EXPIRED_PW"="1"

"MULTINET_SSH_ALLOW_PREEXPIRED_PW"="1"

"MULTINET_SSH_DISPLAY_SYS$ANNOUNCE"="1"

"MULTINET_SSH_ENABLE_SSH1_CONNECTIONS"="1"

"MULTINET_SSH_ENABLE_SSH2_CONNECTIONS"="1"

"MULTINET_SSH_LOG_MBX" = "MBA37"

"MULTINET_SSH_PARAMETERS_0"="/BITS=768/VERBOSE/QUIET/PORT=22"

"MULTINET_SSH_PARAMETERS_1"="/KEY_GEN_TIME=3600"

"MULTINET_SSH_PARAMETERS_2"=""

"MULTINET_SSH_PARAMETERS_3" =""
"SSH2_DIR"=MULTINET__SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2]"
"SSH_DIR"="MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH]"
"SSH_EXE"= MULTINET_COMMON_ROOT:[MULTINET.PSCSSH]"
"SSH_LOG"= MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.LOG"
"SSH_MAX_SESSIONS"="100"

"SSH_TERM_MBX"="MBA36:"

Changing SSH2 Configuration File After Enabling SSH2

$ SSHCTRL RESTART

Note! When issuing the "RESTART" command for SSH, all active SSH server sessions are terminated. Active client sessions are not affected.

Connection and Login Process

To create a session, SSHD does the following:

1 SSHD_MASTER sees the connection attempt. It creates an SSHD process, passing the operating parameters to it. SSHD performs validation for the user.

2 Assuming the login is successful, SSHD creates a pseudo terminal for the user (an FTAnn: device). This device is owned by the user attempting to log in.

3 SSHD creates an interactive process on the pseudo terminal, using the username, priority, and privileges of the user who is attempting to log in. If a command was specified, it is executed and the session is terminated.

4 SSH generates the file SSHD.LOG for each connection to the SSH server. Many connections result in many log files. Instead of purging the files on a regular basis, use the following DCL command to limit the number of versions:

$ SET FILE /VERSION_LIMIT=x SSH_LOG:SSHD.LOG

Note! The value for /VERSION_LIMIT must not be smaller than the maximum number of simultaneous SSH sessions anticipated. If the value is smaller, SSH users may be prevented from establishing sessions with the server.

SSH Files

Note! HP’s TCP/IP services do not use the traditional UNIX rhosts and hosts.equiv files; it uses a proprietary format. Therefore, any information added to HP’s files via the "ADD PROXY" command must also be manually added to the SSH_DIR:RHOSTS and SSH_DIR:HOSTS.EQUIV files in order for it to be used by SSH for OpenVMS.

The following table provides descriptions of the various SSH files:

Table 5-3 SSH Files

File

Description

SSH_DIR:HOSTS.EQUIV

Contains host names, one per line. This file is used during rhosts authentication. Users on those hosts are permitted to log in without a password, provided they have the same username on both machines. The hostname may also be followed by a username. Such users are permitted to log in as any user on the remote machine (except SYSTEM). Additionally, the syntax +@group can be used to specify netgroups. Negated entries start with dash (-). If the client host/user is matched in this file, login is permitted, provided the client and server usernames are the same. Successful RSA host authentication is required. This file should be world-readable but writable only by SYSTEM.

It is never a good idea to use usernames in hosts.equiv. It means the named user(s) can log in as anybody, which includes accounts that own critical programs and directories. Using a username grants the user SYSTEM access. The only valid use for usernames is in negative entries.

Note! This warning also applies to rshell/rlogin.

SSH_DIR:SHOSTS:EQUIV

Processed as SSH_DIR:HOSTS.EQUIV. May be useful in environments that want to run both rshell/rlogin and ssh.

MULTINET_SSH2_HOSTKEY_DIR:HOSTKEY

Contains the private part of the host key. This file does not exist when SSH for OpenVMS is first installed. The SSH server requires this file to exist to start. This file must be created manually using the command:

$ MULTINET SSHKEYGEN /SSH2 /HOST

This file should be owned by SYSTEM, readable only by SYSTEM, and not accessible to others.

To create a host key with a name that is different than what SSHKEYGEN creates, do one of the following:

Generate with SSHKEYGEN /SSH2 /HOST and simply rename the file(s).

Generate without the /HOST switch and then name the file(s) whatever you want.

By default, the logical name SSH2_DIR points to the MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2] directory.

Refer to Chapter 6 of the SSH for OpenVMS Administration and User’s Guide, for more details about SSHKEYGEN.

MULTINET_SSH2_HOSTKEY_DIR:HOSTKEY.PUB

Contains the public part of the host key. This file should be world-readable but writable only by SYSTEM. Its contents should match the private part. This file is not used for anything; it is only provided for the convenience of the user so its contents can be copied to known hosts files

SSH2_DIR:RANDOM_SEED

Seeds the random number generator. This file should not be readable by anyone but SYSTEM.

SYS$LOGIN:[.SSH2]RANDOM_SEED

Seeds the random number generator. This file should not be readable by anyone but the user.

SYS$LOGIN:RHOSTS

This file contains host-username pairs, separated by a space, one per line. The given user on the corresponding host is permitted to log in without a password. The same file is used by rlogin and rshell. SSH2 differs from rlogin and rshell in that it requires RSA host authentication in addition to validating the hostname retrieved from domain name servers (unless compiled with the -with-rhosts configuration option). The file must be writable only by the user. It is recommended that it not be accessible by others. It is possible to use netgroups in the file. Either host or username may be of the form +@groupname to specify all hosts or all users in the group.

SYS$LOGIN:[.SSH2]AUTHORIZATION

This file contains information on how the server verifies the identity of a user.

SYS$LOGIN:[.SSH2.KNOWNHOSTS]xxxxyyyy.pub

These are the public host keys of hosts that a user wants to log in from using "hostbased" authentication (equivalent to the SSH1's "RhostsRSAAuthentication"). Also, a user must set up his/her individual .SHOSTS or .RHOSTS file. If the username is the same in both hosts, it is adequate to put the public host key in the MULTINET_SSH2_KNOWNHOSTS_DIR directory and add the host's name to the system-wide SHOSTS.EQUIV or RHOSTS.EQUIV file.

xxxx is the hostname (FQDN) and yyyy denotes the public key algorithm of the key ("ssh-dss" or "ssh-rsa").

key ("ssh-dss" or "ssh-rsa").

For example flower.plants.com's host key algorithm is "ssh-dss". The hostkey would then be "flower_plants_com_ssh-dss.pub" in the [.SSH2.KNOWNHOSTS] directory.


SSH2 AUTHORIZATION File Format

The Authorization file contains information on how the server verifies the identity of a user. This file has the same general syntax as the SSH2 configuration files, as shown in the following table.

Table 5-4 SSH2 AUTHORIZATION Keywords

Keyword

Description

KEY

The filename of a public key in the [.SSH2] directory in the user's SYS$LOGIN directory. This key is used for identification when contacting the host. If there are multiple KEY lines, all are acceptable for login.

COMMAND

This keyword, if used, must follow the KEY keyword above. This is used to specify a "forced command" that executes on the server side instead of anything else when the user is authenticated. This option might be useful for restricting certain public keys to perform certain operations.


SSH2 Logicals

These logicals are used with the SSH server in the system logical name table.

Table 5-5 SSH2 Logicals

Logical

Description

SSH_DIR

Points to the directory where the master server log file is kept. Normally, this is MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH].

SSH_EXE

Points to the directory where common SSH files are kept. Normally, this is

MULTINET_COMMON_ROOT:[MULTINET.PSCSSH].

SSH_LOG

Points to the directory where the log files are kept. Normally, this is MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.LOG]

MULTINET_SSH_MAX_SESSIONS

Set this to the maximum number of concurrent SSH sessions you want to allow on the server system. If MULTINET_SSH_MAX_SESSIONS is not defined, the default is 1000. Setting MULTINET_SSH_MAX_SESSIONS to zero (0) will cause an error. The value must be between 1 and 1000.

SSH_TERM_MBX

Mailbox used by SSHD_MASTER to receive termination messages from SSHD daemon processes. Do not change this logical name. This is created by the SSHD_MASTER process.

MULTINET_SSH_PARAMETERS_n

These values are set by MultiNet and must not be modified by the user.

MULTINET_SSH_ENABLE_SSH2_CONNECTIONS

Enables SSHD Master to accept SSH V2 sessions.

MULTINET_SSH2_HOSTKEY_DIR

Directory containing the host keys for the SSH V2 server. Normally set to MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2.HOSTKEYS]

MULTINET_SSH2_KNOWNHOSTS_DIR

Directory containing client’s public host keys used for hostbased authentication. Normally set to MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.KNOWNHOSTS]

SSH2_DIR

Contains all SSH V2-specific files, such as configuration files. Normally set to MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2].

SSH daemon Files

These files are used by or created by SSH when you log into a daemon. These files are not to be altered in any way.

Table 5-6 SSH daemon Files

File

Description

SSH_LOG:SSHD.LOG

This log file is created by each SSHD daemon.

SSHD_MASTER.LOG

This log file is created by SSHD_MASTER.

Previous Page TOC Index Next Page