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.

FIPS mode will be used, if it is so specified either in global or in user configuration file (or both).

<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 defines public-key infrastructure (PKI) settings used for validating remote server authentication certificates. The element can have three attributes: end-point-identity-check, default-domain, http-proxy-url, and socks-server-url.

The end-point-identity-check attribute specifies whether the client will verify the server's hostname against the Subject Name or Subject Alternative Name (DNS Address) in the server's certificate. If set to no, the fields in the server host certificate are not verified and the certificate is accepted based on validity period and CRL check only. Note that this is a possible security risk, as anyone with a certificate issued by the same trusted CA that issues the server host certificates can perform a man-in-the-middle attack on the server if a client has the end-point identity check disabled. The default value is yes.

The default-domain attribute can be used when the end-point identity check is enabled. It specifies the default domain part of the remote system name and it is used if only the base part of the system name is available. The default-domain is appended to the system name if it does not contain a dot (.).

If the default domain is not specified, the end-point identity check fails, for example, when a user tries to connect to a host "rock" giving only the short hostname and the certificate contains the full DNS address "rock.example.com".

The http-proxy-url attribute defines an 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, to make the SOCKS server use host socks.ssh.com and port 1080 for connections outside of networks 192.196.0.0 (16-bit domain) and 10.100.23.0 (8-bit domain), and to get these networks connected directly, set socks-server-url as follows:

"socks://mylogin@socks.ssh.com:1080/192.196.0.0/16,10.100.23.0/24"

The cert-validation element can contain multiple ldap-server, ocsp-responder, and crl-prefetch elements, a dod-pki element, and multiple ca-certificate elements.

An example of a certificate validation configuration is shown below:

<cert-validation end-point-identity-check="yes" 
                 default-domain="example.com"
                 http-proxy-url="http://proxy.example.com:8080">
  <ldap-server address="ldap://ldap.example.com:389" />
  <ocsp-responder url="http://ocsp.example.com:8090" validity-period="0" /> 
  <crl-prefetch url="file:///full.path.to.crlfile" interval="1800"/>
  <dod-pki enable="no" />
  <ca-certificate name="ssh_ca1"
                  file="ssh_ca1.crt"
                  disable-crls="no"
                  use-expired-crls="100" />
</cert-validation>         

There can be one <key-stores> instance under the <general> element. It can have any amount of <key-store> elements each of which configures one key store provider.

See the section called “Key Store Configuration Examples” for key store configuration examples.

This element enables strict host key checking. If it is enabled, the Connection Broker never adds host keys to the user's .ssh2/hostkeys directory upon connection, and refuses to connect to hosts whose key has changed. This provides maximum protection against man-in-the-middle attacks. However, it can be somewhat annoying if you frequently connect to new hosts.

The word yes or no is given as the value of the enable attribute. The default is no (the user is asked whether to accept a new or changed host key).

Strict host key checking will be used, if it is so specified in either the global or the user configuration file (or both).

<strict-host-key-checking enable="yes" />

This element defines whether the Connection Broker should prompt the user to accept the proposed host key even if it is already known.

The word yes or no is given as the value of the enable attribute. The default is no (known host keys are accepted without prompting).

Host keys are always asked, if it is so specified in either the global or the user configuration file (or both).

<host-key-always-ask enable="yes" />

This element defines whether the Connection Broker will always accept the proposed host key without saving the key. It is the equivalent of automatically answering "Once" to all accept-host-key prompts.

The word yes or no is given as the value of the enable attribute. The default is no (unknown host keys are not automatically accepted).

If this element is set to no either in the global or the user configuration file, the changed or new host keys are prompted normally. Additionally, setting this element to yes takes effect only when both strict-host-key-checking and host-key-always-ask are set to no (or are not explicitly defined).

<accept-unknown-host-keys enable="no" />

	Caution
	Consider carefully before enabling this option. Disabling the host-key checks can make you vulnerable to a man-in-the-middle attack.

This element specifies the location of an OpenSSH-style known-hosts file that contains the public key data of known server hosts. The full path to the known_hosts file must be given as a value of the path attribute.

<known-hosts path="/u/username/.ssh/known_hosts" />

The hostname(s) in the file must be in clear-text format. Hashed hostnames are not supported.

This element defines the ciphers that the client will propose to the server. The ciphers element can contain multiple cipher elements.

The ciphers are tried in the order they are specified.

<ciphers>
  <cipher name="crypticore128@ssh.com" />
  <cipher name="aes128-cbc" />
</ciphers>

This element defines the MACs that the client will propose to the server. The macs element can contain multiple mac elements.

The MACs are tried in the order they are specified.

