ssh-server-config — SSH Tectia Server configuration file format
The SSH Tectia Server configuration file ssh-server-config.xml
is a valid XML file.
On Unix, the file is stored in the
/etc/ssh2/
directory. The XML DTD can be found in the
/etc/ssh2/ssh-tectia/auxdata/ssh-server-ng
directory.
On Windows, the file is stored by default in the
"C:\Program Files\SSH Communications Security\SSH Tectia\SSH Tectia Server
" directory. The XML DTD can be found in
the "C:\Program Files\SSH Communications Security\SSH Tectia\SSH Tectia AUX\ssh-server-ng
"
directory.
If the configuration file cannot be found or some of the elements are
missing, hardcoded default values are used. The default values
are specified in the ssh-server-config-default.xml
file in
the same directory with the configuration file. However, this default
configuration file is not actually read. It only shows the hardcoded
system defaults.
In addition, an example configuration file
ssh-server-config-example.xml
can be found in the same
directory with the configuration file. This file contains useful
examples of the various configuration options.
The configuration file is divided in four blocks:
general server parameters (params
)
connection rules and encryption methods (connections
)
authentication rules and methods (authentication-methods
)
service rules (services
)
In the connections
and authentication-methods
blocks, different selectors can be used to set
access rules to users based on the user parameters such as username or
location. Users can be divided to groups dynamically, for example, based
on the authentication method they used when logging in. In the
services
block, each group can then be allowed or denied
services such as tunneling, file transfer, and terminal access.
Note | |
---|---|
The configuration file is read in top-down order during connection setup. If a connection is denied in one of the blocks, the connection setup phase ends immediately and the rest of the configuration file is not read. |
This section describes the options available in the SSH Tectia Server configuration file. See Appendix B for more information on the syntax of the configuration file.
The connection settings can be changed based on selectors in the configuration file. Using selectors makes it possible, for example, to:
allow/deny connections from certain IP addresses
require different authentication methods based on username or group
restrict access based on a certificate field
Selectors are used in the connections
,
authentication-methods
, and services
blocks.
The different selector attributes are specified as sub-elements of the
selector
element. The following sub-elements are
available:
certificate
: Matches to a pattern in a specified field of the user certificate.
host-certificate
: Matches to a pattern in a specified field of the client host certificate.
interface
: Matches to the server listener interface ID or address/port.
ip
: Matches to the IP address or FQDN of the client.
publickey-passed
: Matches if the authentication is passed using a public key.
user
: Matches to a user name or ID.
user-group
: Matches to a user group name or ID.
user-password-change-needed
(Unix): Matches if the user password has expired and should be changed.
user-privileged
: Matches based on the user privilege status (yes/no).
In the connections
block, only the interface
and ip
selectors can be used. In the authentication-methods
and services
blocks, all selectors can be used.
When a parent element contains multiple child elements with
selectors, the first functional child element matched is used, and
the rest are ignored. For example, if the connections
element has multiple connection
child elements, but the
first one has an empty selector, or no selectors at all, that
connection
element always matches and the remaining ones are
never used.
On Windows domain environment, the user
and
user-group
selectors have a length limitation.
For more information, see the description of option
User in
Configuration Tool (Windows).
Simple wild cards can be used inside selector values.
An asterisk (*
) matches any string. A question mark
(?
) matches any character. A dash (-
) can be
used to specify a range.
For example, the following selector matches to usernames
jdoe
and jdox
, but not to
jdoel
:
<selector> <user name="jdo?" /> </selector>
For example, the following selector matches to IP addresses
between 192.168.0.42
and 192.168.0.82
:
<selector> <ip address="192.168.0.42-192.168.0.82" /> </selector>
Multiple selector
elements are in an OR relation (one
of the selector elements must match for the parent element to match).
For example, the following block matches if either the IP address is
192.168.0.3
or the user ID is 1001
:
<selector> <ip address="192.168.0.3" /> </selector> <selector> <user id="1001" /> </selector>
Selector attributes in the same selector
element are
normally in an AND relation (all attributes must match for the element
to match). For example, the following block matches if both the IP
address is 192.168.0.3
and the user ID is
1001
:
<selector> <ip address="192.168.0.3" /> <user id="1001" /> </selector>
However, selector attributes in the same selector
element matching to the same attribute type are in an OR relation to
each other. The following three examples produce the same result, either
the username exa
or mple
matches:
<selector> <user name="exa" /> <user name="mple" /> </selector> <selector> <user name="exa" /> </selector> <selector> <user name="mple" /> </selector> <selector> <user name="exa,mple" /> </selector>
An empty selector always matches:
<selector />
Also, typically, if an element accepts selectors, but none are given, the element is assumed to have an empty selector, which will then always match.
Normally when the server tries to match to a selector attribute for which the respective data has not been defined (the data is not available to the server), the selector matching process ends in error, effectively terminating the connection attempt. This happens, for example, in the following cases:
Other selectors than ip
and
interface
are erroneously used in the connections
block. Only the IP address of the client and the connected listener
interface are available to the server in that stage of connection. For
example, the username is not yet known.
The certificate
selector is erroneously used
without previously requiring public-key authentication. The server will not
have user certificate data unless it has received it first during public-key
authentication.
The host-certificate
selector is erroneously
used without previously requiring host-based authentication. The server will
not have host certificate data unless it has received it first during
host-based authentication.
The certificate
or host-certificate
selector is used to match to a field that does not exist in the
certificate.
The user-privileged
selector is used
in the authentication-methods
block on a Windows
server and the user is logging in using a domain
account and does not yet have an access token allocated.
The allow-undefined
attribute can be used in all
selector sub-elements to control this behavior. Its value must be
yes
or no
. If set to yes
, the
undefined data is treated as non-matched and the matching continues to
other elements. The default is no
(trying to match
undefined data results in termination of the connection).
For example, encountering the following selector causes the
connection attempt to end in failure if the certificate is not available
or does not contain the altname-email
field:
<selector> <certificate field="altname-email" pattern="%username%@ssh.com" /> </selector>
The following selector simply does not match when the certificate
does not exist or does not contain the altname-email
field,
and the processing continues with the next block:
<selector> <certificate field="altname-email" pattern="%username%@ssh.com" allow-undefined="yes" /> </selector>
The server configuration file is a valid XML file and starts with the Document Type Declaration.
The root element in the configuration file is secsh-server
.
It can include params
, connections
,
authentication-methods
, and services
elements.
An example of an empty configuration file is shown below:
<!DOCTYPE secsh-server SYSTEM "../auxdata/ssh-server-ng/ssh-server-ng-config-1.dtd"> <secsh-server> <params /> <connections> <connection /> </connections> <authentication-methods /> <services> <rule /> </services> </secsh-server>
Note | |
---|---|
It is not mandatory to include all elements in the
configuration file. If an element is missing the default values shown in
the |
params
BlockThe params
block defines the general server
parameters, such as the location of the host key file, the listen
address, logging, connection limits, and certificate validation
settings.
This element selects the cryptographic library mode to be used.
Either the standard version (standard
) or the FIPS 140-2
certified version (fips
) of the crypto library can be
used. The library name is given as a value of the mode
attribute. By default, standard crypto libraries are used.
<crypto-lib mode="standard" />
In the FIPS mode, the cryptographic operations are performed
according to the rules of the FIPS 140-2 standard. The FIPS library
includes the
3des-cbc
,
aes128-cbc
,
aes192-cbc
,
and
aes256-cbc
ciphers and the
hmac-sha1
MAC.
Note | |
---|---|
Setting the FIPS mode does not prevent using algorithms from crypto plugins. For example, CryptiCore can be used even when the main crypto library is set in the FIPS mode. To enforce that only FIPS-compliant algorithms are used, disable the non-FIPS algorithms from the configuration. See cipher and mac. |
For a list of platforms on which the FIPS library has been validated or tested, see SSH Tectia Client/Server Product Description.
This element contains miscellaneous settings. It has the following attributes:
proxy-scheme
, xauth-path
, ignore-aix-rlogin
,
record-ptyless-sessions
and user-config-dir
.
The proxy-scheme attribute defines rules for HTTP or SOCKS proxy servers that SSH Tectia Server uses when a client forwards a connection (local tunnel).
The format of the attribute value is a sequence of rules
delimited by semicolons (;
). Each rule has a format
that resembles the URL format. In a rule, the connection type is
given first. The type can be direct
,
socks
, socks4
, socks5
, or
http-connect
(socks
is a synonym for
socks4
). This is followed by the server address and
port. If the port is not given, the default ports 1080 for SOCKS and
80 for HTTP are used.
After the address, zero or more conditions delimited by commas
(,
) are given. The conditions can specify IP addresses
or DNS names.
direct:///[cond[,cond]...] socks://server/[cond[,cond]...] socks4://server/[cond[,cond]...] socks5://server/[cond[,cond]...] http-connect://server/[cond[,cond]...]
The IP address/port conditions have an address pattern and an optional port range:
ip_pattern[:port_range]
The ip_pattern
may have one of the following forms:
a single IP address x.x.x.x
an IP address range of the form x.x.x.x-y.y.y.y
an IP sub-network mask of the form x.x.x.x/y
The DNS name conditions consist of a hostname which may be a regular expression containing the characters "*" and "?" and a port range:
name_pattern[:port_range]
An example proxy-scheme
is shown below. It causes
the server to access the callback address and the ssh.com
domain directly, access *.example
with HTTP CONNECT, and
all other destinations with SOCKS4.
"direct:///127.0.0.0/8,*.ssh.com; http-connect://http-proxy.ssh.com:8080/*.example; socks://fw.ssh.com:1080/"
The xauth-path attribute contains a path to a supplementary XAuth binary used with X11 forwarding on Unix platforms.
The ignore-aix-rlogin attribute
defines whether the server should ignore the remote login restriction
on AIX. Local login permission is still honored. The value must be
yes
or no
. The default is
no
.
The record-ptyless-sessions attribute can be used
to control whether sessions without PTYs are recorded as user logins in
the operating system. Sessions without PTYs are for example remote
commands and SFTP sessions. By default, all sessions are recorded.
However, some system utilities (such as finger on Solaris) do not allow
sessions without PTYs to be recorded because these sessions do not have a
valid TTY name. On these systems, only real shell logins should be
recorded and others turned off by setting
record-ptyless-sessions=no
.
The value must be yes
or no
.
The default is yes
.
The user-config-dir attribute can be used to specify a directory where user-specific public-key configuration data is found. With this, the administrator can control those options that are usually controlled by the user. The directory path can include a pattern string which is expanded by SSH Tectia Server.
The following pattern strings can be used:
%D
or %homedir%
is the user's home directory
%U
or %username%
is the user's login name
For Windows domain users, these strings are substituted differently:
%U
is expanded to domain.username
%username%
is expanded to domain\username
%IU
or %userid%
is the user's user ID (uid)
%IG
or %groupid%
is the user's group ID (gid)
Note that user ID and group ID are only supported on Unix, not on Windows.
The default is "%D/.ssh2"
.
Example of the settings element and its attributes:
<settings proxy-scheme="direct:///10.0.0.0/8,localhost;socks5://fw.example.com:1080/" xauth-path="/usr/X11R6/bin/xauth" ignore-aix-rlogin="no" record-ptyless-sessions="yes" user-config-dir="%D/.ssh2"/>
The hostkey
element defines the location of the
private host key and optionally the location of the public key
and/or certificate. The elements inside the element must be given in
the right order (private key before public).
Inside one hostkey
element either the public key
or the certificate can be given, not both.
Giving the public key in the configuration file is not mandatory. It will be derived from the private key if it is not found otherwise. However, specifying the public key will decrease the start-up time for the software, as deriving the public key is a fairly slow operation.
This element gives the path to the private key file as a value of the
file
attribute.
The key file should be located on a local drive. Network
or mapped drives should not be used, as the server program may
not have proper access rights for them. The default is
hostkey
, in the /etc/ssh2
directory on Unix and in the "C:\Program Files\SSH Communications Security\SSH Tectia\SSH Tectia Server
" directory on Windows.
On Unix, the private key file should be readable and writable only
by root
. The private key directory should be writable
only by root
On Windows, the key file and directory should have full permissions for the Administrators group and the SYSTEM account and no other permissions.
This element gives the path to the public key file as a value
of the file
attribute.
The key file should be located on a local drive. Network or mapped drives should not be used, as the server program may not have proper access rights for them.
Alternatively, the public key can be specified as a base64-encoded ASCII element.
This element gives the path to the X.509 user certificate file as
a value of the file
attribute.
Alternatively, the certificate can be specified as a base64-encoded ASCII element.
This element defines an external host key. The
type
must be given as an attribute. The currently
supported types are none
, software
,
entrust
, mscapi
, pkcs11
,
and pkcs12
.
The init-info
for the external key can also be given.
Sample hostkey
elements are shown below:
<hostkey> <private file="/etc/ssh2/hostkey_dsa" /> <public file="/etc/ssh2/hostkey_dsa.pub" /> </hostkey> <hostkey> <private file="/etc/ssh2/hostcert_rsa" /> <x509-certificate file="/etc/ssh2/hostcert_rsa.crt" /> </hostkey> <hostkey> <externalkey type="entrust" init-info="profile-file(/etc/ssh2/hostcertprofile.epf)" /> </hostkey>
For PKCS#12, the <hostkey>
settings are as follows:
<hostkey> <externalkey type="software" init-info="key_file(/etc/ssh2/server-cert.p12) key_passphrase_file(/etc/ssh2/my-passphrase)" /> </hostkey>
In the PKCS#12 sample output, the hostkey setting reads the
PKCS#12 file server-cert.p12
and if it needs a passphrase
to open it, it will read the my-passphrase
file and use the
contents as the passphrase. The file can also contain additional
certificates but they are ignored in SSH Tectia Server.
In the init-info
string, the following keywords are
supported:
directory(<directory_name>)
- defines the directory
to be polled for the keys. All files in the named directory are added to
sshexternalkey
. Note however, that this option lacks control
over the actual server key and certificate.
polling_interval_ms(<time_ms>)
- defines the polling
interval for the option above.
key_files(<key_spec>)
- defines that multiple
comma-separated files are read. Loose grouping between files is expected so
that public key, private key and certificate are assumed to be parts of the
same key. Supported in SSH Tectia Server.
key_file(<file_name>)
- defines that one key file
is read. The same as key_files
with one parameter.
key_passphrase(<passphrase>)
- if a private key or
certificate container is password-protected, the command tries to open it
with the supplied passphrase first. In case the passphrase is not valid,
the authentication callback is called normally. In the server, that means a
failure to open the file as the server does not have an interactive prompt.
key_passphrase_file(<filename>)
- defines that
instead of giving the passphrase in the configuration file directly, it can be
written to a separate file. This option is useful if server configuration file
needs to be more widely readable. The private key and passphrase can still be
with root access only.
This element is used to specify where the Secure Shell server
listens for connections. The element has three attributes:
id
, address
, and port
.
The id
must be given as an attribute. The value must be
unique. The value must begin with a letter, it can contain alphanumeric
characters or underscore characters but no any whitespaces. Also the
port
and network interface address
can be given.
The default port for listeners is 22
.
Several listeners can be created to the same IP address to different ports. Each must have an unique ID. If the address is not specified, the server will listen to the given port on all interfaces.
Sample listener
elements are shown below:
<listener id="internet" address="192.0.2.62" /> <listener id="intranet" address="10.0.0.1" /> <listener id="admin-private" port="222" />
This element changes the logging settings that define the
log event severities and logging facilities. The element contains
one or more log-events
elements.
This element sets the severity and facility of different logging events. The events have reasonable default values, which are used if no explicit logging settings are made. This setting allows customizing the default values.
For the events, facility
and
severity
can be set as attributes. The events
itself should be listed inside the log-events
element.
The facility can be normal
, daemon
,
user
, auth
, local0
,
local1
, local2
, local3
,
local4
, local5
, local6
,
local7
, or discard
. Setting the
facility to discard
causes the server to ignore
the specified log events.
On Windows, only the normal
and
discard
facilities are used.
The severity can be informational
,
notice
, warning
, error
,
critical
, security-success
, or
security-failure
.
Any events that are not specifically defined in the
configuration file use the default values. The defaults
can be overridden for all remaining events by giving an empty
log-events
element after all other definitions
and setting a severity value for it.
For a complete list of log events, see Appendix D.
The following example sets the facility of the
Auth_method_failure
event to auth
and the
severity to notice
. It also sets the facility of the
Server_reconfig_started
and Server_starting
events to discard
(the events will not be logged). All other
events use the default settings.
<logging> <log-events facility="auth" severity="notice"> Auth_method_failure </log-events> <log-events facility="discard"> Server_reconfig_started Server_starting </log-events> </logging>
This element sets the maximum number of connections and processes the server will handle. SSH Tectia Server uses a distributed architecture where the master server process launches several servant server processes that handle the actual connections.
The max-processes attribute defines the maximum number of servant processes the master server will launch. The value range is 1-40. The default value is 40.
The max-connections attribute defines the maximum number of client connections allowed per servant. The value range is 1-256. The default value is 256.
This setting is useful in systems with low resources. The server has to be restarted to use the changed setting.
A sample limits
element is shown below:
<limits max-connections="256" max-processes="40" />
This element contains the CA certificates used in validation
of the host-based and public-key authentication certificates. The element can have two
attributes: http-proxy-url
and socks-server-url
.
The http-proxy-url attribute defines a HTTP proxy and the socks-server-url attribute defines a SOCKS proxy for making LDAP or OCSP queries for certificate validity.
The address of the proxy is given as the value of the
attribute. The format of the address is
socks://username@socks_server:port/network/netmask,network/netmask ...
(with a SOCKS proxy) or
http://username@proxy_server:port/network/netmask,network/netmask ...
(with an HTTP proxy).
For example, by setting socks-server-url
to
"socks://mylogin@socks.ssh.com:1080/192.168.0.0/16,10.100.23.0/24"
,
the host socks.ssh.com
and port 1080
are used as your SOCKS server for connections outside of
networks 192.168.0.0
(16-bit domain) and
10.100.23.0
(8-bit domain). Those networks are
connected directly.
The cert-validation
element can contain multiple
ldap-server
and ocsp-responder
elements, a
cert-cache-file
and crl-auto-update
element,
multiple crl-prefetch
elements, a dod-pki
element, and multiple ca-certificate
elements.
The validity of a received certificate is checked separately
using each of the defined ca-certificate
elements in
turn until they are exhausted (in which case the authentication
fails), or a positive result is achieved. If the certificate is
valid, the connections
and authentication-methods
elements determine whether the certificate allows the user to log in
(of course, the correct signature generated by a matching private
key is always required in addition to everything else).
This element specifies an LDAP server address
and
port
used for fetching CRLs and/or subordinate CA
certificates based on the issuer name of the certificate being
validated. Several LDAP servers can be specified by using
several ldap-server
elements.
CRLs are automatically retrieved from the CRL distribution point defined in the certificate to be verified if the point exists.
The default value for port
is 389
.
This element specifies an OCSP (Online Certificate Status
Protocol) responder service address in URL format
(url
). Several OCSP responders can be specified by
using several ocsp-responder
elements.
For the OCSP validation to succeed, both the end-entity
certificate and the OCSP responder certificate must be issued by the
same CA. If the certificate has an Authority Info
Access
extension with an OCSP Responder URL, it is only used
if there are no configured OCSP responders. It is not used if any
OCSP responders have been configured.
The validity-period
in seconds for the OCSP
data can be optionally defined. During this time, new OCSP
queries for the same certificate are not made but the old result
is used.
If an OCSP responder is defined in the configuration file or in the certificate, it is tried first; only if it fails, traditional CRL checking is tried, and if that fails, the certificate validation returns a failure.
This element specifies the name of the file
where the certificates and CRLs are stored when the SSH Tectia Server
service is stopped, and read back in when the service is restarted.
On Unix, the cache file should be writable only by
root
.
On Windows, the cache file should be writable only by the Administrators group and the SYSTEM account.
This element turns on automatic updating of certificate
revocation lists. When it is on, SSH Tectia Server periodically tries to
download the new CRL before the old one has expired. The
update-before
attribute can be used to specify how many
seconds before the expiration the update takes place. The
minimum-interval
sets a limit for the maximum update
frequency. The default minimum interval is 30
seconds.
This element instructs SSH Tectia Server to periodically download a
CRL from the specified url
. The
interval
attribute specifies how often the CRL is
downloaded. The default is 3600
(seconds).
The url
can be either an LDAP or HTTP URL, for example:
ldap://ldap.server.com:389/CN=Root%20CA,OU=certification%20authorities, DC=company,DC=com?certificaterevocationlist
This element defines whether the certificates are required to
be compliant with the DoD PKI (US Department of Defense Public-Key
Infrastructure). In practice, this means that the Digital
Signature bit must be set in the Key Usage of the certificate. The
enable
attribute can have a value of yes
or no
. The default is no
.
This element enables user authentication using
certificates. It can have four attributes: name
,
file
, disable-crls
, and use-expired-crls
.
The name
attribute must contain the name of the CA.
The element must either contain the path to the X.509 CA
certificate file as a value of the file
attribute,
or include the certificate as a base64-encoded ASCII
element.
CRL checking can be disabled by setting the
disable-crls attribute to
yes
. The default is no
.
Note | |
---|---|
CRL usage should only be disabled for testing purposes. Otherwise it is highly recommended to always use CRLs. |
Expired CRLs can be used by setting a numeric value (in seconds) for the use-expired-crls attribute. The default is 0 (do not use expired CRLs).
A sample cert-validation
element is shown below:
<cert-validation http-proxy-url="http://proxy.example.com:800"> <ldap-server address="ldap.example.com" port="389" /> <ocsp-responder validity-period="60" url="http://ca.example.com/ocsp-1/" /> <cert-cache-file file="/var/cert-cache.dat" /> <crl-auto-update update-before="30" minimum-interval="600" /> <crl-prefetch interval="1800" url="http://ca.example.com/default.crl" /> <dod-pki enable="no" /> <ca-certificate name="exa-ca1" file="/etc/ssh2/exa-ca1.crt" /> <ca-certificate name="exa-ca2" file="/etc/ssh2/exa-ca2.crt" use-expired-crls="3600" /> <ca-certificate name="testonly-ca" file="/etc/ssh2/testonly-ca.crt" disable-crls="yes" /> </cert-validation>
connections
BlockThe connections
block defines the basic rules for
allowing and denying connections. The connections
block
includes one or more connection
elements.
If a user does not match to any selectors in the
connection
elements, the server default connection settings are
used.
Each connection
element specifies either an allow
or deny rule for connections. The element can have three attributes:
name
, action
, and tcp-keepalive
.
The word allow
or deny
is given as a
value of the action
attribute. By default, if the
action
attribute is omitted, the connection is
allowed.
The name
attribute can be used to give an identifier to
the connection rule. The value must be a valid XML name beginning with a
letter and containing alphanumeric characters or the underscore character
without any whitespace. The identifier can be used, for example, in
auditing.
The tcp-keepalive attribute defines whether the
system should send keepalive messages to the other side. If they
are sent, a broken connection or crash of one of the machines will
be properly noticed. However, this means that connections will die
if the route is down temporarily, and this can be annoying in some
situations. On the other hand, if keepalive messages are not sent,
sessions may hang indefinitely on the server, leaving "ghost" users
and consuming server resources. The value must be yes
or no
. The default is no
(do not send
keepalives).
The connection
element can include one or more
selectors, a rekey setting, and cipher and MAC definitions.
The selectors define to which connections this connection rule
applies to. Only the interface
and ip
selector attributes can be used in the connections
block. Other information, for example the username, is not yet
available at this stage of the connection. See the section called “Selectors”.
This selector matches to the listener interface id
or
address
and/or port
. At least one
attribute must be given. If the id
is defined, the
others MUST NOT be given. If the id
is not defined,
either or both of address
and port
may
be given.
This selector matches to an IP address
or fqdn
(fully qualified domain name) of the client. Either
address
or fqdn
can be given, not
both.
The address
can be in one of the following formats:
a single IP address x.x.x.x
an IP address range of the form x.x.x.x-y.y.y.y
an IP sub-network mask of the form x.x.x.x/y
The fqdn
attribute matches to an FQDN pattern
(case-insensitive). The attribute can include a comma-separated
list of allowed FQDN patterns. These patterns may also contain "*"
and "?" globbing characters.
This element specifies the number of seconds
or transferred bytes
after which the key exchange
is done again.
If a value for both seconds
and
bytes
is specified, rekeying is done whenever one of
the values is reached, after which the counters are reset.
The defaults are 3600
seconds (1 hour) and
1000000000
bytes (~1 GB). The value 0
(zero) turns
rekey requests off. This does not prevent the client from
requesting rekeys.
This element selects a cipher name
allowed by
the server for data encryption. The supported ciphers are
3des-cbc
,
aes128-cbc
,
aes192-cbc
,
aes256-cbc
,
arcfour
,
blowfish-cbc
,
twofish-cbc
,
twofish128-cbc
,
twofish192-cbc
,
twofish256-cbc
,
crypticore128@ssh.com
,
seed-cbc@ssh.com
,
and
none
(no encryption).
Multiple ciphers can be specified by using multiple
cipher
elements. By default, the server allows
3des-cbc
,
aes128-cbc
,
aes192-cbc
,
aes256-cbc
,
seed-cbc@ssh.com
, and
crypticore128@ssh.com
(on Windows and Linux x86).
The ciphers that can operate in the FIPS mode are
3des-cbc
,
aes128-cbc
,
aes192-cbc
,
and
aes256-cbc
.
Normally when a specified cipher is not found on the server,
the configuration file reading fails and the server will not
restart. The cipher
element may optionally take an
allow-missing
attribute, which can have a value of
yes
or no
. If a value of yes
is given for this attribute and a specified cipher is not found
during configuration reading (for example, CryptiCore on Solaris),
the server logs a warning to the syslog but will restart normally. The
default is no
(a missing cipher is treated as fatal
error and the server configuration reading fails).
Setting the allow-missing
attribute to
yes
is useful when you want to use the same
ssh-server-config.xml
file on multiple servers and only
some of the servers have, for example, CryptiCore available.
This element selects a MAC name
allowed by the server for
data integrity verification. The supported MAC algorithms are
hmac-md5
,
hmac-md5-96
,
hmac-sha1
,
hmac-sha1-96
,
crypticore-mac@ssh.com
,
and
none
(no data integrity verification).
The hmac-sha1
algorithm can operate in the FIPS mode.
Multiple MACs can be specified by using multiple mac
elements. By default, the server allows
hmac-md5
,
hmac-sha1
, and
crypticore-mac@ssh.com
(on Windows and Linux x86).
Normally when a specified MAC is not found on the server,
the configuration file reading fails and the server will not
restart. The mac
element may optionally take an
allow-missing
attribute, which can have a value of
yes
or no
. If a value of yes
is given for this attribute and a specified MAC is not found
during configuration reading (for example, CryptiCore on Solaris),
the server logs a warning to the syslog but will restart normally. The
default is no
(a missing MAC is treated as fatal
error and the server configuration reading fails).
Setting the allow-missing
attribute to
yes
is useful when you want to use the same
ssh-server-config.xml
file on multiple servers and only
some of the servers have, for example, CryptiCore available.
A sample connection
element that allows connections
from a specified IP address range is shown below:
<connection name="conn1" action="allow" tcp-keepalive="yes"> <selector> <ip address="192.168.0.42-192.168.0.82" /> </selector> <rekey seconds="600" bytes="500000000" /> <cipher name="crypticore128@ssh.com" /> <mac name="crypticore-mac@ssh.com" /> </connection>
A sample connection
element that denies all
connections is shown below. As the element does not contain any
selectors, it matches always. This can be used as the last element
in the connections
element to deny all connections that
were not explicitly allowed by the previous elements. (By default,
non-matching connections would be allowed.)
<connection action="deny" />
authentication-methods
BlockThe authentication-methods
block defines the
authentication methods that are allowed and required by the server. It
can have one attribute: login-grace-time
. It can contain a
banner-message
and an auth-file-modes
element
and multiple authentication
elements.
The login-grace-time attribute is
used to specify a time after which the server disconnects if the user
has not successfully logged in. If the value is set to 0
,
there is no time limit. The default is 600
(seconds).
The authentication methods that are on the same level under one
authentication
element are considered allowed (one of them
must succeed).
Several authentication methods can be set as required by nesting the
authentication
elements inside each other.
The server allows by default public-key, keyboard-interactive, and password authentication (one of them must succeed).
If the authentication-methods
element is empty or
missing from the ssh-server-config.xml
file, the server does
not allow any authentication methods and the configuration is essentially
defunctional.
However, if you put inside authentication-methods
an
authentication
element with no authentication methods
defined, the matching users will be allowed to log in without
authentication. This can be used in combination with selectors and/or
nested authentication methods, but should never be used as the only
authentication element.
Caution | |
---|---|
Consider carefully before putting an empty
|
This element specifies the path to the message that is sent to
the client before authentication. The path is given as a value of
the file
attribute. Alternatively, the banner message
can be given as the contents of the banner-message
element.
Note, however, that the client is not obliged to show this message.
<banner-message file="/etc/ssh2/banner-message"> This is the server banner message. If file attribute is set, this inlined text is ignored, and the file is read instead (like in this example). </banner-message>
This element specifies whether SSH Tectia Server on Unix platforms should check permissions and ownership of the user's key files used for public-key authentication.
The word yes
or no
is given as a
value of the strict
attribute. If set to
yes
, the permissions and ownership of the
.ssh2
directory, the .ssh2/authorization
file (if used), the .ssh2/authorized_keys
directory (if
used), and the keys listed in the authorization
file or
present in the authorized_keys
directory are
checked.
This is normally desirable because novices sometimes
accidentally leave their directory or files world-writable, in which
case anyone can edit the authorization and key files. The default is
yes
.
The mask-bits attribute can be
used to specify the forbidden permission bits in octal format. The
default is 022
(group and others must not have the write
permission).
The ownership of the checked files and directories must be either root or the user.
<auth-file-modes strict="yes" mask-bits="022" />
Each authentication
element specifies a chain of
authentication methods. It can include one or more selectors and
different authentication methods. It may also include other
authentication
elements.
Nesting authentication
elements within each other sets
the child elements as required (all must be passed
for the authentication to be successful). Setting multiple authentication
methods at the same level sets them as optional (one
of the methods must be passed for the authentication to be
successful).
The authentication
elements are read in order. For
elements on the same level, the first matching element is used and the
remaining elements are ignored. If the element has nested child elements,
they are matched next using the same procedure.
In the authentication
element, the action
attribute takes values allow
or deny
.
By default, if the action
attribute is omitted,
authentication is allowed.
If an authentication chain ends in a deny
action, or if
the user does not match to any selectors in the authentication
elements, the user is not allowed to log in.
Note | |
---|---|
Note that the behavior has changed in SSH Tectia Server 5.1. In SSH Tectia Server 5.0, a non-matching user was allowed the default authentication methods. |
In a nested chain of authentication
elements, it is
possible, for example, to set the parent method to deny authentication and
a child element with a selector to allow authentication. If the user
matches the selector and successfully completes the authentication
method(s), login is allowed.
For more information on using authentication chains, see Configuring User Authentication Chains.
The authentication
element can take a
repeat-block attribute. This can be used when the
authentication element contains a nested element with
certificate
selectors.
Set the value of repeat-block
to yes
when
you expect the user to have several certificates of which only some allow
login (that is, match the selectors in the child authentication element).
In this case, SSH Tectia Server will try all offered certificates until a match is
found.
If repeat-block
is set to no
(the
default), SSH Tectia Server will try to match only the first certificate offered by
the client.
The authentication
element can additionally take a
set-group attribute, which sets a
group for the users that pass the particular authentication chain. The
group definition can be later used in the services
element.
If set-group
is used here, it overrides any
group
definitions in the services
element. See the section called “The services
Block”.
The authentication name
can be optionally given as an
attribute. The value of name
must be a valid XML name
beginning with a letter and containing alphanumeric characters or the
underscore character without any whitespace. The authentication name
can be used, for example, in auditing.
Caution | |
---|---|
Consider carefully before putting an empty
|
The selectors define to which connections this authentication
method applies to. All selectors can be used in the
authentication-methods
block.
See the section called “Selectors”.
This selector matches to a pattern
in a specified
field
of the user certificate used in public-key
authentication. Using this selector requires that the parent element in
the authentication chain contains an auth-publickey
element.
The field can be either ca-list
,
issuer-name
, subject-name
,
serial-number
, altname-email
,
altname-upn
, altname-ip
, or
altname-fqdn
.
The format of the pattern depends on the type of the
field. The ca-list
field contains a list of CA
names separated by commas. The names that are defined in the
ca-certificate
element are used.
The issuer-name
and subject-name
fields contain distinguished names, serial-number
a positive integer. The altname-fqdn
field contains a hostname and altname-ip
an IP
address or a range. The altname-email
field
contains an email address and altname-upn
the
principal name.
The altname-fqdn
, altname-upn
,
altname-email
, subject-name
, and
issuer-name
selectors may contain the
%username%
keyword which is replaced with the user's
login name before comparing with the actual certificate data.
On Windows, the %username-without-domain%
keyword can be
used and it is replaced by the user's login name without the
domain part. The %hostname%
keyword can be used in the
same way and it is replaced by the client's FQDN. These
patterns may also contain "*" and "?" globbing
characters.
Patterns are normally matched case-insensitively.
Alternatively, the pattern can be specified using the
pattern-case-sensitive
attribute.
The allow-undefined
attribute can be used to
control the behavior of the selector when the required certificate
data is not defined (certificates have not been used at all, or the
certificate does not contain the fields to be matched). Its value must
be yes
or no
. The default is no
.
For more information, see the section called “Selectors and Undefined Data”.
This selector matches to a pattern
in a specified
field
of the client host certificate used in host-based
authentication. Using this selector requires that the parent element in
the authentication chain contains an auth-hostbased
element.
The field can be either ca-list
,
issuer-name
, subject-name
,
serial-number
, altname-email
,
altname-upn
, altname-ip
, or
altname-fqdn
.
Patterns are normally matched case-insensitively.
Alternatively, the pattern can be specified using the
pattern-case-sensitive
attribute.
The allow-undefined
attribute can be used to
control the behavior of the selector when the required certificate
data is not defined (certificates have not been used at all, or the
certificate does not contain the fields to be matched). Its value must
be yes
or no
. The default is no
.
For more information, see the section called “Selectors and Undefined Data”.
This selector matches to the listener interface id
or
address
and/or port
. At least one
attribute must be given. If the id
is defined, the
others MUST NOT be given. If the id
is not defined,
either or both of address
and port
may
be given.
This selector matches to an IP address
or fqdn
(fully qualified domain name) of the client. Either
address
or fqdn
can be given, not
both.
The address
can be in one of the following formats:
a single IP address x.x.x.x
an IP address range of the form x.x.x.x-y.y.y.y
an IP sub-network mask of the form x.x.x.x/y
The fqdn
attribute matches to an FQDN pattern
(case-insensitive). The attribute can include a comma-separated
list of allowed FQDN patterns.
This selector matches to a user name
or
id
. A list of usernames or IDs can be given as a comma-
separated list.
Names are normally matched case-insensitively.
Alternatively, the names can be specified using the
name-case-sensitive
attribute.
On Windows domain environment, the user
and
user-group
selectors have a length limitation.
For more information, see the description of option
User in
Configuration Tool (Windows).
This selector matches to a user group name
or
id
. A list of user-group names or IDs can be given as
a comma-separated list.
Names are normally matched case-insensitively.
Alternatively, the names can be specified using the
name-case-sensitive
attribute.
On Windows domain environment, the user
and
user-group
selectors have a length limitation.
For more information, see the description of option
User in
Configuration Tool (Windows).
This selector matches to a privileged user (administrator or root) or to a
non-privileged user. The value
can be
yes
(match to a privileged user) or no
(match to a normal user).
The allow-undefined
attribute can be used to
control the behavior of the selector when the required data is not
defined (user-privilege level is not known). Its value must be
yes
or no
. The default is no
.
For more information, see the section called “Selectors and Undefined Data”.
Note | |
---|---|
On a Windows server, the user-privilege level is not available during the authentication phase when the user is logging in using a domain account and does not yet have an access token allocated. To get the user-privilege status for domain users, the user should first pass password or GSSAPI authentication. If the privilege level needs to be checked for local accounts,
the To check the privilege level of domain accounts on a Windows
server in the |
This selector matches if authentication is passed using a
normal public key (without a certificate). Using this selector
requires that the authentication chain contains an
auth-publickey
element.
Optionally, the length
range of the public key
can be given as an attribute, for example "1024-2048"
(keys from 1024 to 2048 bits match). The range can also be left
open, for example "1536-"
(keys over 1536 bits
match).
The allow-undefined
attribute can be used to
control the behavior of the selector when the required data is not
defined (public-key authentication has not been used). Its value must
be yes
or no
. The default is
no
. For more information, see the section called “Selectors and Undefined Data”.
This selector matches on Unix platforms if the user password
has expired and should be changed. The actual password change can
be done by defining a rule with a forced passwd
command. See the section called “The services
Block” for an example.
The allow-undefined
attribute can be used to
control the behavior of the selector when the required data is not
defined. Its value must be yes
or no
.
The default is no
. For more information, see
the section called “Selectors and Undefined Data”.
This element sets the public-key authentication method. The
element can have three attributes: authorization-file
,
authorized-keys-directory
, and openssh-authorized-keys-file
.
The authorization-file attribute can be used to specify a path to the file that lists the user public keys that are authorized for login. The path can contain a pattern string that is expanded by SSH Tectia Server.
The following pattern strings can be used:
%D
or %homedir%
is the user's home directory
%U
or %username%
is the user's login name
For Windows domain users, these strings are substituted differently:
%U
is expanded to domain.username
%username%
is expanded to domain\username
%IU
or %userid%
is the user's user ID (uid)
%IG
or %groupid%
is the user's group ID (gid)
Note that user ID and group ID are only supported on Unix, not on Windows.
The default is %D/.ssh2/authorization
.
The authorized-keys-directory attribute can be used to specify
a path to the directory that contains the user public keys that are
authorized for login. As above, the path can contain a pattern string
that is expanded by SSH Tectia Server. The default is
%D/.ssh2/authorized_keys
.
The openssh-authorized-keys-file attribute can be used to
specify a path to an OpenSSH-style authorized_keys
file
that contains the user public keys that are authorized for login. As
above, the path can contain a pattern string that is expanded by
SSH Tectia Server.
Note | |
---|---|
These attributes override the |
For more information, see User Authentication with Public Keys.
This element sets the host-based authentication method.
The element can have one attribute:
require-dns-match
.
If the require-dns-match attribute is set to
yes
, host-based authentication will require the
hostname given by the client to match the one found in DNS. If
the hostname does not match, the authentication will fail. The
default is no
(exact match not required).
This element sets the password authentication method.
The delay between failed attempts in seconds (failure-delay) and the maximum number of attempts (max-tries) can be given as attributes. The default delay is 2 seconds and default maximum is 3 attempts.
This element sets the keyboard-interactive authentication method.
The delay between failed attempts in seconds (failure-delay) and the maximum number attempts (max-tries) can be given as attributes. The default delay is 2 seconds and default maximum is 3 attempts.
The keyboard-interactive submethods are given as child
elements. The supported methods are submethod-password
,
submethod-pam
, submethod-securid
, and
submethod-radius
, and submethod-generic
.
If no submethods are configured, all available submethods are allowed by default (however, the server may not be able find the necessary libraries for SecurID and PAM, for example). If some of the submethods are configured, the rest of the submethods are implicitly disabled.
This element sets the keyboard-interactive PAM submethod in use. PAM is supported on Unix platforms.
The dll-path
to the PAM DLL can be given in an
attribute. The path must point to the operating-system specific
PAM module, for example, "/lib/libpam.so.1"
on Red
Hat Linux, or "/lib/libpam.a(shr.o)"
on AIX.
On AIX, the path should include the archive file, unless the library is a shared object or has been extracted from the shared object.
This element sets the keyboard-interactive password submethod in use.
This element sets the keyboard-interactive SecurID submethod in use.
The dll-path
to the SecurID DLL can be
given in an attribute. The path must point to the
operating-system specific SecurID module, for example,
"/usr/lib/libaceclnt.so"
on Solaris.
This element sets the keyboard-interactive RADIUS submethod in use.
The element can contain multiple radius-server
child elements.
This element defines a RADIUS server. The element
has four attributes: address
,
port
, timeout
, and
client-nas-identifier
.
The address
is the IP address of the
RADIUS server. The port
is the RADIUS server
port. The default port is 1812
.
The timeout
is the time in seconds
after which the RADIUS query is terminated if no response
is gained. The default is 10
seconds.
The client-nas-identifier attribute defines the network access server (NAS) identifier to be used when talking to the RADIUS server.
The element must contain one radius-shared-secret
child element.
This element sets the generic submethod in use. This element can be used to add custom submethods to keyboard-interactive authentication.
The name
on the method must be given in the attribute.
Optional params
for the submethod can be given as well.
This element sets the GSSAPI authentication method.
The dll-path
can be given as an attribute.
This specifies where the necessary GSSAPI libraries are located.
If this attribute is not specified, the libraries are
searched for in a number of common locations. The full path to
the libraries should be given, for example,
"/usr/lib/libkrb5.so,/usr/lib/libgssapi_krb5.so"
.
On AIX, the dll-path
should include the archive file, if applicable, for example,
"<path>/libgssapi_krb5.a(libgssapi_krb5.a.so)"
.
The archive(shared_object)
syntax is not necessary if
the library is a shared object or has been extracted from the shared
object.
On Windows, the dll-path
attribute is
ignored. SSH Tectia Server locates the correct DLL automatically.
The allow-ticket-forwarding attribute defines
whether the server allows forwarding the Kerberos ticket over
several connections. The attribute can have a value of
yes
or no
. The default is
no
.
Normally if a specified authentication method is not found on the
server, the configuration file reading fails and the server will not
restart. The auth-gssapi
element may optionally take an
allow-missing
attribute, which can have a value of
yes
or no
. If a value of yes
is
given for this attribute and GSSAPI plugin is not found during
configuration reading, the server logs a warning to the syslog but will
restart normally. The default is no
(if GSSAPI is specified
but not found, it is treated as fatal error and the server configuration
reading fails).
Setting the allow-missing
attribute to
yes
is useful when you want to use the same
ssh-server-config.xml
file on multiple servers and only
some of the servers have Kerberos/GSSAPI available.
The authentication
elements can be nested within each
other. The method(s) in the child element(s) must be passed in addition to
the method in the parent element.
A sample authentication-methods
element is shown below:
<authentication-methods> <authentication> <selector> <user-group name="staff" /> </selector> <auth-publickey authorized-keys-directory="%IG/ssh2_authorized_keys" /> <auth-password /> </authentication> </authentication-methods>
In this simple authentication example, the users who belong to group "staff" are allowed to log in using either public-key or password authentication. The user public keys are checked from an alternate location. As there are no other authentication blocks, all users that do not match to the selector are implicitly denied authentication.
Note | |
---|---|
Note that the behavior has changed in SSH Tectia Server 5.1. In SSH Tectia Server 5.0, a non-matching user was allowed the default authentication methods. |
Another sample authentication-methods
element is shown below:
<authentication-methods> <authentication action="deny"> <auth-publickey /> <authentication action="allow" set-group="local-user"> <selector> <ip address="10.1.55.14-10.1.55.99" /> <user name="johnd" /> <user name="janed" /> </selector> <auth-keyboard-interactive max-tries="4"/> <submethod-radius> <radius-server address="10.1.61.128"> <radius-shared-secret file="&configdir;/radius-secret-file"/> </radius-server> </submethod-radius> </auth-keyboard-interactive> </authentication> <authentication action="allow" set-group="finance-inspector"> <selector> <user-group name="finance" /> </selector> <auth-password /> </authentication> </authentication> </authentication-methods>
In the example above, all users are first required to authenticate
using public-key authentication. Based on selector matching, also a
second method needs to be passed (RADIUS via keyboard-interactive or
password). A group is set based on the matched and passed authentication
methods. If a user does not match to either of the child authentication
elements, access is denied (the parent authentication element has
the action set to deny
).
If the action of the parent authentication element would be
allow
, the non-matching users would be let in after having
passed public-key authentication.
See Configuring User Authentication Chains for more examples of configuring authentication chains.
A sample authentication-methods
element that sets
requirements for certificate authentication is shown below:
<authentication-methods> <authentication action="allow" repeat-block="yes"> <auth-publickey /> <authentication action="allow" set-group="admin"> <selector> <user-privileged value="yes" allow-undefined="yes" /> <certificate field="ca-list" pattern="exa-ca1,exa-ca2" allow-undefined="yes" /> <certificate field="subject-name" pattern="C=FI, O=SSH, CN=%username%" allow-undefined="yes" /> </selector> </authentication> <authentication action="allow"> <selector> <publickey-passed length="1024-2048" /> </selector> </authentication> <authentication action="deny" /> </authentication> </authentication-methods>
In the example above, privileged users (administrators) are required to pass certificate authentication and the certificate must contain the correct fields. Other users are allowed to log in using a plain public key of a size from 1024 to 2048 bits.
In this example, the allow-undefined
attribute has to be
used in the selectors of the first nested authentication block. Otherwise,
the authentication will end in error for users with plain public keys. When
the user uses a plain public key, the server will not have the certificate
fields to be matched defined. For more information, see the section called “Selectors and Undefined Data”.
Note | |
---|---|
Specifying an explicit |
services
BlockThe services
block defines the policy for the various
services the server offers.
The services
block contains one or more rules
(rule
) and optionally defines groups (group
).
Creates a group that can be used as a basis for restricting services. Groups are defined based on selectors.
The name
must be given as an attribute.
The value of name
must be a valid XML name beginning with a
letter and containing alphanumeric characters or the underscore character
without any whitespace.
If the user was already put to a group during authentication
using the set-group
attribute, the group definitions in
the services
element are ignored.
The selectors define the users that belong to the group.
The same selectors can be used as in the authentication-methods
block. See the section called “Selectors” and the section called “The authentication-methods
Block”.
Sample group
elements are shown below:
<!-- Remote access. --> <group name="remote-access"> <selector> <interface address="192.0.2.62" /> </selector> </group> <!-- Backup. --> <group name="backup"> <selector> <user name="backup" /> </selector> </group> <!-- Password change needed. --> <group name="passwd-change"> <selector> <user-password-change-needed /> </selector> </group>
This element defines a rule for the specified
group
of users. Rules can be used to restrict the
services and commands the server allows to the users. The element
can have three attributes: group
, idle-timeout
,
and print-motd
.
The rules are read in order, and the first rule that matches
the user's group
is used. The match must be exact. No
wild cards are allowed in the group
attribute. If no
group
is specified, the rule matches to all users.
The idle-timeout attribute sets the idle
timeout limit in seconds. If the connection (all channels) has been
idle this long, the connection is closed. The default is
0
(zero), which disables idle timeouts.
The print-motd attribute defines
whether the message of the day (/etc/motd
) is printed
when a user logs in interactively to a Unix server. The value must be
yes
or no
. The default is yes
.
Each rule can contain environment
,
terminal
, subsystem
, tunnel-agent
,
tunnel-x11
, tunnel-local
, tunnel-remote
,
and command
elements.
An empty rule allows the specified group to perform all actions.
A default unnamed rule allows all users access to all services. The unnamed rule should be kept as the last rule, so it will match to users that are not set in any group, but you should edit the rule according to your security policy.
This element defines the environment variables the user group can
set. The variables are given as a value of the
allowed
attribute. By default, the user can set the
TERM
, PATH
, TZ
,
LANG
, and LC_*
variables.
Allowed variables are normally matched case-insensitively.
Alternatively, the variables can be specified using the
allowed-case-sensitive
attribute.
This element defines whether terminal access is allowed or denied for
the user group. The word allow
or deny
can be given as the value of the action
attribute.
By default, terminal access is allowed.
On Unix systems, the chroot attribute can be optionally used to define a directory where the user is chrooted during the terminal session. For more information on chrooting, see Chrooting (Unix).
If terminal access is denied, also shell commands are denied,
unless commands are explicitly allowed or set as forced by the
command
element. See command below.
This element defines a subsystem. The subsystem type
must
be given as an attribute. The use of the subsystem can be allowed
or denied by giving the word allow
or
deny
as the value of the action
attribute. The default action is allow
.
Optionally also the application
can be given.
This is not necessary with the SFTP subsystem if the SFTP binary is
in the default location.
Note | |
---|---|
Denying the SFTP subsystem denies both SFTP and SCP2 operations to the server, but it does not deny OpenSSH-style SCP operations. To deny OpenSSH SCP, you should restrict remote commands. See command below. |
On Unix systems, the chroot attribute can be optionally used to define a directory where the user is chrooted when running the subsystem. For more information on chrooting SFTP, see Chrooting SFTP (Unix).
The element can contain multiple attribute
child
elements.
This element defines an attribute of a subsystem.
The name
must be given as an attribute.
The value
can be optionally given.
This can be used, for example, on Windows platforms to set the user home directory and virtual folders for SFTP.
<subsystem type="sftp" application="sft-server-g3.exe"> <attribute name="home" value="%USERPROFILE%" /> </subsystem>
For more information, see Defining SFTP Virtual Folders (Windows).
This element defines a shell command as allowed, denied,
or forced. The element can have four attributes, however, all of
them are not used at the same time: action
,
application
, application-case-sensitive
,
and chroot
.
The value of the action
attribute can be
either allow
, deny
, or
forced
. The default is allow
.
If the deny
action is set, all shell commands are
denied and no further attributes should be specified. Commands are also
denied if terminal access is denied in the rule and the command element
is omitted.
For the allow
action, the application
can be optionally specified as an attribute. When the allow
action is set and the application
attribute is specified,
running the specified application(s) is allowed and all other
applications are implicitly denied. If the application is not given,
running all commands is allowed.
For the forced
action, the application
must be given as an attribute. When the forced
action is
set, the specified application is run automatically when the user logs
in successfully, instead of the application the user is trying to run.
All other applications are implicitly denied.
If the terminal
element is omitted from the rule and
the command
element specifies a forced command, terminal is
implicitly denied. If the user requests a shell, the forced command is
run instead.
If the terminal
is explicitly allowed in the rule,
the forced
action of the command
element
applies only when the user tries to run remote commands. If the user
requests a shell, he can get it normally and the forced command is not
run.
If the SFTP subsystem
is allowed, the user can also
use the scp2/scpg3 and
sftp2/sftpg3 programs normally. However, if the SFTP
subsystem is denied, trying to use it will not cause the forced command
to be run, but gives an error message.
Note | |
---|---|
Support for legacy OpenSSH SCP in SSH Tectia Server is implemented using a command called scp1-compat-srv. When a client uses OpenSSH SCP to connect to SSH Tectia Server, the server invokes this command. Restrictions on remote commands apply also to OpenSSH-style SCP operations to the server. |
Users can also define forced commands for public keys in their
authorization
files or OpenSSH-style
authorized_keys
files. However, if a command is defined in
the ssh-server-config.xml
file, it overrides any commands
defined in the authorization
or authorized_keys
files. For more information, see
the section called “Authorization File Options”.
Applications are normally matched case-insensitively.
Alternatively, the application can be specified using the
application-case-sensitive
attribute.
On Unix systems, the chroot attribute can be optionally used to define a directory where the user is chrooted when running the command. For more information on chrooting, see Chrooting (Unix).
This element defines whether agent tunneling (forwarding) is allowed or denied by the server.
The word allow
or deny
can be
given as the value of the action
attribute. By
default, agent forwarding is allowed.
For more information on agent forwarding, see Agent Forwarding (Unix).
This element defines whether X11 tunneling (forwarding) is allowed or denied by the server.
The word allow
or deny
can be
given as the value of the action
attribute. By
default, X11 forwarding is allowed.
For more information on X11 forwarding, see X11 Forwarding (Unix).
This element defines a rule for local TCP tunnels (port forwarding). There can be several of these rules. When a user attempts tunneling, the rules are read in order and the first matching rule is used. See the section called “Tunneling Rule Processing” for details.
The word allow
or deny
can be
given as the value of the action
attribute. By
default, local tunnels are allowed.
Tunneling restrictions can be further defined with the
src
and dst
elements.
This element defines source address(es) and port(s) for local tunnels.
The address
or the fqdn
(not both) can be
given as an attribute.
The address
can be in one of the following formats:
a single IP address x.x.x.x
an IP address range of the form x.x.x.x-y.y.y.y
an IP sub-network mask of the form x.x.x.x/y
The fqdn
attribute matches to an FQDN pattern
(case-insensitive). The attribute can include a comma-separated
list of allowed FQDN patterns. These patterns may also contain "*"
and "?" globbing characters.
This element defines destination address(es) and port(s) for local tunnels.
The address
or the fqdn
(not
both) can be given as an attribute. Also the port
can be given.
The address
and the fqdn
can be in the
formats described above for the src
element.
The port
attribute can specify a single port or a
port range (for example, 2000-9000
).
For more information on local tunnels, see Local Tunnels.
This element defines a rule for remote TCP tunnels (port forwarding). There can be several of these rules. When a user attempts tunneling, the rules are read in order and the first matching rule is used. See the section called “Tunneling Rule Processing” for details.
The word allow
or deny
can be
given as the value of the action
attribute. By
default, remote tunnels are allowed.
Tunneling restrictions can be further defined with the
src
and listen
elements.
This element defines source address(es) and port(s) for remote tunnels.
The address
or the fqdn
(not both) can be
given as an attribute.
The address
can be in one of the following formats:
a single IP address x.x.x.x
an IP address range of the form x.x.x.x-y.y.y.y
an IP sub-network mask of the form x.x.x.x/y
The fqdn
attribute matches to an FQDN pattern
(case-insensitive). The attribute can include a comma-separated
list of allowed FQDN patterns. These patterns may also contain "*"
and "?" globbing characters.
This element defines listen address(es) and port(s) for remote tunnels.
The address
and the port
can
be given as attributes.
The address
can be in the formats described
above for the src
element.
The port
attribute can specify a single port or a
port range (for example, 2000-9000
).
For more information on remote tunnels, see Remote Tunnels.
Sample rule
elements are shown below:
<!-- Administrators are allowed to do anything. --> <rule group="admin" /> <!-- The finance inspector. --> <rule group="finance-inspector" print-motd="no"> <tunnel-local action="allow"> <!-- Microsoft SQL ports. --> <dst fqdn="finance-db.example.com" port="1433" /> <dst fqdn="finance-db.example.com" port="1434" /> </tunnel-local> <tunnel-remote action="deny" /> <!-- Can execute commands and shells, as no overriding behavior is defined. --> </rule> <!-- Remote access. --> <rule group="remote-access" idle-timeout="600"> <!-- Setting terminal action to "deny" also denies shell commands, unless they are specifically allowed. --> <terminal action="deny" /> <subsystem type="sftp" application="sft-server-g3" chroot="%homedir%" /> <!-- The listed local tunnels are allowed, other local tunnels are denied. --> <tunnel-local action="allow"> <!-- IMAP. --> <dst fqdn="imap.example.com" port="143" /> <dst fqdn="imap.example.com" port="993" /> <!-- POP. --> <dst fqdn="mail.example.com" port="109" /> <dst fqdn="mail.example.com" port="110" /> <dst fqdn="mail.example.com" port="995" /> </tunnel-local> <tunnel-remote action="deny" /> </rule> <rule group="backup"> <terminal action="deny" /> <!-- This account is only used to back up the disk drive. --> <command application="dd if=/dev/hda" action="forced" /> <tunnel-local action="deny" /> <tunnel-remote action="deny" /> </rule> <!-- This rule is used to force password change. --> <rule group="passwd-change"> <terminal action="deny"/> <command application="/usr/bin/passwd" action="forced" /> <tunnel-local action="deny" /> <tunnel-remote action="deny" /> </rule> <!-- The default rule, used if the user has not been put to any group. --> <rule> <!-- The listed environment variables are allowed and all others are denied. There is no "denied" setting. --> <environment allowed-case-sensitive="TERM,PATH,TZ,LANG,LC_*" /> <terminal action="deny" /> <subsystem type="sftp" application="sft-server-g3" chroot="%homedir%" /> <!-- Only the date command is allowed. Other commands are denied. --> <command application="date" action="allow" /> <!-- Local tunnels are allowed. --> <tunnel-local action="allow" /> <!-- Remote tunnels are denied. --> <tunnel-remote action="deny" /> </rule>
The tunneling rules defined by the tunnel-local
and
tunnel-remote
elements operate in the same way as selectors.
Inside a tunnel rule, elements of different type are in AND relation to each
other. If a tunnel rule contains several items of the same type, they are in
OR relation to each other.
For example, the following rule matches if both the listen port and the source FQDN match:
<rule> <tunnel-remote action="allow"> <listen port="1-9000" /> <src fqdn="trusted.example.com" /> </tunnel-remote> ... </rule>
For example, the following rule matches if either of the source addresses match:
<rule> <tunnel-remote action="deny"> <src address="192.168.23.1" /> <src address="10.1.0.1" /> </tunnel-remote> ... </rule>
With several tunneling rules of the same type, the first matching rule
is used. For example, the following configuration allows local tunnels to
all other addresses in network 192.168.14.0/24
except
192.168.14.21-192.168.14.30
:
<rule> <tunnel-local action="deny"> <dst address="192.168.14.21-192.168.14.30" /> </tunnel-remote> <tunnel-local action="allow"> <dst address="192.168.14.0/24" /> </tunnel-remote> ... </rule>
If the tunnel-local
elements were in different order,
tunnels to the whole 192.168.14.0/24
network would be allowed
as any tunneling attempts would match the first (allow
) rule
and the second (deny
) rule would not be read.
For more examples of tunneling rules, see Chapter 8.