TCPware V5.7 Management Guide
n
Chapter 25
Configuring the Secure Shell (SSH) V1 Server
This chapter describes how to configure and maintain the TCPware Secure
Shell (SSH) server v1.
This is the server side of the software that allows secure interactive
connections to 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.2.0 code
base. While SSH2 is generally regarded to be more secure than SSH1, both
protocols are offered by TCPware for OpenVMS, and although they are
incompatible, they may exist simultaneously on a 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 SSH1 to connect to a VMS server, if the VMS account is set up
with a secondary password, SSH1 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 SSH1 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
SSH1. If this behavior poses a problem, log into the remote system using SSH1
in interactive mode to execute the program.
Understanding the TCPware Secure
Shell Server
Secure Shell daemon (SSHD) is the daemon program for SSH1 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
A TCPware SSH 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 existing 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 TCPware, but any SSH client that uses SSH version 1 protocol may
be used to access the server. Examples of such programs are MultiNet SSH,
TCPware SSH, and FISSH on OpenVMS; SecureCRT and TTSSH on Windows®-based
systems; and other SSH programs on UNIX-based systems.
Security
Each host has a host-specific RSA key (normally 1024 bits) that identifies
the host. Additionally, when the SSHD daemon starts, it generates a server RSA
key (normally 768 bits). This key is regenerated every hour (the time may be
changed in the configuration file) if it has been used, and is never stored on
disk. Whenever a client connects to the SSHD daemon,
• SSHD sends its host and server public keys to the client.
• The client compares the host key against its own database to verify
that it has not changed.
• The client generates a 256 bit random number. It encrypts this
random number using both the host key and the server key, and sends the
encrypted number to the server.
• The client and the server start to use this random number as a
session key which is used to encrypt all further communications in the session.
The rest of the session is encrypted using a conventional cipher. Currently,
IDEA (the default), DES, 3DES, BLOWFISH, and ARCFOUR are supported.
• The client selects the encryption algorithm to use from those
offered by the server.
• The server and the client enter an authentication dialog.
• The client tries to authenticate itself using:
– .rhosts authentication
– .rhosts authentication combined with RSA host
authentication
– RSA challenge-response authentication
– password-based authentication
Note! Rhosts authentication is normally disabled because it is
fundamentally insecure, but can be enabled in the server configuration file, if
desired.
System security is not improved unless the RLOGIN and RSHELL 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.
Options
SSHD can be configured using command-line options or a configuration file.
Command-line options override values specified in the configuration file. The
following configuration file template is in the TCPware kit: SSHD_CONFIG.TEMPLATE.
Note! The recommended method to start the SSHD Master process
is to use the "@TCPWARE:STARTNET SSH" command. All of these options
are set using @TCPWARE:CNFNET SSH.
Configuration File
SSHD reads configuration data from TCPWARE:SSHD_CONFIG (or
the file specified with
/CONFIG_FILE on the command line). 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.
Table 25-1 Configuration File Keywords [SSHD_CONFIG] (Continued)
|
Keyword
|
Value
|
Default
|
Description
|
|
AllowForwardingPort
|
Port List
|
|
Can be followed by any number of port numbers, separated by spaces. Remote
forwarding is allowed for those ports whose number matches one of the
patterns.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range. By default, all port forwardings
are allowed.
|
|
AllowForwardingTo
|
Host/port list
|
|
Can be followed by any number of hostname and port number patterns,
separated by spaces. A port number pattern is separated from a hostname
pattern by a colon. Forwardings from the client are allowed to those hosts
and port pairs whose name and port number match one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns for host names.
Normal name servers are used to map the client’s host into a fully-qualified
host name. If the name cannot be mapped, its IP address is used as the
hostname.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range. By default, all port forwardings
are allowed.
|
|
AllowGroups
|
List
|
|
Can be followed by any number of OpenVMS rights identifier patterns,
separated by spaces. Login is allowed only if the user’s list of rights
identifiers contains an identifier that matches one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns. By default, logins
as all users are allowed.
Note! All other login authentication steps must be completed
successfully.
DenyGroups is an additional restriction.
|
|
AllowHosts
|
Host list
|
|
Can be followed by any number of host name patterns, separated by spaces.
Login is allowed only from hosts whose name matches one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns. Normal name servers
are used to map the client’s host into a fully-qualified host name. If the
name cannot be mapped, its IP address is used as the hostname. By default,
all hosts are allowed to connect.
|
|
AllowSHosts
|
Host list
|
|
Can be followed by any number of host name patterns, separated by spaces.
.SHOSTS (and .RHOSTS and SSH_DIR:HOSTS.EQUIV) entries are honored for hosts
whose name matches one of the patterns. Servers are used to map the client’s
host into a fully-qualified host name. If the name cannot be mapped, its IP
address is used as the host name. By default, all hosts are allowed to
connect.
|
|
AllowTcpForwarding
|
Y/N
|
Y
|
Specifies whether TCP forwarding is permitted. The default is
"yes".
Note! Disabling TCP forwarding does not improve security in
any way, as users can always install their own forwarders.
|
|
AllowUsers
|
User list
|
|
Can be followed by any number of user name patterns or user@host patterns,
separated by spaces. Host name may be either the DNS name or the IP address.
Login is allowed only for users whose name matches one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns. By default, logins
as all users are allowed.
Note! All other login authentication steps must be completed
successfully.
DenyUsers is an additional restriction.
|
|
DenyForwardingPort
|
Port list
|
|
Can be followed by any number of port numbers, separated by spaces. Remote
forwardings are disallowed for those ports whose number matches one of the
patterns.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range.
|
|
DenyForwardingTo
|
Host/port list
|
|
Can be followed by any number of hostname and port number patterns,
separated by spaces. A port number pattern is separated from a hostname by a
colon. Forwardings from the client are disallowed to those hosts and port
pairs whose name and port number match one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns for host names.
Normal name servers are used to map the client’s host into a fully-qualified
host name. If the name cannot be mapped, its IP address is used as a host
name.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range.
|
|
DenyGroups
|
Rights list
|
|
Can be followed by any number of OpenVMS rights
identifier patterns, separated by spaces. Login is disallowed only if the
user’s list of rights identifiers contains an identifier that matches one of
the patterns.
|
|
DenyHosts
|
Host list
|
|
Can be followed by any number of host name patterns, separated by spaces.
Login is disallowed from the host whose name matches any of the patterns.
|
|
DenySHosts
|
Host list
|
|
Can be followed by any number of host name
patterns, separated by spaces. .SHOSTS (and .RHOSTS and SSH_DIR:HOSTS.EQUIV)
entries whose name matches any of the patterns are ignored.
|
|
DenyUsers
|
User list
|
|
Can be followed by any number of user name
patterns or user@host patterns, separated by spaces. A host name may be
either the DNS name or the IP address. Login is disallowed a user whose name
matches any of the patterns.
|
|
HostKey
|
Filename
|
SSH_HOST_KEY
|
Specifies the file containing the private key. The default is
TCPWARE:SSH_HOST_KEY.
|
|
IdleTimeout
|
Time
|
0
|
Sets the idle timeout limit in:
• seconds (s or nothing after the number)
• minutes (m)
• hours (h)
• days (d)
• weeks (w)
If the connection has been idle (all channels) for the time specified, the
process is terminated and the connection is closed. The default is zero; it
never times out.
An idle process is one that has done no I/O to stdin or stdout in the
timeout value.
|
|
IgnoreRhosts
|
Y/N
|
N
|
Specifies that the SYS$LOGIN:RHOSTS file will not be used in
authentication. SSH_DIR:HOSTS.EQUIV is still used. The default is no.
|
|
KeepAlive
|
Y/N
|
Y
|
Specifies whether the system should send keepalive
messages to the other side. If sent, termination of the connection or crash
of one of the machines will be noticed. This means that connections will
terminate if the route is down temporarily.
If keepalives are not ended, sessions may hang indefinitely on the server,
leaving "ghost" users and consuming server resources.
The default is yes (to send keepalives), and the server will notice if the
network goes down or the client host reboots. This avoids infinitely hanging
sessions.
To disable keepalives, set the value to no in both the server and the
client configuration files.
|
|
KeyRegenerationInterval
|
Time
|
3600
|
Specifies how long to wait before the server key is
regenerated automatically. Regeneration prevents decrypting captured sessions
by later breaking into the machine and stealing the keys. The key is never
stored on disk. If the value is 0, the key is never regenerated. The default
is 3600 seconds.
|
|
ListenAddressee
|
|
|
Specifies the IP address of the interface where the SSHD server socket is BIND.
|
|
LoginGraceTime
|
Time
|
600
|
Specifies the time the server should disconnect if the user has not logged
in successfully. If the value is 0, there is no time limit. The default is
600 seconds.
|
|
PasswordAuthentication
|
Y/N
|
Y
|
Specifies whether password authentication is allowed. The
default is yes.
|
|
PermitEmptyPasswords
|
Y/N
|
N
|
Specifies whether the server allows login to accounts with empty password
strings when password authentication is allowed. The default is no.
Note! Use of this keyword may contribute to your system
becoming unsecure. Process Software encourages you to NOT enable the use of empty passwords.
|
|
PermitRootLogin
|
Y/N
|
N
|
Specifies whether the user can log in as SYSTEM using SSH. This keyword
may be set to:
yes allows SYSTEM logins through any of the authentication types allowed
for other users.
no (default) disables SYSTEM logins through any of the authentication
methods (nopwd and no are equivalent), unless you have a rhosts or
SYS$DISK:[<login_dir>.SSH]AUTHORIZED_KEYS file in the SYS$MANAGER
directory.
nopwd disables password-authenticated SYSTEM logins.
System login with RSA authentication when the "command" option
has been specified is allowed regardless of the value of this keyword (which
may be useful for taking remote backups even if SYSTEM login is not allowed).
|
|
QuietMode
|
Y/N
|
N
|
Specifies whether the system runs in quiet mode. In quiet mode, nothing is
logged in the system log, except fatal errors. The default is no.
|
|
RandomSeed
|
Filename
|
Random_seed
|
Specifies the file containing the random seed for the server. This file is
created automatically and updated regularly. The default is
SSH_DIR:SSH_RANDOM_SEED.
|
|
RhostsAuthentication
|
Y/N
|
N
|
Specifies whether authentication using SYS$LOGIN:RHOSTS or
SSH_DIR:HOSTS.EQUIV files is sufficient. Normally, this method should not be
permitted because it is insecure. Use RhostsRSAAuthentication because it
performs RSA-based host authentication in addition to normal rhosts or
SSH_DIR:HOSTS.EQUIV authentication. The default is no.
|
|
RhostsRSAAuthentication
|
Y/N
|
Y
|
Specifies whether SYS$LOGIN:RHOSTS or SSH_DIR:HOSTS.EQUIV authentication
together with successful RSA host authentication is allowed.
The default is yes.
|
|
RSAAuthentication
|
Y/N
|
Y
|
Specifies whether pure RSA authentication is allowed. The default is yes.
|
|
SilentDeny
|
|
|
Specifies whether denied (or not allowed) connections are denied silently
(just close the connection, no logging, etc.) or if they are closed cleanly
(send an error message and log the connection attempt). Defaults to silent
mode, yes.
|
|
StrictIntrusionLogging
|
Y/N
|
N
|
Determine how intrusion records are created by failed authentication
attempts
|
|
StrictModes
|
Y/N
|
N
|
Specifies whether SSH should check file protection and ownership of the
user’s home directory and rhosts files before accepting
login. The default is yes.
|
|
SyslogFacility
|
Syslog level
|
"AUTH"
|
Gives the facility code that is used when logging messages from SSHD. The
values are: DAEMON (default), AUTH, USER, LOCAL0, LOCAL1, LOCAL2, LOCAL3,
LOCAL4, LOCAL5, LOCAL6, LOCAL7.
|
|
X11DisplayOffset
|
#offset
|
10
|
Specifies the first display number available for SSHD’s X11 forwarding.
This prevents SSHD from interfering with real X11 servers.
|
Starting
the SSH Server for the First Time
Follow these instructions for using SSH for the first time.
1 Use the TCPware CNFNET utility to configure the SSH server.
Note! TCPware must be running before issuing the SSHKEYGEN
command.
2 Use SSHKEYGEN to create the file SSH_HOST_KEY in the TCPWARE:
directory.
$ SSHKEYGEN/SSH1/HOST
Initializing random number generator...
Generating p: ...++ (distance 64)
Generating q: .......................................++ (distance 516)
Computing the keys...
Testing the keys...
Key generation complete.
Key file will be TCPWARE_ROOT:[TCPWARE]SSH_HOST_KEY
Your identification has been saved in TCPWARE:SSH_HOST_KEY.
Your public key is:
1024 37
1210318365576698697865367869291969476388228444969905611864276308
9072776904462744415966821020109463617644202397294642277946718549
4404442577594868297087171013359743853182442579923801302020844011
5343754909847513973160249324735913146330232410424936751015953611
18716872491123857940537322891584850459319961275605927
SYSTEM@gg1.prr.com
Your public key has been saved in TCPWARE_ROOT:[TCPWARE]SSH_HOST_KEY.pub
3 Review the SSH1 server configuration file, SSH_DIR:SSHD_CONFIG,
making any appropriate modifications. As delivered, the configuration file
provides a reasonably secure SSH environment.
4 Restart SSH. This creates the SSH server process and defines the
SSH logical names.
$ @TCPWARE:STARTNET SSH
$ SHOW PROCESS "SSHD Master"
7-JUL-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*
"SSH2_DIR" ="TCPWARE_SPECIFIC:[TCPWARE.SSH2]"
"SSH_DIR" = "TCPWARE_SPECIFIC:[TCPWARE]"
"SSH_EXE" = "TCPWARE_COMMON:[TCPWARE]"
"SSH_LOG" = "TCPWARE_SPECIFIC:[TCPWARE.SSH]"
"SSH_MAX_SESSIONS"= "100"
"SSH_TERM_MBX" = "MBA286:"
"TCPWARE_SSH2_HOSTKEY_DIR" =
"TCPWARE_SPECIFIC:[TCPWARE.SSH2.HOSTKEYS]"
"TCPWARE_SSH2_KNOWNHOSTS_DIR" =
"TCPWARE_SPECIFIC:[TCPWARE.SSH2.KNOWN
HOSTS]"
"TCPWARE_SSH_ALLOW_EXPIRED_PW" = "1"
"TCPWARE_SSH_ALLOW_PREEXPIRED_PW" = "1"
"TCPWARE_SSH_DISPLAY_SYS$ANNOUNCE" = "1"
"TCPWARE_SSH_ENABLE_SSH1_CONNECTIONS" = "1"
"TCPWARE_SSH_ENABLE_SSH2_CONNECTIONS" = "1"
"TCPWARE_SSH_LOG_MBX" = "MBA287"
"TCPWARE_SSH_PARAMETERS_0" = "/BITS=768/QUIET/PORT=22"
"TCPWARE_SSH_PARAMETERS_1" = "/KEY_GEN_TIME=3600"
"TCPWARE_SSH_PARAMETERS_2" = "/DEBUG=4"
"TCPWARE_SSH_PARAMETERS_3" = ""
Changing SSH Configuration File
After Enabling SSH
If you make a change to the SSH configuration file after you have enable SSH,
you have to restart SSH. To have the changes take effect, use the command:
$ @TCPWARE:RESTART SSH
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 necessary information to it, such as the server
key and operating parameters.
2 SSHD performs validation for the user.
3 Assuming the login is successful, SSHD creates a pseudoterminal for
the user (an _FTAnn: device). This device is owned by the user attempting to
log in.
4 SSHD creates an interactive process on the pseudoterminal,
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.
5 SSH generates the file SSH_LOG: 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.
AUTHORIZED_KEYS File Format
The SYS$DISK:[<login_dir>.SSH]AUTHORIZED_KEYS file lists the RSA keys that are permitted for RSA authentication. Each line of
the file contains one key (empty lines and lines starting with a ‘#’ are
comments and ignored). Each line consists of the following fields, separated by
spaces:
Table 25-2 RSA Keys
|
Key
|
Description
|
|
bits
|
Is the length of the key in bits.
|
|
comment
|
Not used for anything (but may be convenient for the user to identify the
key).
|
|
exponent
|
Is a component used to identify and make up the key.
|
|
modulus
|
Is a component used to identify and make up the key.
|
|
options
|
Optional; its presence is determined by whether the line starts with a
number or not (the option field never starts with a number.)
|
Note! Lines in this file are usually several hundred
characters long (because of the size of the RSA key modulus). You do not want
to type them in; instead, copy the IDENTITY.PUB file and edit it. The options
(if present) consists of comma-separated option specifications. No spaces are
permitted, except within double quotes. Option names are case insensitive.
The following option specifications are supported:
Table 25-3 RSA Key File [AUTHORIZED_KEYS] (Continued)
|
Option Specification
|
Description
|
|
Allowforwardingport="<port list>"
|
Can be followed by any number of port numbers, separated by spaces. Remote
forwarding is allowed for those ports whose number matches one of the
patterns.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range. By default, all port forwardings
are allowed.
The quotes (" ") are required. The <> show a list. Do not
use the < > in the specification. For example:
allowforwardingport "2,52,2043"
|
|
Allowforwardingto="<hostname and port list>"
|
Can be followed by any number of hostname and port
number patterns, separated by spaces. A port number pattern is separated from
a hostname pattern by a colon. For example: hostname:port
Forwardings from the client are allowed to those hosts and port pairs
whose name and port number match one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns for host names.
Normal name servers are used to map the client’s host into a fully-qualified
host name. If the name cannot be mapped, its IP address is used as the
hostname.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range. By default, all port forwardings
are allowed.
|
|
command="command"
|
Specifies the command to be executed whenever this key is used for
authentication. The user-supplied command (if any) is ignored. You may
include a quote in the command by surrounding it with a backslash (\). Use
this option to restrict certain RSA keys to perform just a specific
operation. An example might be a key that permits remote backups but nothing
else. Notice that the client may specify TCP/IP and/or X11 forwardings unless
they are prohibited explicitly.
|
|
Denyforwardingport="<port list>"
|
Can be followed by any number of port numbers, separated by spaces. Remote
forwardings are disallowed for those ports whose number matches one of the
patterns.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range.
|
|
Denyforwardingto="<hostname port list>"
|
Can be followed by any number of hostname and port
number patterns, separated by spaces. A port number pattern is separated from
a hostname by a colon. For example: hostname:port number pattern
Forwardings from the client are disallowed to those hosts and port pairs
whose name and port number match one of the patterns.
You can use ‘*’ and ‘?’ as wildcards in the patterns for host names.
Normal name servers are used to map the client’s host into a fully-qualified
host name. If the name cannot be mapped, its IP address is used as a host
name.
You can use ‘*’ as a wildcard entry for all ports.
You can use these formats ‘>x’, ‘<x’, and ‘x_x’ to specify greater
than, less than, or inclusive port range.
|
|
from="pattern-list"
|
In addition to RSA authentication, specifies that the fully-qualified name
of the remote host must be present in the comma-separated list of patterns.
You can use ‘*’ and ‘?’ as wildcards.
The list may contain patterns negated by prefixing them with ‘!’; if the
fully-qualified host name matches a negated pattern, the key is not accepted.
This option increases security. RSA authentication by itself does not
trust the network or name servers (but the key). However, if somebody steals
the key, the key permits login from anywhere in the world. This option makes
using a stolen key more difficult because the name servers
and/or routers would have to be comprised in addition to just the key.
|
|
idle-timeout=time
|
Sets the idle timeout limit to a time in seconds (s or nothing after the
number), in minutes (m), in hours (h), in days (d), or in weeks (w). If the
connection has been idle (all channels) for that time, the process is
terminated and the connection is closed.
|
|
no-agent-forwarding
|
Forbids authentication agent forwarding when used for authentication.
|
|
no-port-forwarding
|
Forbids TCP/IP forwarding when used for authentication. Any port forward
requests by the client will return an error. For example, this might be used
in connection with the command option.
|
|
no-X11-forwarding
|
Forbids X11 forwarding when used for authentication. Any X11 forward
requests by the client will return an error.
|
RSA Key File Examples
1024 33 12121...312314325 ylo@foo.bar
from="*.emptybits.com,!sluf.psccos.com"
1024 35 23...2334 ylo@niksula
command="dir *.txt",no-port-forwarding
1024 33 23...2323 xxxxx.tazm.com
allowforwardingport="localhost:80"
1024 35 23...2334 www@localhost
SSH_KNOWN_HOSTS File Format
The TCPWARE:SSH_KNOWN_HOSTS and SYS$DISK:[<login_dir>.SSH]KNOWN_HOSTS
files contain host public keys for all known hosts. The global file should be
prepared by the administrator (optional), and the per-user file is maintained
automatically; whenever the user connects to an unknown host its key is added
to the per-user file. Each line in these files contains the following fields:
hostnames, bits, exponent, modulus, comment. The fields are separated by
spaces.
Hostnames is a comma-separated list of patterns ('*' and '?' act as
wildcards). Each pattern is matched against the fully-qualified host names
(when authenticating a client) or against the user-supplied name (when
authenticating a server). A pattern may be preceded by '!' to indicate
negation; if the hostname matches a negated pattern, it is not accepted (by
that line) even if it matched another pattern on the line.
Bits, exponent, and modulus are taken directly from the host key. They can
be obtained from TCPWARE:SSH_HOST_KEY.PUB. The optional comment field continues
to the end of the line, and is not used. Lines starting with '#' and empty
lines are ignored as comments. When performing host authentication,
authentication is accepted if any matching line has the proper key.
It is permissible (but not recommended) to have several lines or different
host keys for the same names. This happens when short forms of host names from
different domains are put in the file. It is possible that the files contain
conflicting information. Authentication is accepted if valid information can be
found from either file.
Note! The lines in these files are hundreds of characters
long. Instead of typing in the host keys, generate them by a script or by
copying TCPWARE:SSH_HOST_KEY.PUB and adding the host names at the front.
Example
closenet,closenet.hut.fi,...,130.233.208.41
1024 37 159...93 closenet.hut.fi
FILES
Table 25-4 SSH Files (Continued)
|
File Name
|
Description
|
|
TCPWARE: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 '-'. 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.
|
|
TCPWARE:SHOSTS.EQUIV
|
Processed as TCPWARE:HOSTS.EQUIV. May be useful in environments that want
to run both rshell/rlogin and ssh.
|
|
TCPWARE:SSH_HOST_KEY
|
Contains the private part of the host key. This file does
not exist when TCPware is installed. The SSH server starts only with this
file. This file must be created manually using the command: $ NETCU
SSHKEYGEN/SSH1/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 NETCU SSHKEYGEN/SSH1/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 SSH_DIR points to the same directory as
TCPWARE:.
Refer to the TCPware for OpenVMS User’s Guide, Chapter 16,
"Accessing Remote Systems with the Secure Shell (SSH) Utilities"
for more details about SSHKEYGEN.
|
|
TCPWARE:SSH_HOST_KEY.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.
|
|
TCPWARE:SSH_KNOWN_HOSTS
SYS$DISK:[<login_dir>.SSH]KNOWN_HOSTS
|
Checks the public key of the host. These files are
consulted when using rhosts with RSA host authentication. The key must be
listed in one of these files to be accepted. (The client uses the same files
to verify that the remote host is the one you intended to connect.) These
files should be writable only by SYSTEM (the owner). TCPWARE:SSH_KNOWN_HOSTS
should be world-readable, and [.SSH]KNOWN_HOSTS can, but need not be,
world-readable.
|
|
TCPWARE:SSH_RANDOM_SEED
|
Contains a seed for the random number generator. This
file should only be accessible by system. The file SSH_RANDOM_SEED. has the
potential for increasing its number of versions. SSH_RANDOM_SEED. is created
in the SSH_DIR:(TCPWARE:) directory as well as in individual user accounts in
the SYS$LOGIN:[.SSH] directory.
This DCL command limits the number of versions of this file in the TCPWARE
directory:
SET FILE VERSION_LIMIT=x TCPWARE:SSH_RANDOM_SEED.
This DCL command limits the number of versions of this file in the user's
SYS$LOGIN:[.SSH]directory.
SET FILE VERSION_LIMIT=x SYS$LOGIN:[.SSH]SSH_RANDOM_SEED.
or
CREATE /DIRECTORY /VERSION_LIMIT=x SYS$LOGIN:[.SSH]SSH_RANDOM_SEED.
|
|
TCPWARE:SSHD_CONFIG
|
Contains configuration data for SSHD. This file should be writable by
system only, but it is recommended (though not necessary) that it be
world-readable.
|
|
SYS$DISK:[<login_dir>.SSH]AUTHORIZED_KEYS
|
Lists the RSA keys that can be used to log into the user's account. This
file must be readable by system (which may on some machines imply it being
world-readable). It is recommended that it not be accessible by others. The
format of this file is described above.
|
|
SYS$LOGIN:.SHOSTS
|
Permits access using SSH only. For SSH, this file is the same as for
.rhosts. However, this file is not used by rlogin and rshell daemon.
|
|
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. SSH 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 -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.
|
SSH Logicals
These logicals are used with the SSH server in the system logical name
table.
Table 25-5 SSH Logicals (Continued)
|
Logical
|
Description
|
|
SSH_DIR
|
Points to the directory where the master server log file is kept.
Normally, this is TCPWARE_SPECIFIC:[TCPWARE].
|
|
SSH_EXE
|
Points to the directory where SSH executables are kept. Normally, this is
TCPWARE_COMMON:[TCPWARE].
|
|
SSH_LOG
|
Points to the directory where the log files are kept. Normally, this is
TCPWARE_SPECIFIC:[TCPWARE.SSH].
|
|
SSH_MAX_SESSIONS
|
Set this to the maximum number of concurrent SSH sessions you want to
allow on the server system. If SSH_MAX_SESSIONS is not defined, the default
is 9999. Setting SSH_MAX_SESSIONS to zero (0) will cause an error. The value
must be between 1 and 9999. It is defined through @TCPWARE:CNFNET SSH. The
configuration procedure should write these to the common configuration file
and check the values at start up and delete them at shutdown.
|
|
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.
|
|
TCPWARE_SSH_ALLOW_EXPIRED_PW
|
Allows logging in to an account when the account's password has expired
due to pwdlifetime elapsing. This applies to all users and
circumvents normal VMS expired-password checking, and therefore should be
used with caution. An entry is made into the SSH_LOG:SSHD.LOG file when
access is allowed using this logical name.
|
|
TCPWARE_SSH_ALLOW_PREEXPIRED_PW
|
Allows logging in to an account when the password has been pre-expired.
This applies to all users and circumvents normal VMS expired-password
checking, and therefore should be used with caution. An entry is made into
the SSH_LOG:SSHD.LOG file when access is allowed using this logical name.
|
|
TCPWARE_SSH_KEYGEN_MIN_PW_LEN
|
Defines the minimum passphrase length when one is to be set in SSHKEYGEN.
If not defined, defaults to zero.
|
|
TCPWARE_SSH_PARAMETERS_n
|
These parameters are used to start SSHD_MASTER. They are parameters set by
@TCPWARE:CNFNET SSH.
|
|
TCPWARE_SSH_USE_SYSGEN_LGI
|
If defined, causes SSHD to use the VMS SYSGEN value of LGI_PWD_TMO to set
the login grace time, overriding anything specified in the command line or
the configuration file.
|
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 25-6 SSH daemon Files (Continued)
|
File Name
|
Description
|
|
SSHD_MASTER.LOG
|
This log file is created by SSHD_MASTER.
|
|
SSHD.LOG
|
This log file is created by each SSHD daemon.
|