<macs>
  <mac name="hmac-sha1" />
</macs>

This setting defines the number of transport channels used by the Secure Shell connection. Using more than one transport may increase the throughput over low bandwidth connections.

The number of transports is given as value of the num-transports attribute. Currently, a value of 1 to 8 transports is supported. On Unix, the default is 1 transport. On Windows, the default is 2 transports.

<transport-distribution num-transports="1" />

This element specifies the number of transferred bytes after which the key exchange is done again. The value "0" turns rekey requests off. This does not prevent the server from requesting rekeys, however. The default is 1000000000 (1 GB).

<rekey bytes="1000000000" />

This element specifies the authentication methods that are requested by the client. The authentication-methods element can contain multiple authentication-method elements.

The authentication methods are tried in the order of the authentication-method elements. This means that the least interactive methods should be placed first.

<authentication-methods>
  <authentication-method name="hostbased" />
  <authentication-method name="gssapi-with-mic" />
  <authentication-method name="publickey" />
  <authentication-method name="keyboard-interactive" />
  <authentication-method name="password" />
</authentication-methods>

This element specifies the host's default domain name (as name). This element is used to make sure the fully qualified domain name (FQDN) of the client host is transmitted to the server when using host-based user authentication.

The default domain name is appended to the short hostname before transmitting it to the server. This is needed because some platforms (Solaris for instance) use the short format of the hostname, and with that the signature cannot be created.

The allowed formats of the default domain names are: .example.com and example.com (without the leading dot). For example:

<hostbased-default-domain name=".example.com" />

This element specifies whether to use compression.

The name of the compression algorithm and the compression level can be given as attributes. Currently only zlib is supported as the algorithm. The level can be an integer from 0 to 9. By default, compression is not used.

<compression name="none" />

This element defines rules for HTTP or SOCKS proxy servers the client will use for connections. It has a single attribute: ruleset.

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:

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 element 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.

<proxy ruleset="direct:///127.0.0.0/8,*.ssh.com;
                http-connect://http-proxy.ssh.com:8080/*.example;
                socks://fw.ssh.com:1080/" />

This element specifies how long idle time (after all connection channels are closed) is allowed for a connection before automatically closing the connection. The time is given in seconds.

The default setting is 5 seconds. Setting a longer time allows the connection to the server to remain open even after a session (for example, sshg3) is closed. During this time, a new session to the server can be initiated without re-authentication. Setting the time to 0 (zero) terminates the connection immediately when the last channel to the server is closed.

<idle-timeout time="5" />

This element defines whether the server banner message file (if it exists) is visible to the user before login. The word yes or no is given as the value of the visible attribute. The default is yes.

<server-banners visible="no" />

This element contains forward elements that define whether X11 or agent forwarding (tunneling) are allowed on the client side.

An example forward configuration, which allows X11 forwarding and denies agent forwarding globally, is shown below:

<forwards>
  <forward type="x11" state="denied" />
  <forward type="agent" state="on" />
</forwards>

For more information on using X11 and agent forwarding, see X11 Forwarding and Agent Forwarding.

This element contains environment elements that define the environment variables to be passed to the server from the client side by default. The environment variables are then set on the server when requesting a command, shell or subsystem.

You can define the environment variables also for each connection profile. See remote-environment under the profiles element.

Note that the server can restrict the setting of environment variables.

You can override the remote environment settings made in the configuration file if you use the sshg3 command with the --remote-environment or --remote-environment-format arguments on the command-line client.

See --remote-environment name=value in the sshg3 description.

The profile element defines a connection profile. It has seven attributes: id, name, host, port, connect-on-startup, user, and gateway-profile.

The profile id must be a unique identifier that does not change during the lifetime of the profile.

An additional name can be given to the profile. This is a free-form text string. Define a unique name for each profile.

The host is a mandatory setting. The address can be either an IP address or a domain name. The value '*' can be used to prompt the user to enter the hostname when logging in. With the Connector, '%DESTINATION_HOSTNAME%' can be given as the hostname. Then the Connector will pick up the destination IP address from the tunneled application, and open a tunnel to the same host. This way it is no longer necessary to create a separate connection profile for each destination host.

The port is a mandatory setting. The default port is 22.

If you want to make the connection specified by the profile automatically at reboot, set the value of the connect-on-startup attribute to yes. In this case, give also the user attribute (the username the connection is made with). You also need to set up some form of non-interactive authentication for the connection.

In the user attribute, the value '%USERNAME%' can be used to set the user name to the current user. The value '*' can be used to prompt the user to enter the user name when loggin in.

