![\"SSH](\"images/header_logo.gif\"){kind=logo} | ![\"\"](\"images/1x1.gif\"){kind=spacer} | |
![\"\"](\"images/navi1_left.gif\") | ||
|
![\"Home\"](\"images/home.gif\") ![](\"images/index.gif\") ![\"Prev\"](\"images/prev.gif\") ![\"Up\"](\"images/up.gif\") ![\"Next\"](\"images/next.gif\") |
ssh-broker-config
ssh-broker-config — SSH Connection Broker configuration file format
The Connection Broker configuration file \nssh-broker-config.xml is used by SSH Tectia Client, ConnectSecure, and \nSSH Tectia MFT Events on Unix and Windows, and additionally by the SSH Tectia client tools on z/OS \nand z/Linux. The Connection Broker configuration file must be a valid XML file that \nfollows the ssh-broker-ng-config-1.dtd document type \ndefinition.
Connection Broker Files
The Connection Broker reads three configuration files (if all are available):
The
ssh-broker-config-default.xmlfile is \n read first. It holds the factory default settings. It is not \n recommended to edit the file, but you can use it to view the default \n settings.This file must be available and correctly formatted for the \n Connection Broker to start.
Next, the Connection Broker reads the global configuration file. \n The settings in the global configuration file override the default \n settings.
If the global configuration file is missing or malformed, the Connection Broker \n will start normally, and will read the user-specific configuration file, instead. \n A malformed global configuration file is ignored and the default settings \n or user-specific settings, if they exist, are used instead.
Last, the Connection Broker reads the user-specific configuration file, \n if it is available. The settings in the user-specific configuration file \n override the settings in the global configuration file, with the following \n exceptions:
The following settings from the user-specific configuration \n are combined with the settings of the global configuration file:
In
generalelement, thekey-stores, \ncert-validationandfile-access-controlsettingsIn
profileselement, all settingsIn
static-tunnelselement, all settings.
If a connection profile with the same name has been defined in \n both the global configuration file and user-specific configuration file, \n the latter one is used.
If the
filter-enginesettings have been \n defined in the global configuration file, and the file is valid (not \n malformed), those settings are used, and anyfilter-engine\n settings made in the user-specific configuration file are ignored.\n
If the user-specific configuration file is missing, the Connection Broker \n will start using the previously read configuration files. However, if \n a user-specific configuration exists but is malformed, the Connection Broker will not \n start at all.
On Unix, the default configuration file locations are as follows:
the default configuration:
/etc/ssh2/ssh-tectia/auxdata/ssh-broker-ng/ssh-broker-config-default.xmlthe global configuration:
/etc/ssh2/ssh-broker-config.xmlthe user-specific configuration:
$HOME/.ssh2/ssh-broker-config.xmlthe XML DTD:
/etc/ssh2/ssh-tectia/auxdata/ssh-broker-ng/ssh-broker-ng-config-1.dtd
On Windows, the default configuration file locations are as follows:
the default configuration:
\"
C:\\Program Files\\SSH Communications Security\\SSH Tectia\\SSH Tectia AUX\\ssh-broker-ng\\ssh-broker-config-default.xml\"the global configuration:
\"
C:\\Program Files\\SSH Communications Security\\SSH Tectia\\SSH Tectia Broker\\ssh-broker-config.xml\"the user-specific configuration: \"
%APPDATA%\\SSH\\ssh-broker-config.xml\"the XML DTD:
\"
C:\\Program Files\\SSH Communications Security\\SSH Tectia\\SSH Tectia AUX\\ssh-broker-ng\\ssh-broker-ng-config-1.dtd\"
The following sections describe the options available in the Connection Broker \nconfiguration file. \nFor more information on the syntax of the configuration file, see\nBroker Configuration File Syntax.\n\n
Environment Variables
Two kinds of environment variables can be used in the Connection Broker \nconfiguration file. In addition to the system-level environment variables, \nyou can use special variables that are SSH Tectia specific. The environment \nvariables take precedence over the special variables. So if an environment \nvariable and a special variable have the same name, the environment variable \nwill be used.
All alphanumeric characters and the underscore '_' \nsign are allowed in environment variables. The variable name ends to the first \ncharacter that is not allowed.
You can define for example file or directory paths with environment \nvariables, and they will be expanded to their values as explained below. \n
- %VARIABLENAME%
Replaced with the value of the environment variable if one \nhas been defined. The variable is matched case-insensitively. If the \nvariable is not defined, the string '
%VARIABLENAME%' \nis the result.- $VARIABLENAME
Replaced with the value of the environment variable if one \nhas been defined. The variable is matched case-sensitively on Unix and \ncase-insensitively on Windows. If the variable is not defined, it is \nreplaced with an empty string.
- ${VARIABLENAME}
text Replaced with the value defined for '
$VARIABLENAME' \nwith the 'text' appended to it.- ${VARIABLENAME:-
default_value} Replaced with the value defined for '
$VARIABLENAME', or replaced with \nthe 'default_value' if the variable is not set.
The SSH Tectia specific special variables are:
- %U or %username%
Replaced with the currently logged in user name.
- %username-without-domain%
Replaced with the currently logged in user name in short \nformat, i.e. without the domain part. Available on Windows.
- %G or %groupname%
Replaced with the group name of the currently logged in \nuser.
- %D or %homedir%
Replaced with the home directory defined for the currently \nlogged in user.
- %IU or %userid%
Replaced with the user identifier defined for the currently \nlogged in user.
- %IG or %groupid%
Replaced with the group identifier defined for the currently \nlogged in user.
The special variables can also be entered using the Unix format, for \nexample, $username.
Document Type Declaration and the Root Element
The broker configuration file is a valid XML file and starts with \nthe Document Type Declaration.
The root element in the configuration file is secsh-broker. \nIt can include general, \ndefault-settings, \nprofiles, \nstatic-tunnels, \ngui, \nfilter-engine, and \nlogging elements.
An example of an empty configuration file is shown below:
<!DOCTYPE secsh-broker SYSTEM \"ssh-broker-ng-config-1.dtd\">\n<secsh-broker version=\"1.0\">\n <general />\n <default-settings />\n <profiles />\n <static-tunnels />\n <gui />\n <filter-engine /> \n <logging />\n\n</secsh-broker>\n
On SSH Tectia Client, the filter-engine \nelement is used only when the optional transparent TCP tunneling feature \nhas been installed and activated.
The general Element
The general element contains settings such as the \ncryptographic library and the key stores to be used.
The general element can contain zero or one instance \nof the following elements: crypto-lib, cert-\nvalidation, key-stores, user-config-\ndirectory, protocol-parameters; and multiple \nknown-hosts elements.
- crypto-lib
This element selects the cryptographic library mode to be \n used. Either the standard version (
standard) or the \n FIPS 140-2 certified version (fips) of the cryptographic\n library can be used. The library name is given as a value of the \nmodeattribute. By default, standard cryptographic libraries \n are used.FIPS mode will be used if it is so specified either in \n the global or the user configuration file (or both).
<crypto-lib mode=\"standard\" />\n
In the FIPS mode, the cryptographic operations are \n performed according to the rules of the FIPS 140-2 standard. The FIPS \n library includes the \n
3des-cbc, \naes128-cbc,\naes192-cbc,\nand \naes256-cbcciphers and the \nhmac-sha1MAC.\n![\"[Note]\"](\"images/note.gif\")
Note Setting the FIPS mode does not prevent using algorithms from \n the crypto plugins. For example, CryptiCore can be used even when the main \n cryptographic library is set into the FIPS mode. To enforce that only \n FIPS-compliant algorithms are used, disable the non-FIPS algorithms \n from the configuration. \n See cipher \n and mac.
For a list of platforms on which the FIPS library has been \n validated or tested, see SSH Tectia Client/Server Product \n Description.
- cert-validation
This element defines public-key infrastructure (PKI) settings \n used for validating remote server authentication certificates. The \n element can have the following attributes:
end-point-identity-check, \ndefault-domain,http-proxy-url, and\nsocks-server-url.The
end-point-identity-checkattribute specifies \n whether the client will verify the server's hostname or IP address against \n the Subject Name or Subject Alternative Name (DNS Address) specified in the \n server host certificate. The default value isyes.\n If set tono, the fields in the server host certificate \n are not verified and the certificate is \n accepted based on the validity period and CRL check only.![\"[Caution]\"](\"images/caution.gif\")
Caution Setting
end-point-identity-check=\"no\"is a security \n risk. Then anyone with a certificate issued by the same trusted \n certification authority (CA) that issues the server host certificates can \n perform a man-in-the-middle attack on the server.The
default-domainattribute can be used when the \n end-point identity check is enabled. It specifies the default domain \n part of the remote system name and it is used if only the base part of \n the system name is available. Thedefault-domainis \n appended to the system name if it does not contain a dot \n (.).If the default domain is not specified, the end-point \n identity check fails, for example, when a user tries to connect to a \n host \"
rock\" giving only the short hostname and the \n certificate contains the full DNS address \n \"rock.example.com\".The
http-proxy-urlattribute defines an HTTP proxy \n and thesocks-server-urlattribute defines a SOCKS \n server for making LDAP or OCSP queries for certificate validity.The address of the server is given as the value of the \n attribute. The format of the address is\n
socks://username@socks_server:port/network/netmask,network/netmask ...(with a SOCKS server) or\nhttp://username@proxy_server:port/network/netmask,network/netmask ...(with an HTTP proxy).For example, to make the SOCKS server use host
socks.ssh.comand \n port1080for connections outside of networks192.196.0.0(16-bit domain) \n and10.100.23.0(8-bit domain), and to get these networks connected \n directly, setsocks-server-urlas follows:\"socks://mylogin@socks.ssh.com:1080/192.196.0.0/16,10.100.23.0/24\"
The
cert-validationelement can contain multiple \nldap-server,ocsp-responder, \ncrl-prefetchelements, onedod-pkielement, and\n multipleca-certificateandkey-storeelements. \n The elements have to be in the listed order.- ldap-server
This element specifies an LDAP server
addressand \nportused for fetching CRLs and/or subordinate CA \n certificates based on the issuer name of the certificate being \n validated. Several LDAP servers can be specified by using \n severalldap-serverelements.CRLs are automatically retrieved from the CRL distribution \n point defined in the certificate to be verified if the point \n exists.
The default value for
portis389.- ocsp-responder
This element specifies an OCSP (Online Certificate Status \n Protocol) responder service address in URL format with attribute \n
url. Several OCSP responders can be specified by \n using severalocsp-responderelements.If the certificate has a valid Authority Info Access extension \n with an OCSP Responder URL, it will be used instead of this setting. \n Note that for the OCSP validation to \n succeed, both the end-entity certificate and the OCSP Responder \n certificate must be issued by the same CA.
The
validity-period(in seconds) can be \n optionally defined. During this time, new OCSP queries for the same \n certificate are not made but the old result is used. The default \n validity period is0(a new query is made every time).- crl-prefetch
This element instructs SSH Tectia Client to periodically download a CRL \n from the specified URL. The
urlvalue can be an LDAP or \n HTTP URL, or it can refer to a local file. The file format must be either \n binary DER or base64, PEM is not supported.To download CRLs from the local file system, define the file URL in \n this format:
file:///absolute/path/name
To download CRLs from an LDAP server, define the LDAP URL in this format:
ldap://ldap.server.com:389/CN=Root%20CA,OU=certification\n %20authorities,DC=company,DC=com?certificaterevocationlist
Use the
intervalattribute to specify how often \n the CRL is downloaded. The default is3600seconds.- dod-pki
This element defines whether the certificates are required to be \n compliant with the US Department of Defense Public-Key Infrastructure \n (DoD PKI). In practise, this means that the Digital Signature bit must be \n set in the Key Usage of the certificate. The \n
enableattribute can have a value ofyes\n orno. The default isno.- ca-certificate
This element defines a certification authority (CA) used in server \n authentication. It can have four attributes:
name, \nfile,disable-crls, and \nuse-expired-crls.The
nameattribute must contain the name of the CA.The element must either contain the path to the X.509 CA \n certificate file as a value of the
file\n attribute, or include the certificate as a base64-encoded \n ASCII block.CRL checking can be disabled by setting the \n
disable-crlsattribute toyes. The default \n isno.Expired CRLs can be used by setting a numeric value (in \n seconds) for the
use-expired-crlsattribute. The \n default is0(do not use expired CRLs).- key-store
This element defines CA certificates stored in an external key \n store for server authentication. Currently it is used only on z/OS for \n CA certificates stored in System Authorization Facility (SAF).
CRL checking can be disabled by setting the \n
disable-crlsattribute toyes. The default \n isno.Expired CRLs can be used by setting a numeric value (in \n seconds) for the
use-expired-crlsattribute. The \n default is0(do not use expired CRLs).
An example of a certificate validation configuration is shown below:
<cert-validation end-point-identity-check=\"yes\" \n default-domain=\"example.com\"\n http-proxy-url=\"http://proxy.example.com:8080\">\n <ldap-server address=\"ldap://ldap.example.com:389\" />\n <ocsp-responder url=\"http://ocsp.example.com:8090\" validity-period=\"0\" /> \n <crl-prefetch url=\"file:///full.path.to.crlfile\" interval=\"1800\" />\n <dod-pki enable=\"no\" />\n <ca-certificate name=\"ssh_ca1\"\n file=\"ssh_ca1.crt\"\n disable-crls=\"no\"\n use-expired-crls=\"100\" />\n</cert-validation> \n
- key-stores
This element defines settings for user public-key and certificate authentication.
Under the
<general>element, there can be one \n<key-stores>instance which in turn can have any \n number of<key-store>,<user-keys>, and\n<identification>elements, and the order of the elements is free.Special variables and environment variables can be used when defining the \n values for the elements. The following variables can be used and they will be \n expanded as follows:
%U=%USERNAME%= user name%USERNAME-WITHOUT-DOMAIN%= user name without the domain part%IU=%USERID%= user ID (not on Windows)%IG=%GROUPID%= user group ID (not on Windows)%D=%HOMEDIR%= the user's home directory%G=%GROUPNAME%= the name of the user's default group
Also environment variables are replaced with their current values. \n For example it is possible to use strings
$HOMEor \n%HOME%to expand to user's home directory (if \n environment variableHOMEis set).Note Short alias names (for example,
%U) are \n case-sensitive and long alias names (for example, \n%USERNAME%) are case-insensitive.- key-store
Each of the
key-storeelements configures one key \n store provider. Thekey-stores/key-storeelement can take the following \n attributes:typeandinit.The
typeattribute is the key store type. \n The currently supported types are\n\"entrust\", \n\"mscapi\", \n\"pkcs11\", \n\"software\", and \n\"zos-saf\".\n Entrust is supported on Windows, only.\nThe
initattribute is the initialization info\n specific to the key-store-provider. The initialization string can contain \n special strings explained above inkey-stores, see\n key-stores.For key store configuration examples, see \n the section called “Key Store Configuration Examples”.\n \n
- user-keys
The
user-keyselement can be used to override the \n default directory for the user keys. Theuser-keyselement \n can take the following attributes:\nThe
directoryattribute defines the directory where the\n user private keys are stored. Enter the full path.The
passphrase-timeoutattribute defines the time (in \n seconds) after which the passphrase-protected private key will time out, \n and the user must enter the passphrase again. The default is0, \n meaning that the passphrase does not time out. The value of this element\n should be longer than thepassphrase-idle-timeoutvalue.By default, the Connection Broker keeps the passphrase-protected private keys open \n once the user has entered the passphrase successfully. This can be changed\n with the passphrase timeout options. When
passphrase-timeout\n is set, the private key stays open (usable without further passphrase prompts) \n until the timeout expires. Thepassphrase-timeoutattribute \n sets the hard timeout, that is set only once when the key is opened and will \n not be reset even if the key is used multiple times.The
passphrase-idle-timeoutattribute defines the time \n (in seconds) after which the passphrase-protected private key will time out \n unless the user accesses or uses the key. Thepassphrase-idle-timeout\n is reset every time the key is accessed. The default is0, \n meaning that the passphrase never times out.Both of the timeout options can be set simultaneously, but notice \n that if the idle timeout is set longer than the hard timeout, the idle \n timeout has no effect.
- identification
The
identificationelement can be used to override the \n default location of the identification file that defines the user keys. \n Theidentificationelement can take the following attributes:\nThe
fileattribute specifies the location of the \n identification file. Enter the full path.The
base-pathattribute defines the directory where \n the identification file expects the user private keys to be stored. This \n element can be used to override the default relative path interpretation of the \n identification file (paths relative to the identification file directory).\nThe
passphrase-timeoutattribute defines the time \n (in seconds) after which the user must enter the passphrase again. \n The default is0, meaning that the passphrase is not \n re-requested.The
passphrase-idle-timeoutattribute defines a time \n (in seconds) after which the passphrase times out if there are no user \n actions. The default is0, meaning that the passphrase does \n not time out.The timeout settings affect only those private keys that are \n listed in the identification file.
- strict-host-key-checking
Note This element is deprecated starting from SSH Tectia Client version 6.1.4.
This element is supported in configuration for backwards \n compatibility and used only if the
policyattribute of \n theserver-authentication-methods/auth-server-publickey\n element underdefault-settingsor \nprofiles/profileis not defined. In this case, the host \n key policy is interpreted based on the values of this option and the \nhost-key-always-askand \naccept-unknown-host-keysoptions.\n See auth-server-publickey for details.\n \n- host-key-always-ask
Note This element is deprecated starting from SSH Tectia Client version 6.1.4.
This element is supported in configuration for backwards \n compatibility and used only if the
policyattribute of \n theserver-authentication-methods/auth-server-publickey\n element underdefault-settingsor \nprofiles/profileis not defined. In this case, the host \n key policy is interpreted based on the values of this option and the \nstrict-host-key-checkingand \naccept-unknown-host-keysoptions. \n See auth-server-publickey for details.\n \n- accept-unknown-host-keys
Note This element is deprecated starting from SSH Tectia Client version 6.1.4.
This element is supported in configuration for backwards \n compatibility and used only if the
policyattribute of \n theserver-authentication-methods/auth-server-publickey\n element underdefault-settingsor \nprofiles/profileis not defined. In this case, the host \n key policy is interpreted based on the values of this option and the \nstrict-host-key-checkingand \nhost-key-always-askoptions. \n See auth-server-publickey for details.\n \nCaution Consider carefully before enabling this option. \n Disabling the host-key checks makes you vulnerable to man-in-the-middle attacks.
- user-config-directory
This element can be used to change the storage location of the \n user-specific configuration files away from the default which is \n
$HOME/.ssh2/on Unix, and \n \"%APPDATA%\\SSH\" on Windows. It can be used for example, \n if you want to store all client-side configurations to a centralized \n location.When this element is added to the global configuration file, the Connection Broker \n reads the following user-specific files in the defined location:
user's key file
user's own configuration files
user's known host keys
user's random_seed file
Windows GUI profile files:
1.ssh2, 2.ssh2SSH_SFTP_BATCH_FILE variable of the
sftpg3clientIn SSH Tectia MFT Events, the events logging database and journaling file \n
(/home/.ssh2/smtf/)
Note Stop all existing SSH applications before modifying the \n
user-config-directorysetting in the Connection Broker \n configuration.The
user-config-directorysetting affects all SSH Tectia \n products running on the same host, for example SSH Tectia Client, SSH Tectia ConnectSecure and SSH Tectia MFT Events.The
user-config-directoryoption takes an attribute \npath, whose value can be either a directory path or one of \n the following variables:%U: The user name.%username%: The user name.%username-without-domain%: The user name without domain definition.%D: The user's home directory.%homedir%: The user's home directory.%USER_CONFIG_DIRECTORY%: The user-specific configuration directory.%IU: The user's ID, on Unix only%userid%: The user's ID, on Unix only%IG: The group ID, on Unix only%groupid%: The group ID, on Unix only
The default is
%USER_CONFIG_DIRECTORY%. This variable \nrefers to the user-specific configuration directory:$HOME/.ssh2\non Unix, and%APPDATA%\\SSHon Windows. \nThe%USER_CONFIG_DIRECTORY%variable cannot be used in \nother settings.- file-access-control
On Unix, this element can be used to enable checking of file access \n permissions defined for the global and user-specific configuration files, \n and for the private keys files. If the permissions are not as expected, the \n Connection Broker will refuse to start, or to use certain private keys.
By default this setting is disabled. On Windows, this element has no effect.
The file permissions are checked differently, if the \n
file-access-controlelement is set in both the global and user \n configuration files, or just in one of them. See the following table for details:\nTable A.1. Different file-access-control effects
Setting in: Permissions checked in: Global config User config Global config User config Private key files yes yes Checked Checked Checked yes - Checked Checked Checked - yes Not checked Checked Checked yes no Checked Checked Not checked no yes Not checked Checked Checked no / - no / - no checking no checking no checking In the table:
Nomeansfile-access-control enable=\"no\". \nSign - means that the setting is not included in the file at all. \nWhen the file access permissions are checked, the controls are applied \nas follows:
Expected permissions for the global configuration file: \n read rights for all, write rights only for the user and group. \n If the permissions are any wider, the Connection Broker will not start.
Expected permissions for the user configuration file: \n only the user has read and write rights. If the permissions are any wider, \n the Connection Broker will not start.
Expected permissions for the private key files: \n only the user has read and write rights. If the permissions \n are any wider, keys that do not pass the check will be ignored.
- protocol-parameters
This element contains protocol-specific values that can be used to \ntune the performance. It should be used only in very specific environments. \nIn normal situations the default values should be used.
The
threadsattribute can be used to define the \nnumber of threads the protocol library uses (fast path dispatcher threads). \nThis attribute can be used to allow more concurrent cryptographic transforms \nin the protocol on systems with more than four CPUs. If the value is set to \nzero, the default value is used.Example of the
threadsattribute:<protocol-parameters threads=\"8\" />\n
- known-hosts
This element can be used to specify locations for storing the host \n keys of known server hosts, and to define the storage format of the host \n key files. If no
known-hostsdirectories are specified, \n the known host keys are stored to the default directories. See the section called “Files” for \n the default locations. On z/OS (only), this element can contain \nkey-storeelements.This element can be used:
To specify non-default directories that contain the \n public-key data or public-key files of known server hosts.
To specify a non-default location for OpenSSH-style \n known_hosts files that contain the public-key data of known server \n hosts.
(On z/OS) To specify a SAF key store \n that contains the certificates of known server hosts.
The server host keys are searched in the
known-hosts\n paths in the order they are specified in the configuration. The settings \n of the last definedknown-hostselement are used when \n storing new host keys.If you define any
known-hostsfile settings, the \n default OpenSSH files will be overridden. So if you wish to make the Connection Broker \n use both the default OpenSSH locations and other locations specified in \n the configuration, you need to specify all the locations separately. \nYou can define several
known-hostselements, and \n each of them can contain one or several attributes:path, \ndirectory,fileand \nfilename-format.The
pathattribute requires a full path to the \n known-hosts file or directory as the value. For example:<known-hosts path=\"/u/username/.ssh/known_hosts\" />\n<known-hosts path=\"/etc/ssh2/hostkeys\" />\n<known-hosts path=\"/u/username/.ssh2/hostkeys\" />\n<known-hosts path=\"/h/username/hostkeys\" filename-format=\"plain\" />\n
The
directoryattribute is used to define that \n known host keys are saved to a non-default directory. Enter the complete \n path to the directory as the value. If the defined directory does not \n exist, it will be created during the first connection attempt. If a file \n is found in its place, the connection will be made but the host key will \n not be stored, and the user gets a warning about it. The \nfilename-formatattribute can be used together with the \ndirectorysetting to define in which format the host key\n files will be stored. Example of thedirectoryattribute:<known-hosts directory=\"<path_to_dir>/MyKEYS\" \n filename-format=\"plain\" />\n
The
pathordirectory(whichever \n is present) defined in the lastknown-hostselement in \n the configuration file will be used when storing new known host keys. If \n both attributes are present in the lastknown-hosts\n element, the location specified in thedirectory\n attribute will be used.The
fileattribute is used to point to an \n OpenSSH-style known_hosts file. Enter the complete path to the file as \n the value. If a directory is found in its place, it is considered an \n error, and the connection attempt will fail. In case the \nknown-hostselement only contains thefile\n attribute, and the defined OpenSSH known_hosts file exists, the received \n host keys are searched first in the defined file, and if not found \n there, the search continues in the default Tectia-specific locations. \nExample of the
fileattribute:<known-hosts file=\"<path_to_file>/.ssh2/openSSH_keys\" />\n
An empty
fileorpathattribute \n will disable the handling of the OpenSSH known_hosts file:<known-hosts file=\"\" />\nor\n<known-hosts path=\"\" />\n
The
filename-formatattribute defines the format in \n which new host key files are stored. Thefilename-format\n attribute is only relevant for the last specified \nknown-hostselement and for the default directory.The
filename-formatattribute takes the values: \nhash(default),plain, and \ndefault(equals to hash).With value
hash, the host key files will be stored \n in format:keys_<hash>, for example \n \"keys_182166d2efe5a134d3fb948646e0b48f780bff6c\".With value
plain, the file name format will be \nkey_<port>_<hostname>.pub, where \n <port> is the port the Secure Shell server is running on and \n <host> is the hostname you use when connecting to the server; for \n example \"key_22_my.example.com.pub\".Setting
<known-hosts filename-format=\"plain\" />\n changes the storage format of host key files for the next \nknown-hostselements or for the default storage location \n if no otherknown-hostselements are present.The
filename-format=\"default\"alternative can be \n used as the last option when the sameknown-hostselement \n is used to define several locations for the host keys some of which store \n the keys in plain format.For more information on the host key storage \n formats, see Host Key Storage Formats.
- extended
This element is reserved for future use.
Key Store Configuration Examples
Example with Software Provider
The software provider handles key pairs stored on disk in standard \nSecure Shell v2 or legacy OpenSSH formats and X.509 certificates stored in \nnative X.509, PKCS#7, and PKCS#12 formats.
To add a single key file (for example, /u/exa/keys/enigma \nand /etc/my_key), specify both the private key file and the \npublic key file:
<key-stores>\n <key-store type=\"software\" \n init=\"key_files(/u/exa/keys/enigma.pub,/u/exa/keys/enigma)\" />\n <key-store type=\"software\" \n init=\"key_files(/etc/my_key.pub,/etc/my_key)\" />\n</key-stores>\n
To add all keys from a specific directory (for example all keys \nfrom /u/exa/keys and /etc/keys):
<key-stores>\n <key-store type=\"software\" \n init=\"directory(path(/u/exa/keys))\" />\n <key-store type=\"software\" \n init=\"directory(path(/etc/keys))\" />\n</key-stores>\n
Example with Entrust Provider
The Entrust provider handles keys and certificates stored in \nthe proprietary Entrust format. You should provide the initialization file \nand the profile-specific file for the Entrust provider. For example:
<key-stores>\n <key-store type=\"entrust\" \n init=\"ini-file(/etc/entrust.ini),profile-file(/etc/profile.epf)\" />\n</key-stores>\n
Example with PKCS#11 Provider
The PKCS#11 provider handles keys and certificates \nstored in PKCS#11 tokens (for example, smart cards or USB tokens).
Specify the dynamic library path for the PKCS provider \nand all or a specific slot. For example, with all slots:
<key-stores>\n <key-store type=\"pkcs11\" init=\"dll(/usr/lib/pkcs.so),slots(all)\" />\n</key-stores>\n
For example, with one slot named sesam:
<key-stores>\n <key-store type=\"pkcs11\" init=\"dll(/usr/local/lib/pkcs.so),slots(sesam)\" />\n</key-stores>\n
The default-settings Element
The default-settings element defines the default \nconnection-related settings. Profile-specific settings can override \nthese settings. \nSee the section called “The profiles Element”.\n
The default-settings element can contain zero or one \ninstance of the following elements in the listed order: \nciphers, macs, transport-distribution, \nrekey, authentication-methods, \nhostbased-default-domain, compression, \nproxy, idle-timeout, \ntcp-connect-timeout, keepalive-interval,\nexclusive-connection, server-banners, \nforwards, extended, remote-environment,\nserver-authentication-methods,\nauthentication-success-message,\nsftpg3-mode, terminal-selection, \nterminal-bell, close-window-on-disconnect,\nquiet-mode, and \nchecksum.
The default-settings element can take one attribute:
The user attribute can be used to define a default \nuser name to be used when connecting to remote servers. The value of the \nuser attribute can be one of the following:
A generic user name that will be used in connections unless another \n user name is specified in the connection profile settings or in the \n connection attempt. Note that the user name is treated case sensitively. \n
\"
%USERNAME%\" can be used to apply the \n user name of the currently logged in user.In case this option is used but left empty, the Connection Broker \n will prompt the user for a user name.
The default-settings element can contain the \nfollowing elements:
- ciphers
This element defines the ciphers that the client will propose to \n the server. The
cipherselement can contain multiple \ncipherelements.The ciphers are tried in the order they are specified.
With SSH Tectia Server for Linux on IBM System z, the client tools will \n automatically use hardware acceleration (CPACF), if it is available, on \n cryptographic operations with the 3DES and AES algorithms.
- cipher
This element selects a cipher
namethat the client \n requests for data encryption.The supported ciphers are\n
3des-cbc,\naes128-cbc,\naes192-cbc,\naes256-cbc,\naes128-ctr,\naes192-ctr,\naes256-ctr,\narcfour,\nblowfish-cbc,\ntwofish-cbc,\ntwofish128-cbc,\ntwofish192-cbc,\ntwofish256-cbc,\n\ncrypticore128@ssh.com, \nseed-cbc@ssh.com,\nand\nnone(no encryption).The default ciphers used by the Connection Broker are, in order: \n
crypticore128@ssh.com(on Windows and Linux x86), \naes128-cbc, \naes192-cbc, \naes256-cbc,\naes128-ctr, \naes192-ctr, \naes256-ctr,\n3des, and \nseed-cbc@ssh.com.The ciphers that can operate in the FIPS mode are\n
aes128-cbc,\naes192-cbc,\naes256-cbc,\nand \n3des-cbc.
<ciphers>\n <cipher name=\"aes128-cbc\" />\n <cipher name=\"3des-cbc\" />\n</ciphers>\n
- macs
This element defines the MACs that the client will propose to \n the server. The
macselement can contain multiple \nmacelements.With SSH Tectia Server for Linux on IBM System z, the client tools will \n automatically use hardware acceleration (CPACF), if it is available, on \n cryptographic operations with the HMAC-SHA1 algorithms.
The MACs are tried in the order they are specified.
- mac
This element selects a MAC
namethat the client \n requests for data integrity verification.The supported MAC algorithms are \n
hmac-md5,\nhmac-md5-96, \nhmac-sha1, \nhmac-sha1-96, \ncrypticore-mac@ssh.com, \nand \nnone(no data integrity verification).The default MACs used by the Connection Broker are, in order: \n
crypticore-mac@ssh.com(on Windows and Linux x86), \nhmac-md5, andhmac-sha1.\n\nThe
hmac-sha1algorithm can operate in the FIPS mode.
<macs>\n <mac name=\"hmac-sha1\" />\n</macs>\n
- transport-distribution
This setting defines the number of transport channels used \n by the Secure Shell connection. Using more than one transport may \n increase the throughput over low bandwidth connections.
The number of transports is given as value of the \n
num-transportsattribute. Currently, a value of 1 to 8 \n transports is supported. On Unix, the default is1transport.\n On Windows, the default is2transports.<transport-distribution num-transports=\"1\" />\n
- rekey
This element specifies the number of transferred
bytes\n after which the key exchange is done again. The value\"0\"\n turns rekey requests off. This does not prevent the server from requesting \n rekeys, however. The default is 1000000000 (1 GB).<rekey bytes=\"1000000000\" />\n
- authentication-methods
This element specifies the authentication methods that are requested \n by the client-side components. The
authentication-methods\n element can contain one of each:auth-hostbased, \nauth-password,auth-publickey, \nauth-gssapi, andauth-keyboard-interactive. \n Alternatively, you can specify multipleauthentication-method\n elements. The order of these elements is free.The authentication methods are tried in the order the \n
auth-*orauthentication-methodelements are \n listed. This means that the least interactive methods should be placed \n first.When several interactive authentication methods are defined as \n allowed, SSH Tectia Client will alternate between the methods and offers each \n of them in turn to the server in case the previous method failed.
- authentication-method
This element specifies an authentication method
name. \n It is included for backwards compatibility. Use theauth-*\n elements instead.The allowed authentication method names are: \n
gssapi-with-mic,publickey, \nkeyboard-interactive,password, and \nhostbased.SSH Tectia Client supports host-based authentication only on \n Unix platforms.
<authentication-methods>\n <authentication-method name=\"hostbased\" />\n <authentication-method name=\"gssapi-with-mic\" />\n <authentication-method name=\"publickey\" />\n <authentication-method name=\"keyboard-interactive\" />\n <authentication-method name=\"password\" />\n</authentication-methods>\n
- auth-hostbased
This element specifies that host-based authentication will be used.
The
auth-hostbasedelement can include a \nlocal-hostnameelement.- local-hostname
This element specifies the local hostname, as the value of the \n
nameattribute, that is advertised to the remote \n server during host-based authentication.The remote server can use the client host name as a hint when \n locating the public key for the client host. This information is not \n significant to the authentication result, but makes it faster to find \n the relevant client host key, if the server has such a big storage of \n host identities, that trying them all would be infeasible.
- auth-password
This element specifies that password authentication will be used.
- auth-publickey
This element specifies that public-key authentication will be used.
The
auth-publickeyelement can include a \nkey-selectionelement.- key-selection
This element specifies the key selection policy the client uses when \n proposing user public keys to the server. The
policy\n attribute can take the valuesautomatic(default) and \ninteractive-shy.In the
automaticmode, the client tries keys \n in the following order:Keys with public key available and private key without \n a passphrase (no user interaction)
Keys with public key available but private key behind \n a passphrase (one passphrase query)
Keys that need a passphrase to get the public key but \n private key without passphrase (one user query for each key which is \n considered and proposed to server, but no user interaction for actual \n public-key login)
The rest of the keys, that is, keys that need a \n passphrase to get the public key and also to get the private key \n
In the
interactive-shymode, the client does \n not try any keys automatically, but it prompts the user to select the \n key from a list of available keys. If the authentication with the \n selected key fails, the client will prompt the user again, removing \n the already tried key(s) from the list. If there is only one key \n candidate available, the key will be tried automatically without \n asking the user.The
key-selectionelement can include a \npublic-keyelement.
- auth-keyboard-interactive
This element specifies that keyboard-interactive methods will be used in \n authentication.\n
- auth-gssapi
This element specifies that GSSAPI will be used in authentication.\n
The
auth-gssapielement can take the following attributes:The
dll-pathattribute specifies where the \n necessary GSSAPI libraries are located. If this attribute is not \n specified, the libraries are searched for in a number of common \n locations. The full path to the libraries should be given, for example, \n\"/usr/lib/libkrb5.so,/usr/lib/libgssapi_krb5.so\".\nOn AIX, the
dll-pathshould include the archive file, \n if applicable, for example,\n\"<path>/libgssapi_krb5.a(libgssapi_krb5.a.so)\". \n Thearchive(shared_object)syntax is not necessary if \n the library is a shared object or has been extracted from the shared \n object.On Windows, the
dll-pathattribute is \n ignored. SSH Tectia Client locates the correct DLL automatically.The
allow-ticket-forwardingattribute defines \n whether SSH Tectia Client allows forwarding the Kerberos ticket over \n several connections. The attribute can have a value of \nyesorno. The default is \nno.
An example of authentication-methods configuration is shown below:
<authentication-methods>\n <auth-hostbased>\n <local-hostname name=\"host.example.com\" />\n </auth-hostbased>\n <auth-gssapi allow-ticket-forwarding=\"yes\"/>\n <auth-publickey>\n <key-selection policy=\"interactive-shy\">\n <public-key type=\"plain\" />\n </key-selection>\n </auth-publickey>\n <auth-keyboard-interactive />\n <auth-password>\n <password file=\"/path/filename\" />\n </auth-password>\n</authentication-methods>\n
- hostbased-default-domain
This element specifies the host's default domain name (as \n
name). This element is used to make sure the fully \n qualified domain name (FQDN) of the client host is transmitted to \n the server when using host-based user authentication.The default domain name is appended to the short hostname \n before transmitting it to the server. This is needed because some \n platforms (Solaris for instance) use the short format of the hostname, \n and with that the signature cannot be created.
The allowed formats of the default domain names are: \n
.example.comand \nexample.com(without the leading dot). For example:<hostbased-default-domain name=\".example.com\" />\n
- compression
This element specifies whether the client sends the data compressed\n (PUT operation). When activated, compression is applied on-the-fly to all \n data sent out through the connection and on all channels in it.
The name of the compression algorithm and the compression level can \n be given as attributes. The
nameattribute can be defined \n asnone(compression not used) orzlib, \n currently the only supported algorithm. By default, compression is not \n used.The
levelattribute can be given an integer from \n0to9. The default compression level is\n6, when compression is activated but no level is given.\nExample: to activate maximum level compression of sent data, \n make the following setting:
<compression name=\"zlib\" level=\"9\" />\n
Compression can also be activated per \n connection with command line tools. For information, see the \n sshg3(1), sftpg3(1) and \n scpg3(1) man pages.
Note that this
compressionsetting does not affect \n received data (GET operations), but their compression is defined on the \n Secure Shell server. SSH Tectia Server always uses compression level 6.- proxy
This element defines rules for HTTP proxy or SOCKS servers the \n client will use for connections. It has a single attribute: \n
ruleset.The format of the attribute value is a sequence of rules \n delimited by semicolons (
;). Each rule has a format \n that resembles the URL format. In a rule, the connection type is \n given first. The type can bedirect, \nsocks,socks4,socks5, or \nhttp-connect(socksis a synonym for \nsocks4). This is followed by the server address and \n port. If the port is not given, the default ports 1080 for SOCKS and \n 80 for HTTP are used.After the address, zero or more conditions delimited by commas \n (
,) are given. The conditions can specify IP addresses \n or DNS names.direct:///[cond[,cond]...]\nsocks://server/[cond[,cond]...]\nsocks4://server/[cond[,cond]...]\nsocks5://server/[cond[,cond]...]\nhttp-connect://server/[cond[,cond]...]
The IP address/port conditions have an address pattern and an \n optional port range:
ip_pattern[:port_range]
The
ip_patternmay have one of the following forms:a single IP address
x.x.x.xan IP address range of the form
x.x.x.x-y.y.y.yan 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 \n expression containing the characters \"*\" and \"?\" and a port range:
name_pattern[:port_range]
An example
proxyelement is shown below. It causes \n the server to access the callback address and thessh.com\n domain directly, access*.examplewith HTTP CONNECT, and \n all other destinations with SOCKS4.<proxy ruleset=\"direct:///127.0.0.0/8,*.ssh.com;\n http-connect://http-proxy.ssh.com:8080/*.example;\n socks://fw.ssh.com:1080/\" />\n
- idle-timeout
This element specifies how long idle time (after all connection \n channels are closed) is allowed for a connection before \n automatically closing the connection. The
timeis given \n in seconds. Thetypeis always connection.The default setting is 5 seconds. Setting a longer time allows the \n connection to the server to remain open even after a session (for example, \n
sshg3) is closed. During this time, a new session to the \n server can be initiated without re-authentication. Setting the time to 0 \n (zero) terminates the connection immediately when the last channel to the \n server is closed.<idle-timeout time=\"5\" />\n
- tcp-connect-timeout
This element specifies a timeout for the TCP connection. When this \n setting is made, connection attempts to an Secure Shell server are stopped \n after the defined time if the remote host is down or unreachable. This \n timeout overrides the default system TCP timeout, and this timeout setting \n can be overridden by defining a
tcp-connect-timeoutsetting \n per connection profile (in theprofilessettings) or per \n connection (on command line).The
timeis given in seconds. The factory default is 5 \n seconds. Value 0 (zero) disables this feature and the default system TCP \n timeout will be used.<tcp-connect-timeout time=\"5\" />\n
- keepalive-interval
This element specifies an interval for sending keepalive messages to \n the Secure Shell server. The
timevalue is given in seconds. \n The default setting is 0, meaning that the keepalive messages are disabled.<keepalive-interval time=\"0\" />\n
- exclusive-connection
The
exclusive-connectionelement can be used to specify \n that a new connection is opened for each new channel.The word
yesornois given as the \n value of theenableattribute. The default is \nno(open connections are reused for new channels requested \n by a client).- server-banners
This element defines whether the server banner message file (if it \n exists) is visible to the user before login. The word \n
yesornois given as the value of the \nvisibleattribute. The default isyes.\nTo eliminate server banners:
<server-banners visible=\"no\" />\n
- forwards
This element contains
forwardelements that \n define whether X11 or agent forwarding (tunneling) are allowed on \n the client side.An example forward configuration, which denies X11 \n forwarding and allows agent forwarding globally, is shown \n below:
<forwards>\n <forward type=\"x11\" state=\"denied\" />\n <forward type=\"agent\" state=\"on\" />\n</forwards>\n
For more information on using X11 \n and agent forwarding, see X11 Forwarding and \n Agent Forwarding.
- extended
This element is reserved for future use.
- remote-environment
This element contains
environmentelements which define \n the environment variables to be passed to the server from the client side. \n The environment variables are then set on the server when requesting a \n command, shell or subsystem.Note that the server can restrict the setting of environment \n variables.
- environment\n \n
This element defines the name and value of the environment \n variables, and whether the Connection Broker should process the value. Possible \n attributes are
name,value, and \nformat.An example remote environment configuration:
<remote-environment>\n <environment name=\"FOO\" value=\"bar\" />\n <environment name=\"QUX\" value=\"%Ubaz\" format=\"yes\" />\n <environment name=\"ZAPPA\" value=\"%Ubaz\" />\n</remote-environment>\n
You can use
%Uin thevalueto indicate \n a user name. Whenformat=\"yes\"is also defined, the Connection Broker \n processes the%Uinto the actual user name before sending \n it to the server.Let's assume the user name is
joedoein this example. \n The example configuration results in the following environment variables \n on the server side, provided that the server allows setting the \n environment variables:FOO=bar \nQUX=joedoebaz \nZAPPA=%Ubaz \n
You can override the remote environment settings made in the \n configuration file if you use the
sshg3command with the \n following arguments on the command-line client: \n--remote-environmentor \n--remote-environment-formatFor information on the command-line options, see \n sshg3(1).\n \n
- server-authentication-methods
This
server-authentication-methodselement can be \n used to force the Connection Broker to use only certain methods in server \n authentication. This element can containauth-server-publickeyand \nauth-server-certificateelements (one of each). \n Alternatively, you can specify up to twoauthentication-method\n elements. The order of these elements is free.If only
auth-server-certificateis specified, server \n certificate is needed. If no server certificate is received, connection \n fails.If only
auth-server-publickeyis specified, \n (plain) server public key is needed. If no server public key is received, \n connection fails.If both
auth-server-certificateand \nauth-server-publickeyare specified, server certificate \n is used if present. Otherwise server public key is used.- auth-server-certificate
The
auth-server-certificateelement specifies \n that certificates are used for server authentication.- auth-server-publickey
The
auth-server-publickeyelement specifies that \n public host keys are used for server authentication.Note The host key policy settings have changed in version 6.1.4 \n and are now defined in the
auth-server-publickey\n element.The element takes attribute
policythat defines \n how unknown server host keys are handled. It can have the following \n values:strict: Connect to the server only if \n the host key is found from the host key store and matches.If the policy is set to
strict, the Connection Broker never \n adds host keys to the user's.ssh2/hostkeys\n directory upon connection, and refuses to connect to hosts whose key has \n changed. This provides maximum protection against man-in-the-middle \n attacks. However, it also means you must always obtain host keys via \n out-of-band means, which can be troublesome if you frequently connect to \n new hosts.ask(default):\n If the server host key is not found from the host key store, the user \n will be asked if he wants to accept the host key. If the host key has \n changed, the user is warned about it and asked how to proceed. If the \n client application is not able to ask the user (for example, \n sftpg3 in batch mode,-B), the \n connection will be disconnected.trust-on-first-useortofu:\n If the server host key is not found, it is stored to the user's \n.ssh2/hostkeysdirectory. If the host key has \n changed, the connection will be disconnected.advisory:\n Use of this setting effectively disables server authentication, which \n makes the connection vulnerable to active attackers.If the server host key is not found in the host key store, it will \n be added to the user's
.ssh2/hostkeys\n directory without user interaction. If the host key has changed, the \n connection will be continued without user interaction. The incident will \n be audited if logging is enabled.When the policy is set to
advisory, the keys from \n new hosts are automatically accepted and stored to the host key database \n without prompting acceptance from the user. However, changed host keys \n (from hosts whose keys are already in the database) are not stored, but \n they are accepted for that connection only.This setting should be used only if logging is enabled for the \n Connection Broker (by default, logging is enabled only if the Broker is \n run by the MFT Events service).
Caution Consider carefully before setting the policy to
advisory. \n Disabling the host-key checks makes you vulnerable to man-in-the-middle attacks.
In policy modes other than
strict, if logging \n is enabled for the Connection Broker, SSH Tectia Client will log information about \n changed and new host public keys with their fingerprints in the syslog \n (on Unix) or Event Viewer (on Windows).Note When transparent FTP tunneling or FTP-SFTP \n conversion is used, accepting the host key cannot be prompted from the \n user. Either the policy must be set to
tofuor the host \n keys of the Secure Shell tunneling and SFTP servers must be obtained \n beforehand and stored based on the IP addresses of the servers.If the
policyattribute is not defined, the host \n key policy is interpreted based on the values of the old\nstrict-host-key-checking,\nhost-key-always-ask, and\naccept-unknown-host-keys\n options as shown in Table A.2 below.Note In version 6.1.4 and later, the host key policy setting in \n the user-specific configuration file always takes precedence over the \n setting in the global configuration file.
Table A.2. Interpretation of old host key policy (SSH Tectia Client 5.0.0-6.1.3) to new host key policy (SSH Tectia Client 6.1.4 and later)
strict-host-key-checking accept-unknown-host-keys host-key-always-ask Policy - - - ask (default) enabled - - strict enabled enabled - strict enabled enabled enabled ask enabled - enabled ask - enabled - trust on first use - enabled enabled ask - - enabled ask - authentication-method
The
server-authentication-methods/authentication-method\n element specifies an authentication methodname. This element is \n included for backwards compatibility. Use theauth-server-*elements instead.<server-authentication-methods>\n <authentication-method name=\"publickey\" />\n <authentication-method name=\"certificate\" />\n</server-authentication-methods>\n
An example
server-authentication-methodselement is shown below:<server-authentication-methods>\n <auth-server-publickey policy=\"ask\" />\n <auth-server-certificate />\n</server-authentication-methods>\n
- authentication-success-message
This setting defines whether the
AuthenticationSuccessMsg\n messages are output. Theauthentication-success-message\n element takes attributeenablewith value \nyesorno. The default is \nyes, meaning that the messages are output and logged.- sftpg3-mode
This setting defines how the sftpg3 client behaves \n when transferring files. The
sftpg3-modeelement takes attribute \ncompatibility-modewith the following values:tectia(the default) - \n sftpg3 fransfers files recursively, meaning that \n files from the current directory and all its subdirectories are transferred.\nftp- theget/putcommands \n are executed assget/sputmeaning that they transfer a \n single file; and commandsmget/mputhave recursion depth \n set to 1 meaning that they only transfer files from the specified directory, \n not from subdirectories.openssh- commandsget/put/mget/mput\n behave alike, and the recursion depth is set to 1, meaning that only files \n from the specified directory are transferred, not from subdirectories.
The recursion depth can be overridden by using the sftpg3 \nclient's commands
get/put/mget/mputwith command-line \noption--max-depth=\"LEVEL\". For more information, see \nsftpg3(1).- terminal-selection
This element defines how the SSH Tectia terminal behaves when \n the user selects text with double-clicks. The element takes one attribute: \n
selection-type, whose value can be:select-words- double-clicking selects one word at \n a time, space and all punctuation characters are used as delimiters. \n This is the default.select-paths- selects strings of characters between \n spaces, meaning a selection is extended over characters\\/.-_, \n so that for example a path to a file can be selected by double-clicking \n anywhere in the path.- terminal-bell
This element defines whether SSH Tectia terminal repeats audible \n notifications from the destination server. This option is only applied \n to connections with Unix servers. The element takes one attribute, \n
bell-style, whose value can be:none- no audible notifications are usedpc-speaker- the user's PC speakers beep when an \n audible notification is indicated by the destination serversystem-default- the SSH Tectia terminal sounds the \n default alerts defined in the system on the destination server. This is \n the default.- close-window-on-disconnect
This element defines that also the SSH Tectia terminal window is to be \n closed while disconnecting from a server session by pressing \n
CTRL+D. The element takes one attribute, \nenable, whose value can beyesor \nno. The default isnomeaning that \nCTRL+Dcloses only the server connection but the \n SSH Tectia terminal window remains open. \n- quiet-mode
This setting defines whether the command line clients should \n suppress warnings, error messages and authentication success messages.\n The
quiet-modeelement takes attributeenable\n with valueyesorno. The default is \nno, meaning that the errors and messages are output and \n logged.The
quiet-modeelement affects command line tools \nscpg3,sshg3, andsftpg3. \n Enabling the quiet mode here with settingquiet-mode enable=\"yes\"\n is the same as running these clients with option-q. \n Note that the-qcommand line parameter will take priority \n over thequiet-modeelement set in this configuration file.- checksum
The
checksumelement can be used to define a default\nsetting for comparing checksums. This default overwrites the factory setting \nthat checksums are not checked for files smaller than 32kB.The
checksumelement takes attribute \ntype, whose value can be:yes|YES- MD5 checksums are checked on files larger than 32kBno|NO- checksums are not usedmd5|MD5- only MD5 checksums are checked on files larger than 32kB, use \n this in FIPS modesha1|SHA1- only SHA1 checksums are checked on files larger than 32kB, use \n this in other than FIPS modemd5-force|MD5-FORCE- MD5 checksums are forced on all files in FIPS modesha1-force|SHA1-FORCE- SHA1 checksums are forced on all filescheckpoint|CHECKPOINT- checkpointing is forced on \n large files that are transferred one by one.Note that checksums can also be defined with the command line \n clients
scpg3andsftpg3, or with \n environment variables. The order of priority of the three checksum \n settings (in case they are different) is as follows, the later one always \n overwrites the previous value:checksumsetting in the configuration file- environment value
- command line arguments.
The profiles Element
The profiles element defines the connection \nprofiles for connecting to the specified servers. Element \nprofiles can contain multiple profile \nelements. Each profile defines the connection rules to one server. The \nsettings in the profile element override the default \nconnection settings.
When a profile is used for the connection, the settings in the profile \noverride the default settings. \nSee the section called “The default-settings Element”.\n
- profile
The
profileelement defines a connection \n profile. It has the following attributes:id, \nname,host,port, \nprotocol,\nconnect-on-startup,user, and \ngateway-profile.The profile
idmust be a unique identifier that \n does not change during the lifetime of the profile.An additional
namecan be given to the profile. This is \n a free-form text string. The name can be used for connecting with the \n profile on the command line, so define a unique name for each \n profile.The
hostattribute defines the address of the Secure Shell \n server host and it is a mandatory setting. The address can be either an IP \n address or a domain name. The valuehost=\"*\"can be used \n to prompt the user to enter the host address when starting the session.\n An empty value
host=\"\"can be used when the profile \n is used with transparent TCP or FTP tunneling or FTP-SFTP conversion and \n the host name is taken from the application \n (filter-engine/rule[@hostname-from-app=\"yes\"]). \n See rule for details.\n \nThe
portis a mandatory setting. It defines the port number \n of the Secure Shell server listener.\n The default port is22.The
protocolis a mandatory setting. It defines the \n used communications protocol.\n Currently the only allowed value issecsh2.If you want to make the connection specified by the profile \n automatically when the Connection Broker is started, set the value of the \n
connect-on-startupattribute toyes. In \n this case, give also theuserattribute (the username \n the connection is made with). You also need to set up some form of\n non-interactive authentication for the connection.The
userattribute specifies the user name for opening \n the connection. The value \"%USERNAME%\" can be used to \n apply the user name of the currently logged in user. The value \nuser=\"*\"can be used to prompt the user to enter the user \n name when logging in. When theuserattribute is not defined,\n the user name defined in the default connection settings will be used.\n The
gateway-profileattribute can be used to create \n nested tunnels. The tunnels defined under thelocal-tunnel\n element of the profile, and the tunnels defined underfilter-engine\n andstatic-tunnelsthat refer to the profile can be nested. \n The profile name through which the connection is made is given as the \n value of the attribute. The first tunnel is created using the gateway host \n profile and from there the second tunnel is created to the host defined in \n this profile.- hostkey
This element gives the path to the remote server host \n public key file as a value of the
file\n attribute.Alternatively, the public key can be included as a base64-encoded ASCII block.
- ciphers
This element defines the ciphers used with this profile. \n See ciphers for details.\n \n
- macs
This element defines the MACs used with this profile. \n See macs for details.\n \n
- transport-distribution
This element defines the transport distribution for this profile. \n See transport-distribution for details.\n \n
- rekey
This element defines the rekeying settings used with this profile. \n See rekey for details.\n \n
- authentication-methods
This element defines the authentication methods used with this profile. \n See authentication-methods for details.\n \n
- user-identities
This element specifies the identities used in user public-key \n authentication. In contrast to the
key-storeselement \n that specifies all the keys that are available for the Connection Broker, this \n element can be used to control the keys that are attempted in \n authentication when this connection profile is used and to specify the \n order in which they are attempted.The
user-identitieselement can contain multiple \nidentityelements. When multipleidentity\n elements are used, they are tried out in the order they are \n listed.The
identityelement has the following attributes: \nidentity-file,file,hash, \nid, anddata.The
identity-fileattribute specifies that the user \n identity is read in the identification file used with public-key \n authentication. Enter the full path to the file if it is located \n somewhere else than the default identification file directory which is\n$HOME/.ssh2. See also ssh-broker-g3(1).The
fileattribute specifies the path to the public-key file \n (primarily) or to a certificate. Enter the full path and file name as the value.\nThe
hashattribute is used to enter the hash of the \n public key that will be used to identify the related private key. The \n key must be available for the Connection Broker The public key hashes of the \n available keys can be listed with the ssh-broker-ctl \n tool. See also ssh-broker-ctl(1).The
idattribute is reserved for future use.The
dataattribute is reserved for future use.\nAn example
user-identitieselement is shown below:<user-identities>\n <identity identity-file=\"C:\\\\ mykey\" />\n <identity file=\"$HOME/user/.ssh2/id_dsa_2048_a\" />\n <identity file=\"C:\\\\private_keys\\id_dsa_2048_a\" />\n <identity hash=\"#a8edd3845005931aaa658b5573609e7d31e23afd\" />\n</user-identities>\n
- compression
This element defines the compression settings used with this profile. \n See compression for details.\n \n
- proxy
This element defines the HTTP proxy and SOCKS server settings used with this profile. \n See proxy for details.\n \n
If
gateway-profilehas been defined for this profile, \n the proxy setting is ignored and the default proxy setting or \n the proxy setting of the gateway profile is used instead.- idle-timeout
This element defines the idle timeout settings used with this profile. \n See idle-timeout for details.\n \n
- tcp-connect-timeout
This element defines the TCP connection timeout for this profile. \n The timeout is used to terminate connection attempts to Secure Shell \n servers that are down or unreachable. The default value is 5 seconds.\n See tcp-connect-timeout for details.\n \n
- keepalive-interval
This element defines an interval for sending keepalive messages to \n the Secure Shell server. The setting applies to this profile. The default \n value is 0, meaning that no keepalive messages are sent.\n See keepalive-interval for details.\n \n
- exclusive-connection
This element defines whether a new connection is opened for each \n new channel when a connection is made with this profile. \n See exclusive-connection for details.\n \n
- server-banners
This element defines the server banner setting used with this profile. \n See server-banners for details.\n \n
- forwards
This element defines the forwards allowed with this profile. \n See forwards for details.\n \n
- tunnels
The
tunnelselement defines the tunnels that are \n opened when a connection with this profile is made. The element can \n contain multiplelocal-tunnelandremote-tunnel\n elements.- local-tunnel
This element defines a local tunnel (port forwarding) that is \n opened automatically when a connection is made with the connection \n profile. It has five attributes:
type,listen-port, \nlisten-address,dst-host,dst-port, \n andallow-relay.The
typeattribute defines the type of the tunnel. \n This can betcp(default, no special processing), \nftp(temporary forwarding is created for FTP data \n channels, effectively securing the whole FTP session), or \nsocks(SSH Tectia Client/ConnectSecure will act as a SOCKS server for other \n applications, creating forwards as requested by the SOCKS \n transaction).The
listen-portattribute defines the listener port \n number on the local client.The
listen-addressattribute can be used to define \n which network interfaces on the client should be listened. Its value \n can be an IP address belonging to an interface on the local host. \n Value0.0.0.0listens to all interfaces. The default is \n127.0.0.1(localhost loopback address on the client). \n Setting any other value requires settingallow-relay=\"yes\".Whenever a connection is made to the specified listener, the \n connection is tunneled over Secure Shell to the remote server and \n another connection is made from the server to a specified destination \n host and port (
dst-host,dst-port). \n The connection from the server onwards will not be secure, it is a \n normal TCP connection.The
dst-hostanddst-port\n attributes define the destination host address and port. The value of \ndst-hostcan be either an IP address or a domain \n name. The default is127.0.0.1(localhost = server host).The
allow-relayattribute defines whether \n connections to the listened port are allowed from outside the \n client host. The default isno.\n If you useallow-relay=\"yes\", it will check also the \nlisten-addresssetting.For more information on using local tunnels, see \n Local Tunnels.
- remote-tunnel
This element defines a remote tunnel (port forwarding) that is \n opened automatically when a connection is made with the connection \n profile. It has four attributes:
type,listen-port, \nlisten-address,dst-host,dst-port, \n andallow-relay.The
typeattribute defines the type of the tunnel. \n This can be eithertcp(default, no special processing) \n orftp(temporary forwarding is created for FTP data \n channels, effectively securing the FTP session between the client and \n server).The
listen-portattribute defines the listener port \n number on the remote server.The
listen-addressattribute can be used to define \n which network interfaces on the server should be listened. Its value \n can be an IP address belonging to an interface on the server host. \n Value0.0.0.0listens to all interfaces. The default is \n127.0.0.1(localhost loopback address on the server). \n Setting any other value requires thatallow-relay=\"yes\".Whenever a connection is made to this listener, the \n connection is tunneled over Secure Shell to the local client and \n another connection is made from the client to a specified destination \n host and port (
dst-host,dst-port). The \n connection from the client onwards will not be secure, it is a \n normal TCP connection.The
dst-hostanddst-port\n attributes define the destination host address and port. The value of \ndst-hostcan be either an IP address or a domain \n name. The default is127.0.0.1(localhost = client host).The
allow-relayattribute defines whether \n connections to the listener port are allowed from outside the \n server host. The default isno.For more information on using remote tunnels, see \n Remote Tunnels.
- extended
This element is reserved for future use.
- remote-environment
This element defines the remote environment settings used with \n this profile. Within the
remote-environmentelement, define \n anenvironmentelement for each environment variable to be \n passed to the server. \n See remote-environment for details.\n \n- server-authentication-methods
This element defines the server authentication methods allowed with this profile. \n See server-authentication-methods for details.\n \n
- password
This element can be used to specify a user password that the \n client will send as a response to password authentication.
The password can be given directly in the
string\n attribute, or a path to a file containing the password can be given in \n thefileattribute, or a path to a program or a script \n that outputs the password can be given in thecommand\n attribute.When using the
commandoption to refer to a \n shell script, make sure the script also defines the user's shell, and \n outputs the actual password. Otherwise the executed program fails, \n because it does not know what shell to use for the shell script. For \n example, if the password string is defined in a file named \nmy_password.txt, and you want to use the bash \n shell, include these lines in the script:#!/usr/bash\ncat /full/pathname/to/my_password.txt\n
Caution If the password is given using this option, it is \n extremely important that the
ssh-broker-config.xml\n file, the password file, or the program are not accessible by anyone \n else than the intended user.Note Any password given with the command-line options will \n override this setting.
An example connection profile is shown below:
<profile name=\"rock\"\n id=\"id1\"\n host=\"rock.example.com\"\n port=\"22\"\n connect-on-startup=\"no\"\n user=\"doct\">\n\n <hostkey file=\"key_22_rock.pub\">\n </hostkey>\n\n <authentication-methods>\n <auth-publickey />\n <auth-password />\n </authentication-methods>\n\n <server-authentication-methods>\n <auth-server-publickey policy=\"strict\" />\n </server-authentication-methods>\n\n <server-banners visible=\"yes\" />\n\n <forwards>\n <forward type=\"agent\" state=\"on\" />\n <forward type=\"x11\" state=\"on\" />\n </forwards>\n\n <tunnels>\n <local-tunnel type=\"tcp\"\n listen-port=\"143\"\n dst-host=\"imap.example.com\"\n dst-port=\"143\"\n allow-relay=\"no\" />\n </tunnels>\n\n <remote-environment>\n <environment name=\"FOO\" value=\"bar\" />\n <environment name=\"QUX\" value=\"%Ubaz\" format=\"yes\" />\n <environment name=\"ZAPPA\" value=\"%Ubaz\" />\n </remote-environment>\n\n</profile>\n
The static-tunnels Element
The static-tunnels setting is used to configure the \nbehaviour of the automatic tunnels. You can create listeners for local \ntunnels automatically when the Connection Broker starts up. The actual tunnel is formed \nthe first time a connection is made to the listener port. If the connection \nto the server is not open at that time, it will be opened automatically as \nwell.
The static-tunnels element can contain any number of \ntunnel elements.
- tunnel
The
tunnelelement specifies a static tunnel. \n It has the following attributes:type,listen-port, \nlisten-address,dst-host,dst-port, \nallow-relay, andprofile.The
typeattribute defines the type of the \n tunnel. This can be eithertcporftp.tcpspecifies a listener for generic TCP \n tunnelingftpspecifies a listener for FTP tunneling \n (also the FTP data channels are tunneled)
The
listen-portattribute defines the listener port \n number on the local client.The
listen-addressattribute can be used to define \n which network interfaces on the client should be listened. Its value \n can be an IP address belonging to an interface on the local host. \n Value0.0.0.0listens to all interfaces. The default is \n127.0.0.1(localhost loopback address on the client). \n Setting any other value requires thatallow-relay=\"yes\".The
dst-hostanddst-portattributes \n define the destination host address and port. The value of \ndst-hostcan be either an IP address or a domain name. \n The default is127.0.0.1(localhost = server host).The
allow-relayattribute defines whether \n connections to the listened port are allowed from outside the \n client host. The default isno.The
profileattribute specifies the connection profile id that is used for the tunnel.
<static-tunnels>\n <tunnel type=\"tcp\"\n listen-address=\"127.0.0.1\"\n listen-port=\"9000\"\n dst-host=\"st.example.com\"\n dst-port=\"9000\"\n allow-relay=\"no\"\n profile=\"id1\" />\n</static-tunnels>\n
The gui Element
The gui element is used to adjust the SSH Tectia terminal \nGUI settings. The gui element takes the following attributes: \n\n hide-tray-icon, show-exit-button, \n show-admin, enable-connector, \n and show-security-notification. The last two settings have \n effect only when transparent TCP tunneling is activated on \n the system.\n \nAll of these must have yes or no as the \nvalue.
The hide-tray-icon attribute\tcontrols whether the SSH Tectia \nicon is displayed in the system tray. The default is \nno (the tray icon is displayed).
The show-exit-button attribute controls whether the \nExit command is displayed in the shortcut menu of the SSH Tectia icon. \nThe default is yes.
The show-admin attribute defines whether the \nConfiguration command is displayed in the SSH Tectia icon \nshortcut menu. The default is yes. If the button is not \ndisplayed, the SSH Tectia Configuration tool can be started by running \nssh-tectia-configuration.exe, located by default in directory \n\"C:\\Program Files\\SSH Communications Security\\SSH Tectia\\SSH Tectia Broker\".
The enable-connector attribute \ndefines whether transparent TCP tunneling is active and capturing \napplication connections for tunneling. The default is \nyes.
On Windows, the show-security-notification attribute \ndefines whether the SSH Tectia security notifications are shown upon establishing or \nclosing transparent TCP or FTP tunnels. The default is yes.
<gui hide-tray-icon=\"no\"\n show-exit-button=\"yes\"\n show-admin=\"yes\"\n enable-connector=\"yes\"\n show-security-notification=\"yes\" />\n
The filter-engine Element
The filter-engine element handles the \nsettings related to transparent TCP tunneling that has to be separately selected when \ninstalling the SSH Tectia Client.
| Note |
|---|---|
The On Unix, the global configuration is stored as \n |
For configuration examples, see these sample files:
On Unix:
etc/ssh2/ssh-broker-config-example-capture.xmland \netc/ssh2/ssh-broker-config-example.xmlOn Windows: \"
<INSTALLDIR>\\SSH Tectia Broker\\ssh-broker-config-example-capture.xml\" and\n\"<INSTALLDIR>\\SSH Tectia Broker\\ssh-broker-config-example.xml\"
The top level element is filter-engine. It has two \nattributes: ip-generate-start and \nftp-filter-at-signs (used with SSH Tectia ConnectSecure, only).
The ip-generate-start attribute defines the start address \nof the pseudo IP address space. Pseudo IPs are generated by the Connection Broker when \napplications do the DNS query through the SSH connection capture component.
With SSH Tectia ConnectSecure, the ftp-filter-at-signs attribute can be used with \nFTP-SFTP conversion when scripts are used to open a connection directly from \nthe FTP/SFTP client to the SFTP server, bypassing any proxies. This attribute \ndefines that SSH Tectia ConnectSecure uses the FTP user name, FTP server name, and FTP server \npassword specified in the FTP script.
The FTP script is expected to specify the username in format \nftp-user@proxy-user@ftp-server and the password in format \nftp-password@proxy-password. The @ sign is used to \nextract the relevant data from the strings.
The ftp-filter-at-signs takes yes and \nno as values, no is the default.
When ftp-filter-at-signs=\"yes\", SSH Tectia ConnectSecure cuts the username \nstring at the first @ sign to extract the ftp-user and \nat the last @ sign to extract the ftp-server, and the \nrest of the string is ignored. Likewise, the passwords string is cut at the \nlast @ sign and the first part is used as the password on the SFTP \nserver.
| Note |
|---|---|
Under the |
- network\n\n\n\n
The
networkelement specifies a \"location\" \n where SSH Tectia Client/ConnectSecure is running. By using thenetwork\n element, you can implement location-awareness for SSH Tectia Client/ConnectSecure.\n It has four attributes:id,address, \ndomain, andip-generate-start.The
idattribute specifies a unique identifier for the \nnetworkelement. Theaddressattribute specifies the \n address of the network. It can be missing or empty, in which case it is \n not used. Thedomainattribute contains the domain name of \n the computer. It can also be missing or empty, in which case it is not \n used. Theip-generate-startattribute defines the start \n address of the pseudo IP space. If it is defined here, it overrides the \nip-generate-startattribute of thefilter-engine\n element.- dns\n\n\n
Note The
dnselement exists for backward-compatibility reasons. \n Currently theruleelement is used for the same settings.The
dnselement creates a DNS rule for the \n filter engine. It has six attributes:id, \nnetwork-id,application, \nhost,ip-address, and \npseudo-ip. \n For their descriptions, see \n rule below.\n- filter\n\n\n
Note The
filterelement exists for backward-compatibility reasons. \n Currently theruleelement is used for the same settings.The
filterelement specifies an action for a \n connection. It has the following attributes: \ndns-id,ports, \naction,profile-id, \ndestination,destination-port,\nfallback-to-plain.The
dns-idattribute is a reference to a \ndnselement.For the descriptions of the other \n attributes, see rule below.
- rule
The
ruleelement specifies how a filtered connection\n will be handled. It has the following attributes: \napplication,host, \nip-address,pseudo-ip, \nports,action, \nprofile-id,destination, \ndestination-port,username,\nhostname-from-app,username-from-app,\nfallback-to-plain.The
applicationattribute can be used to specify one or more \n applications to which the rule is applied. This can be a regular \n expression using the egrep syntax. \n For information on the syntax, \n see Appendix D.The
hostattribute specifies a target hostname. It \n can be a regular expression using the egrep syntax.The
ip-addressattribute specifies the target host \n IP address. It can be a regular expression using the egrep syntax. \n If both the hostname and the IP address are defined, thehost\n attribute takes \n precedence and theip-addressattribute is ignored.The
pseudo-ipsetting has the following effects \n when theip-addressis left empty and thehost\n matches:When
pseudo-ip=\"yes\", the Connection Broker assigns \n a pseudo IP address for the target host and SSH Tectia Server resolves the real \n IP address. The pseudo IP addresses should be used when accessing an internal \n network from the outside, because name resolution for the machines in \n the internal network is not available from the outside.When
pseudo-ip=\"no\", a normal DNS query \n is made for the target hostname. The default value isno.\n
The
portsattribute can be a single port or a range. \n A range is specified with a hyphen between two integers (for example\n\"21-25\").Note For FTP-SFTP conversion, always specify the port unambiguosly if \nfallback mode is set. Do not use an asterisk (*), because it causes problems \nin passive mode file transfer when connected to a plaintext FTP server.
The
actionattribute specifies the action to be done \n when a filter matches. Its value can beDIRECT, \nBLOCK,TUNNEL,FTP-TUNNEL, or \nFTP-PROXY.DIRECTcauses the connection \n to be made directly as plaintext without tunneling or FTP-SFTP \n conversion.BLOCKcauses the connection to be \n blocked.FTP-TUNNELactivates transparent FTP\n tunneling\nTUNNELactivates transparent TCP\n tunnelingFTP-PROXYcauses the FTP-SFTP conversion \n to start and a connection to be made to the Secure Shell SFTP server. \n
The
profile-idattribute can be used to specify the \n connection profile that defines the connection settings.If the
profile-idattribute is left empty and \nhostname-from-app=\"yes\"is specified, the Secure Shell \n connection is made to the server specified by the client application \n using default settings. If aprofile-idis specified and \n alsohostname-from-app=\"yes\"is specified, or the referred \n profile has*(an asterisk) or empty as the value of the \nhostattribute, the Secure Shell connection is made to the \n server specified by the client application using the profile \n settings.The
destinationanddestination-port\n attributes can be used to define a static destination address and port number \n that will be used as the end point of the connection instead of the \n original address and port given by the application.The
usernameattribute can be used to define the user \n name used for connecting to the Secure Shell server, or you can define the \n path from where the Connection Broker should retrieve the user name.The
hostname-from-appattribute defines whether the \n Connection Broker should extract the Secure Shell server's host name from data sent \n by the application, or use a Secure Shell server defined by the \n connection profile inprofile-id. The value is \nyesorno, and the default is \nno.When
hostname-from-app=\"no\", the tunnel \n will be \n created to the Secure Shell server specified in the connection profile \n referred in theprofile-idattribute. Note that with \n transparent tunneling, the connection from the Secure Shell server to \n the final destination application will be unsecured and in plaintext. To \n achieve end-to-end security, the Secure Shell server should reside on \n the same host as the application.When
hostname-from-app=\"yes\", the tunnel \n will be \n created to the destination server specified by the application. \n This setting can be used with both FTP and TCP tunneling and FTP-SFTP conversion.\n When usinghostname-from-app=\"yes\", it is no longer necessary \n to create a separate connection profile for each destination host. Note \n that this requires that a Secure Shell server is installed to each\n destination server (or thatfallback-to-plainis enabled to \n allow direct connections to those servers that do not have Secure \n Shell installed).The
username-from-appattribute defines whether the \n FTP tunneling or FTP-SFTP conversion extracts the user name from data \n sent by the FTP application. The value isyesor \nno. The default isno.When
username-from-app=\"yes\", the user name received \n from the FTP client application is used. This setting can be used with FTP \n tunneling and FTP-SFTP conversion. This setting will override any user \n name settings made in a related connection profile. When \nusername-from-app=\"no\", the user name is taken from the \n connection profile defined with theprofile-idattribute.The
fallback-to-plainattribute can be used to define \n whether a direct (unsecured) connection is used if creating the \n tunnel fails or the connection to the Secure Shell server fails. \n The default value isno.\n Normally, when the secured connection fails when applying a filter rule, \n the Connection Broker will return a \"host not reachable\" error. \n \n \nNote Do not enable the
fallback-to-plainand \npseudo-ipoptions at the same time. If they both are enabled, \n and a secure connection fails, the application will try a direct connection \n with the pseudo IP, which will not work.
The logging Element
The logging element changes the logging settings that \ndefine the log event severities and logging facilities. The element contains \none or more log-target and log-events elements.
- log-target
This element specifies the log target for auditing. By default, the broker \ndoes not log anything. This element can be used to direct log data to a \nfile or syslog.
The
log-targetelement can havefileandtypeas attributes.The
typeattribute specifies the logging facility \nwhere the audit data is output to. The value can befile, \nsyslogordiscard.The
fileattribute sets the file system path where \nthe audit data is written to. If thetypeattribute has \nsyslogordiscardset, the \nfileattribute is not allowed.- log-events
This element sets the severity and facility of different \n logging events. The events have reasonable default values, \n which are used if no explicit logging settings are made. This \n setting allows customizing the default values.
The element can also contain one or more \n
log-targetelements. When defined here, the \nlog-targetelement will override the definition given in the \nlogging/log-target.For the events,
facilityand \nseveritycan be set as attributes. The events \n itself should be listed inside thelog-events\n element.The facility can be
normal,daemon, \nuser,auth,local0, \nlocal1,local2,local3, \nlocal4,local5,local6, \nlocal7, ordiscard. Setting the \n facility todiscardcauses the server to ignore \n the specified log events.On Windows, only the
normaland \ndiscardfacilities are used.The severity can be
informational, \nnotice,warning,error, \ncritical,security-success, or \nsecurity-failure.Any events that are not specifically defined in the \n configuration file will use the default values. The defaults \n can be overridden for all remaining events by giving an empty \n
log-eventselement after all other definitions \n and by setting a severity value for it.In the names of log events, the characters '*' and '?' can be used as wildcars.
For a complete list of log events, see \nAppendix E.
An example logging configuration that logs all events, which are \nprogrammed to be logged by default, both to /tmp/foo \nand to syslog.
<logging>\n <log-target file=\"/tmp/foo\" />\n <log-target type=\"syslog\" />\n</logging>\n
An example logging configuratin in which events are logged to \n/tmp/foo, except those whose event name matches \n\"Key_store_*\", which will be discarded.
<logging>\n <log-target file=\"/tmp/foo\" />\n <log-events facility=\"discard\">\n Key_store_*\n </log-events>\n</logging>\n
| |
\n Copyright ![](\"images/copyright.gif\")
2010 SSH Communications Security Corp.
\n This software is protected by international copyright laws. All rights reserved.
Contact Information