- ciphers
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.
- cipher
This element selects a cipher name that the client
requests for data encryption.
The supported ciphers are
3des-cbc,
aes128-cbc,
aes192-cbc,
aes256-cbc,
arcfour,
blowfish-cbc,
twofish-cbc,
twofish128-cbc,
twofish192-cbc,
twofish256-cbc,
seed-cbc@ssh.com,
and
none (no encryption).
The default ciphers used by the SOCKS Proxy are, in order:
aes128-cbc,
aes192-cbc,
aes256-cbc,
3des, and
seed-cbc@ssh.com.
<ciphers>
<cipher name="aes128-cbc" />
</ciphers>
|
- macs
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.
- mac
This element selects a MAC name that the client
requests for data integrity verification.
The supported MAC algorithms are
hmac-md5,
hmac-md5-96,
hmac-sha1,
hmac-sha1-96,
and
none (no data integrity verification).
The default MACs used by the SOCKS Proxy are, in order:
hmac-md5, and
hmac-sha1.
<macs>
<mac name="hmac-sha1" />
</macs>
|
- transport-distribution
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.
<transport-distribution num-transports="1" />
|
- rekey
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" />
|
- authentication-methods
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-method
This element specifies an authentication method name.
The allowed authentication method names are:
publickey,
keyboard-interactive, password, and
hostbased.
<authentication-methods>
<authentication-method name="hostbased" />
<authentication-method name="publickey" />
<authentication-method name="keyboard-interactive" />
<authentication-method name="password" />
</authentication-methods>
|
- hostbased-default-domain
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 domain names are:
.example.com and
example.com (without the leading dot).
<hostbased-default-domain name=".ssh.hostname.example.com" />
|
- compression
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" />
|
- proxy
This element defines rules for HTTP or SOCKS proxy servers the
SOCKS Proxy 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:
The ip_pattern may have one of the following forms:
-
a single IP address x.x.x.x
-
an IP address range of the form x.x.x.x-y.y.y.y
-
an IP sub-network mask of the form x.x.x.x/y
The DNS name conditions consist of a hostname which may be a regular
expression containing the characters "*" and "?" and a port range:
name_pattern[:port_range]
|
An example proxy 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/" />
|
- idle-timeout
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,
transparent tunneling) 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" />
|