The gateway-profile attribute can be used to create nested tunnels. The profile name through which the connection is made is given as the value of the attribute. The first tunnel is created using the gateway host profile and from there the second tunnel is created to the host defined in this profile.

An example connection profile is shown below:

<profile name="rock"
         id="id1"
         host="rock.example.com"
         port="22"
         connect-on-startup="no"
         user="doct">

  <hostkey file="key_22_rock.pub">
  </hostkey>

  <authentication-methods>
    <authentication-method name="publickey" />
    <authentication-method name="password" />
  </authentication-methods>

  <server-banners visible="yes" />

  <forwards>
    <forward type="agent" state="on" />
    <forward type="x11" state="on" />
  </forwards>

  <tunnels>
    <local-tunnel type="tcp"
                  listen-port="143"
                  dst-host="imap.example.com"
                  dst-port="143"
                  allow-relay="no" />
  </tunnels>

  <remote-environment>
    <environment name="FOO" value="bar" />
    <environment name="QUX" value="%Ubaz" format="yes" />
    <environment name="ZAPPA" value="%Ubaz" />
  </remote-environment>

</profile>

The tunnel element specifies a static tunnel. It has six attributes: type, listen-port, dst-host, dst-port, allow-relay, and profile.

The type attribute defines the type of the tunnel. This can be either tcp or ftp.

The listen-port attribute defines the local port to be listened. The dst-host and dst-port attributes define the destination host address and port. The value of dst-host can be either an IP address or a domain name. The default is 127.0.0.1 (localhost = server host).

The allow-relay attribute defines whether connections to the listened port are allowed from outside the client host. The default is no.

The profile attribute specifies the connection profile id that is used for the tunnel.

Users apply a script to connect to an FTP server via a proxy. The script defines the username as ftp-user@proxy-user@ftp-server and the password as ftp-password@proxy-password. When FTP-SFTP conversion is used instead, make the setting ftp-filter-at-signs=yes, and the following will be done:

SSH Tectia cuts the username string at the first @ sign to extract the ftp-user and at the last @ sign to extract the ftp-server, and the rest of the string is ignored. Likewise, the passwords string is cut at the last @ sign and the preciding part is used as the password on the FTP server.

The network element specifies a "location" where SSH Tectia Connector is running. Using the network elements you can implement location-awareness for SSH Tectia Connector. It has four attributes: id, address, domain, and ip-generate-start.

The id attribute specifies a unique identifier for the network element. The address attribute specifies the address of the network. It can be missing or empty, in which case it is not used. The domain attribute contains the domain name of the computer. It can also be missing or empty, in which case it is not used. The ip-generate-start attribute defines the start address of the pseudo IP space. If it is defined here, it overrides the ip-generate-start attribute of the filter-engine element.

The dns element creates a DNS rule for the filter engine. It has six attributes: id, network-id, application, host, ip-address, and pseudo-ip.

The id attribute specifies a unique identifier for the dns element. The network-id attribute contains a reference to a network element. This can be left empty if the dns entry does not bind to a specific network. The application attribute specifies the application for which this DNS entry is used. This can be a regular expression.

The host attribute specifies a target hostname. It can be a regular expression. The ip-address attribute specifies the target host IP address. It can be a regular expression. When both the hostname and the IP address are defined, the host attribute takes precedence and the ip-address attribute is ignored. When the ip-address is left empty and the host matches one of the following things happen:

The filter element specifies an action for a connection. It has five attributes: dns-id, ports, action, profile-id, and fallback-to-plain.

The dns-id attribute is a reference to a dns element.

The ports attribute can be a single port or a range. A range is specified with a dash between two integers (such as "21-25").

	Note
	For FTP-SFTP conversion, always specify the port unambiguosly if fallback mode is set. Do not use an asterisk (*), because it causes problems in passive mode file transfer when connected to a plaintext FTP server.

The action attribute specifies the action to be done when a filter is used. Its value can be DIRECT, BLOCK, TUNNEL (with SSH Tectia Connector), or FTP-PROXY (with SSH Tectia Client with EFT Expansion Pack).

When applying the filter rule, if creating the tunnel fails (or the connection to the Secure Shell server fails) the Connection Broker will normally return a "host not reachable" error. However, if the fallback-to-plain attribute is set to yes, a direct (unsecured) connection is used instead. In FTP-SFTP conversion on Unix, this requires that option -F is used with the ssh-convert-ftp command. See ssh-convert-ftp (EFT Expansion Pack on Unix)(1).

The fallback-to-plain and pseudo-ip options should not be enabled at the same time. If they are, and the secure connection fails, the application will try a direct connection with the pseudo IP, which will not work.

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 specifed 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 will 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 F.