SSHD2_CONFIG(5) SSH2 SSHD2_CONFIG(5)
NAME
sshd2_config - configuration file format for sshd2 on z/OS
CONFIGURATION FILE
sshd2 reads configuration data from /opt/tec-
tia/etc/sshd2_config (or the file specified with -f on the
command line). The file contains keyword-value pairs, one
per line.
A configuration file can begin with "metaconfiguration"
information, that is, information configuring the configu-
ration language itself.
If the configuration file starts with a line matching the
following egrep-style regex
#.*VERSION[ \t\f]+[0-9]+.[0-9]+
it is interpreted as the version of the configuration
style. If this kind of line is not found, the version is
considered to be "1.0".
The version string can be followed by one or more metacon-
figuration parameters. The lines have to start with '#',
and they have to match the following egrep style regex:
#[# \t]+[A-Z0-9]+[ \t]+.*
The parsing of metaconfiguration directives stops with the
first non-recognized line.
Version 1.1 and later recognize the following parameter:
REGEX-SYNTAX
This denotes the regex syntax used to parse the
configuration file in question. The regex syntax
is used in parsing the labels, lists, and so on,
and when matching something with the regex patterns
specified in the configuration file.
The value can be egrep, ssh, zsh_fileglob or tradi-
tional (the arguments are not case-sensitive).
zsh_fileglob and traditional are synonymous.
Subconfiguration files can be specified in the main con-
figuration file, see HostSpecificConfig and UserSpecific-
Config. Note that if changes are made in the main config-
uration file, sshd2 will have to be restarted, for example
by sending a signal to it:
# kill -HUP `cat /opt/tectia/var/run/sshd2.pid`
In the configuration file, empty lines and lines starting
with '#' are ignored as comments.
Otherwise a line is of the format 'keyword arguments'.
Note that it is possible to enclose arguments in quotes,
and use the standard C convention. The possible keywords
and their meanings are as follows (note that the keywords
are not case-sensitive but the arguments are case-sensi-
tive):
AllowAgentForwarding or ForwardAgent
Specifies whether agent forwarding is permitted.
This parameter is implemented mainly for complete-
ness. Usually, you should allow users to freely
forward agent connections. The argument must be
yes or no. The default is yes.
AllowedAuthentications
This keyword specifies the authentication methods
that are allowed. Known authentication methods
are: keyboard-interactive, password, publickey, and
hostbased. The default is "publickey,password".
The order of the listed authentication methods is
important, as the first method will be used that
matches the methods the client is proposing.
With RequiredAuthentications, the system adminis-
trator can force the users to complete several
authentications before they are considered authen-
ticated. See RequiredAuthentications.
AllowGroups
This keyword can be followed by any number of group
name patterns, separated by commas. If specified,
login is allowed only if one of the groups the user
belongs to matches one of the patterns. Patterns
are matched using the egrep syntax (see
sshregex(1)), or the syntax specified in the meta-
configuration header of the configuration file.
You can use the comma character (,) in the patterns
by escaping it with backslash (\). By default, all
groups are allowed to log in.
Note that all other authentication steps must still
be successfully completed. AllowGroups and Deny-
Groups are additional restrictions and never
increase the tolerance.
AllowHosts
This keyword can be followed by any number of host-
name patterns, separated by commas. If specified,
login is allowed only from hosts whose name matches
one of the patterns. Patterns are matched using
the egrep syntax (see sshregex(1)), or the syntax
specified in the metaconfiguraion sect1ion of the
configuration file. If you want the pattern to be
matched with the host's IP address only (ignoring
the canonical hostname), prefix your pattern with
"\i". You can also use subnet masks (e.g
127.0.0.0/8) by prefixing the pattern with "\m".
DNS is used to map the client's hostname into a
canonical hostname. If the name cannot be mapped,
the IP address is used as the hostname. By
default, all hosts are allowed to connect.
AllowSHosts
This keyword can be followed by any number of host-
name patterns, separated by commas, same as the
option AllowHosts. The entries in .shosts,
.rhosts, /etc/hosts.equiv and /etc/shosts.equiv are
ignored if they do not match one of the patterns
given here (if there are any).
AllowTcpForwarding
Specifies whether TCP forwarding is permitted.
Note: Disabling TCP forwarding does not improve
security at all unless you deny the user shell
access at the same time (see ssh-dummy-shell(1)):
users that have a shell can always install their
own forwarders. The argument must be yes or no.
The default is yes.
AllowTcpForwardingForGroups
The syntax is the same as in AllowGroups, but
instead of login, this controls the ability to for-
ward ports in remote or local forwarding. See the
security note under option AllowTcpForwarding.
AllowTcpForwardingForUsers
The syntax is the same as in AllowUsers, but
instead of login, this controls the ability to for-
ward ports in remote or local forwarding. See the
security note under option AllowTcpForwarding.
AllowUsers
This option can be followed by any number of pat-
terns of the form user or user@host, separated by
commas. The details explained under option
AllowHosts apply accordingly. By default, all
users are allowed to log in.
Note that all the other login authentication steps
must still be successfully completed. AllowUsers
and DenyUsers are additional restrictions.
AuthHostbased.Cert.Required
This keyword specifies whether the client must pre-
sent a host certificate during user authentication.
If this option is set to yes, also the AllowedAu-
thentications keyword must contain the value host-
based. If the server does not receive a certifi-
cate, the authentication fails. The argument must
be yes or no. The default is no.
AuthHostbased.Cert.ValidationMethods
This keyword specifies the method used for certifi-
cate validation during host-based user authentica-
tion. Its value can be tectia or saf, or both
(saf,tectia). The default is tectia.
If saf is specified, RACF/SAF is used for validat-
ing client host certificates. The host
certificates must exist in a trusted key ring
defined by the KnownHostsEkProvider keyword. Note
that when only SAF validation is used, the certifi-
cate validity period and revocation status are not
checked.
If tectia is specified (or the keyword is missing
from the configuration), the Tectia Certificate
Validator (ssh-certd) is used for validating client
host certificates. The host certificates must be
issued by a trusted certification authority defined
in the HostCA, HostCANoCRLs, HostCAEkProvider, or
HostCAEkProviderNoCRLs keyword of ssh_certd_config.
If both values are specified, the RACF/SAF valida-
tion is performed first and after that the Tectia
validation. The host certificates must exist
in a trusted key ring defined by the KnownHost-
sEkProvider keyword. Also the CA certificate of the
issuing certification authority must exist in a
trusted key ring defined by the HostCAEkProvider or
HostCAEkProviderNoCRLs keyword of ssh_certd_config.
AuthInteractiveFailureTimeout
Specifies the delay in seconds of the server after
a failed attempt to log in using keyboard-interac-
tive and password authentication. The default is 2.
AuthKbdInt.NumOptional
Specifies how many optional submethods must be
passed before the authentication is considered a
success (note that all required submethods must
always be passed). See AuthKbdInt.Optional for
specifying optional submethods, and AuthKb-
dInt.Required for required submethods. The default
is 0, although if no required submethods are speci-
fied, the client must always pass at least one
optional submethod.
AuthKbdInt.Optional
Specifies the optional submethods keyboard-interac-
tive will use. Currently only the password and plu-
gin submethods are supported on z/OS. AuthKb-
dInt.NumOptional specifies how many optional sub-
methods must be passed. The keyboard-interactive
authentication method is considered a success when
the specified number of optional submethods and all
required submethods are passed. The plugin sub-
method is special. It can be used if a system
administrator wants to create a new authentication
method. See also AuthKbdInt.NumOptional and
AuthKbdInt.Required.
AuthKbdInt.Plugin
Specify this to point to a program that is used by
the plugin submethod in keyboard-interactive.
sshd2 converses with this program using a line-
based protocol, so it is easy to implement it, for
example as a shell script. If the plugin submethod
is used, and this is not set, or the specified pro-
gram does not exist or cannot be run, the submethod
will fail, which may cause the whole user authenti-
cation to fail. This is not set by default. More
information about the protocol can be found in the
distribution package. RFC.kbdint_plugin_protocol
has a description of the protocol used and an exam-
ple script is called kbdint_plugin_example.sh.
Note that the program is run with the privileges of
the sshd2 process, typically root, so be careful.
AuthKbdInt.Required
Specifies the required submethods that must be
passed before the keyboard-interactive authentica-
tion method can succeed. See AuthKbdInt.Optional.
AuthKbdInt.Retries
Specifies how many times the user can retry key-
board-interactive. The default is 3.
AuthorizationEkProvider
This keyword specifies the external key provider
for accessing external public keys and certificates
used for user public-key authentication. The value
is of the format "provider:initstring". Currently,
the only valid value for provider on z/OS is zos-
saf. For the format of the initstring, see ssh-
externalkeys(5).
AuthorizationEkInitStringMapper
This keyword specifies a path to external program
(for example, "/path/to/mapper.sh") that can be
used for generating the initialization string used
in public-key authentication with external keys.
The usage of the mapper program should be the fol-
lowing:
mapper.sh username "initstring"
username is the name of the user found in the cer-
tificate. initstring is the initialization string
as it is given in the AuthorizationEkProvider key-
word. The program should print the modified ini-
tialization string into standard output.
AuthorizationEkInitStringMapperTimeout
This keyword specifies a timeout (in seconds) for
the AuthorizationEkInitStringMapper. If the server
is unable to read the full output from the mapper
in the given period, the operation will fail and
the mapper program will be terminated. The default
timeout is 10 seconds.
AuthorizationFile
Specifies the name of the user's authorization
file. The default is $HOME/.ssh2/authorization.
AuthorizedKeysFile
Specifies the name of the user's authorized keys
file. This is given as a pattern string which is
expanded by sshd2. %D is the user's home directory,
%U is the user's login name, %IU is the user's user
ID (uid), and %IG is user's group ID (gid).
The file is a legacy-format file containing multi-
ple public keys so that each line holds a single
public key. Keys are in the ssh1/openssh public
key format.
This option is disabled by default.
The public-key option from="host" is equivalent to
allow-from="host" and from="!host" is equivalent to
deny-from="host". Also the $SSH_ORIGINAL_COMMAND is
equivalent to $SSH2_ORIGINAL_COMMAND. Note that the
public-key option permitopen="host:port" is not
supported, please see the ForwardACL configuration
option to achieve a similar setup.
AuthPassword.ChangePlugin
Set this to the path of the password change plug-
in, typically ssh-passwd-plugin (if you have the
binary packages or you have configured the source
with --with-passwd-plugin). This allows the pass-
word to be changed during the authentication phase,
instead of using a system's passwd command to do
it. This replaces the actual session, requiring the
user to log in again. This option is also used by
the password submethod of keyboard-interactive. By
default this is not set.
AuthPublicKey.Algorithms
Specifies the public key signature algorithm to be
used in client authentication.
The supported algorithms are
ssh-dss,
ssh-dss-sha224@ssh.com,
ssh-dss-sha256@ssh.com,
ssh-dss-sha384@ssh.com,
ssh-dss-sha512@ssh.com,
x509v3-sign-dss,
x509v3-sign-dss-sha224@ssh.com,
x509v3-sign-dss-sha256@ssh.com,
x509v3-sign-dss-sha384@ssh.com,
x509v3-sign-dss-sha512@ssh.com,
ssh-rsa,
ssh-rsa-sha224@ssh.com,
ssh-rsa-sha256@ssh.com,
ssh-rsa-sha384@ssh.com,
ssh-rsa-sha512@ssh.com,
x509v3-sign-rsa,
x509v3-sign-rsa-sha224@ssh.com,
x509v3-sign-rsa-sha256@ssh.com,
x509v3-sign-rsa-sha384@ssh.com,
and
x509v3-sign-rsa-sha512@ssh.com.
Multiple public key signature algorithms can be
specified as a comma-separated list. Special values
for this option are Any, AnyStd, AnyPublicKeyAlgorithm,
and AnyStdPublicKeyAlgorithm. Any allows all the
supported algorithms; AnyStd allows only those
mentioned in the IETF-SecSh draft (x509v3-sign-dss,
x509v3-sign-rsa, ssh-dss, ssh-rsa);
AnyPublicKeyAlgorithm and AnyStdPublicKeyAlgorithm
are analogous to the first two cases.
The default list is
ssh-rsa,
ssh-rsa-sha256@ssh.com,
ssh-dss,
ssh-dss-sha256@ssh.com,
x509v3-sign-dss,
x509v3-sign-dss-sha256@ssh.com,
x509v3-sign-rsa, and
x509v3-sign-rsa-sha256@ssh.com.
AuthPublicKey.Cert.Required
This keyword specifies whether the client must pre-
sent a user certificate during user authentication.
If this option is set to yes, also the AllowedAu-
thentications keyword must contain the value pub-
lickey. If the server does not receive a certifi-
cate, the authentication fails. The argument must
be yes or no. The default is no.
AuthPublicKey.Cert.ValidationMethods
This keyword specifies the method used for certifi-
cate validation during user public-key authentica-
tion. Its value can be tectia or saf, or both
(saf,tectia). The default is tectia.
If saf is specified, RACF/SAF is used for validat-
ing user certificates. The user certificates must
exist in a trusted key ring defined by the Autho-
rizationEkProvider keyword. Note that when only SAF
validation is used, the certificate validity period
and revocation status are not checked.
If tectia is specified (or the keyword is missing
from the configuration), the Tectia Certificate
Validator (ssh-certd) is used for validating user
certificates. The user certificates must be issued
by a trusted certification authority defined in the
Pki or PkiEkProvider keyword of ssh_certd_config.
If both values are specified, the user certificate
is read from RACF/SAF and the username is taken
form the certificate. After that the Tectia
validation is performed. The CA certificate of the
issuing certification authority must exist in a
trusted key ring defined by the PkiEkProvider key-
word of ssh_certd_config.
AuthPublicKey.MaxSize
Specifies the maximum size of a public key that can
be used to log in. Value 0 disables the check. The
default is 0 (disabled).
AuthPublicKey.MinSize
Specifies the minimum size of a public key that can
be used to log in. Value 0 disables the check. The
default is 0 (disabled).
BannerMessageFile
Specifies the path to the message that is sent to
the client before authentication. Note, however,
that the client is not obliged to show this mes-
sage. The default is /opt/tectia/etc/ssh_banner_message
(if defined).
CertdListenerPath
Specifies the path where the server tries to con-
nect to the certificate validator. Mainly
intended for debugging and testing. The default is
/opt/tectia/var/run/ssh-certd-listener.
CheckMail
Makes sshd2 print information on whether there is
new mail or not when a user logs in interactively.
(On some systems this information is also printed
by the shell, /etc/profile, or equivalent.) The
argument must be yes or no. The default is yes.
ChRootGroups
This option works like ChRootUsers, except that it
can be used to list groups instead of single users.
Groups are listed on the server in /etc/group.
Follows the logic of DenyGroups.
ChRootUsers
sshd2 gives all users listed here a chrooted envi-
ronment (e.g. /home). This stops users from
accessing sensitive information on the server's
file system. Users are defined on the server in
/etc/group. More than one group can be listed,
separated by a comma. This is not a default
option. The logic follows that of DenyUsers.
Ciphers
Specifies the ciphers to use for encrypting the
session. The supported ciphers are aes128-cbc,
aes192-cbc, aes256-cbc, 3des-cbc, arcfour, blowfish-
cbc, cast128-cbc, twofish-cbc, twofish128-cbc,
twofish192-cbc, twofish256-cbc,
cast128-12-cbc@ssh.com. des-cbc@ssh.com, seed-
cbc@ssh.com, and rijndael-cbc@ssh.com.
Multiple ciphers can be specified as a comma-sepa-
rated list. Special values for this option are
Any, AnyStd, none, AnyCipher, and AnyStdCipher.
Any allows all ciphers including none, which
means that the data on the line is in plaintext;
AnyStd allows only those mentioned in the IETF-
SecSh draft
(aes128-cbc, 3des-cbc, twofish128-cbc, cast128-cbc,
twofish-cbc, blowfish-cbc, idea-cbc, aes192-cbc,
aes256-cbc, twofish192-cbc, twofish256-cbc, arcfour)
plus none; AnyCipher and AnyStdCipher are analogous
to the first two cases but exclude none.
The default list is aes128-cbc, aes192-cbc, aes256-
cbc and 3des-cbc.
DenyGroups
This keyword can be followed by any number of group
name patterns, separated by commas. If specified,
login is denied if one of the groups the user
belongs to matches one of the patterns. Otherwise,
this option is parsed and matched identically to
AllowGroups. By default, all users are allowed to
log in.
If a user's group matches a pattern in both Deny-
Groups and AllowGroups, login is denied.
Note that all other authentication steps must still
be successfully completed. AllowGroups and Deny-
Groups are additional restrictions and never
increase the tolerance.
DenyHosts
This keyword can be followed by any number of host-
name patterns, separated by commas. If specified,
login is denied from hosts whose names match any of
the patterns. See AllowHosts.
DenySHosts
This keyword can be followed by any number of host-
name patterns, separated by commas, just as the
option DenyHosts. The entries in .shosts, .rhosts,
/etc/hosts.equiv and /etc/shosts.equiv are ignored
if they match one of the patterns given here (if
there are any). See AllowSHosts.
DenyTcpForwardingForGroups
The syntax is the same as in DenyGroups, but
instead of login, this controls the ability to for-
ward ports, in remote or local forwarding. See
security note under option AllowTcpForwarding.
DenyTcpForwardingForUsers
The syntax is the same as in DenyUsers, but instead
of login, this controls the ability to forward
ports, in remote or local forwarding. See security
note under option AllowTcpForwarding.
DenyUsers
This is the opposite of AllowUsers and works
accordingly. If a user's name matches a pattern in
both DenyUsers and AllowUsers, login is denied.
Note that all other authentication steps must still
be successfully completed. AllowUsers and
DenyUsers are additional restrictions.
DisableVersionFallback
Selects whether to disable fallback compatibility
code for earlier, or otherwise incompatible ver-
sions of software. Do not disable this unless you
know what you are doing. The argument must be yes
or no. The default is no.
ExternalAuthorizationProgram
If set, this program is run to verify whether the
user is authorized to log in. sshd2 converses with
this program using a line-based protocol, so it is
easy to implement for example as a shell script. If
this is set, and the program does not exist or can-
not be run, authorization (user login) will be
denied. This will not be set by default. More
information about the protocol can be found in the
distribution package, RFC.authorization_pro-
gram_protocol has a description of the protocol
used and an example script is called ext_authoriza-
tion_example.sh. Note that the program is run with
the privileges of the sshd2 process, typically
root, so be careful.
ForwardACL
With this option, you can have more fine-grained
control over what the client is allowed to forward
and where. The format for this option is
(allow|deny) (local|remote) user-pat forward-pat
[originator-pat]
user-pat will be used to match the client user, as
specified under option UserSpecificConfig. for-
ward-pat is a pattern of format host-id[%port].
This has different interpretations depending on
whether the ACL is specified for local or remote
forwardings. For local forwardings, the host-id
will match with target host of the forwarding, as
specified under option AllowHosts. port will match
the target port. Also, if the client sent a host-
name, the IP is looked up from the DNS, which will
be used to match the pattern. For remote forward-
ings, where the forwarding target is not known (the
client handles that end of the connection), this
will be used to match the listen address specified
by the user (and as such is not as usable as with
local forwardings). port will match the port the
server is supposed to be listening to with this
forwarding. With local forwards, originator-pat
will match the originator address that the client
has reported. Remember, if you do not administer
the client machine, or the users on that machine
have shell access, they may use a modified copy of
ssh that can be used to lie about the originator
address. Also, with NATs (Network Address Transla-
tion) the originator address will not be meaningful
(it will probably be an internal network address).
Therefore you should not rely on the originator
address with local forwardings, unless you know
exactly what you are doing. With remote forward-
ings, on the other hand, originator-pat will match
with the IP address of the host connecting to the
forwarded port. This will be valid information, as
it is the server checking the information.
If you specify any allow directives, all forward-
ings in that class (local or remote) not specifi-
cally allowed will be denied. (Note that local and
remote forwardings are separate in this respect;
e.g. if you have one "allow remote" definition,
local forwardings are still allowed, pending other
restrictions.) If a forwarding matches both allow
and deny directives, the forwarding will be denied.
Also, if you have specified any of the options
{Allow,Deny}TcpForwardingFor{Users,Groups} or
AllowTcpForwarding, and the forwarding for the user
is disabled with those, an allow directive will not
re-enable the forwarding for the user. Forwarding
is enabled by default.
ForwardAgent
See AllowAgentForwarding.
HostbasedAuthForceClientHostnameDNSMatch
If the hostname given by the client does not match
the one found in DNS, fail host-based authentica-
tion. Defaults to no. Note that this differs from
2.4 and earlier releases.
HostCertificateFile
This keyword works very much like PublicHostKey-
File, except that the file is assumed to contain an
X.509 certificate in binary format. The keyword
must be paired with a corresponding HostKeyFile
option. If multiple certificates with the same
public-key type (DSA or RSA) are specified, only
the first one is used.
HostIdMappingHostnames
A user certificate might contain a HostIdMapping
field. That field is used by SAF to determine the
local username of the user. If the HostIdMapping
field should be processed in Tectia Server, the
HostIdMappingHostnames keyword can be used. It
specifies the list of hostnames that the server
recognizes. If the user certificate has the correct
hostname in the HostIdMapping hostname field, the
username associated with that hostname (specified
in the certificate) is used. Note that if
HostIdMappingHostnames is used, the Tectia cer-
tificate validation must be performed (the AuthPub-
licKey.Cert.ValidationMethods keyword must be set
to saf,tectia).
HostKeyAlgorithms
Specifies the host key signature algorithm to be
used in server authentication and host-based authe-
ntication. The supported algorithms are
ssh-dss,
ssh-dss-sha224@ssh.com,
ssh-dss-sha256@ssh.com,
ssh-dss-sha384@ssh.com,
ssh-dss-sha512@ssh.com,
x509v3-sign-dss,
x509v3-sign-dss-sha224@ssh.com,
x509v3-sign-dss-sha256@ssh.com,
x509v3-sign-dss-sha384@ssh.com,
x509v3-sign-dss-sha512@ssh.com,
ssh-rsa,
ssh-rsa-sha224@ssh.com,
ssh-rsa-sha256@ssh.com,
ssh-rsa-sha384@ssh.com,
ssh-rsa-sha512@ssh.com,
x509v3-sign-rsa,
x509v3-sign-rsa-sha224@ssh.com,
x509v3-sign-rsa-sha256@ssh.com,
x509v3-sign-rsa-sha384@ssh.com, and
x509v3-sign-rsa-sha512@ssh.com.
Multiple HostKeyAlgorithms can be specified as a
comma separated list. Special values for this option
are Any, AnyStd, AnyHostKeyAlgorithm, and AnyStd-
HostKeyAlgorithm. Any allows all HostKeyAlgorithms;
AnyStd allows only those mentioned in the IETF-
SecSh draft; AnyHostKeyAlgorithm and AnyStdHost-
KeyAlgorithm are analogous to the first two cases.
The algorithms mentioned in the IETF-SecSh draft are
x509v3-sign-dss, x509v3-sign-rsa, ssh-dss and ssh-
rsa.
The default list is ssh-rss, ssh-rsa-sha256@ssh.com,
ssh-dss, ssh-dss-sha256@ssh.com, x509v3-sign-dss,
x509v3-sign-dss-sha256@ssh.com, x509v3-sign-rsa and
x509v3-sign-rsa-sha256@ssh.com.
HostKeyFile
Specifies the file containing the private host key
(default /opt/tectia/etc/hostkey). The directory should
be readable only by root.
HostKeyEkInitString
Specifies the initialization string for the exter-
nal host key provider. This is ignored when the
keyword HostKeyEkProvider is not present. The key
specification must define exactly one key. It must
be a personal RSA key that contains both a private
key and a certificate. See ssh-externalkeys(5) for
details about specifying initialization strings.
HostKeyEkProvider
Specifies the external key provider for accessing
the server host key. Currently, the only valid
value on z/OS is zos-saf. See ssh-externalkeys(5)
for details about specifying providers.
HostKey.Cert.Required
This keyword specifies whether the local server
must present a host certificate to the remote
client during server authentication (or whether the
local client must present a host certificate to a
remote server during host-based user authentica-
tion).
If set to yes, a certificate must be defined either
with the HostCertificateFile keyword or with the
HostKeyEkProvider keyword.
If set to no, a certificate is not required. In
this case, if the HostKeyEkProvider keyword speci-
fies a certificate in SAF, only the public key
found in the certificate is used (but HostCertifi-
cateFile is used normally, if defined).
If set to optional, both certificate and public key
are used. In this case, if the HostKeyEkProvider
keyword specifies a certificate in SAF, the cer-
tificate and the public key found in the certifi-
cate are used (but HostCertificateFile is used nor-
mally, if defined).
The argument must be yes, no, or optional. The
default is no.
HostSpecificConfig
Specifies a subconfiguration file for sshd2. The
syntax for this option is
pattern subconfig-file
pattern is used to match the client host, as speci-
fied under option AllowHosts. The file subconfig-
file is read, and configuration data is amended
accordingly. The file is read before any actual
protocol transactions begin, and you can specify
most of the options allowed in the main configura-
tion file. You can specify more than one subconfig-
uration file, in which case the patterns are
matched and the files read in the specified order.
Configuration option values defined later will
either override or amend the previous value,
depending on the option. The effect of redefining
an option is described in the documentation for
each option. For example, setting Ciphers in the
subconfiguration file will override the old value,
but setting AllowUsers will amend the value. See
sshd2_subconfig(5) for more thorough documentation
on what you can set in this subconfiguration file.
See also option UserSpecificConfig.
IdentityDispatchUsers
This keyword is used in conjunction with certifi-
cate authentication. It is followed by a username
pattern as in the AllowUsers keyword. If the login
username given by the client matches to the pat-
tern, it is not used, but instead the username is
taken from the user certificate.
IdleTimeOut
Sets the idle timeout limit to time either in sec-
onds (s or nothing after the number), in minutes
(m), in hours (h), in days (d), or in weeks (w).
If the connection has been idle (all channels) this
long, the connection is closed. Default is 0
(zero), which disables idle timeouts.
IgnoreLoginRestrictions.PasswordExpiration
This option has no effect on z/OS.
IgnoreRhosts
Specifies that the .rhosts and .shosts files will
not be used in hostbased authentication (see
AllowedAuthentications). /etc/hosts.equiv and
/etc/shosts.equiv are still used as before. The
argument must be yes or no. The default is no.
IgnoreRootRhosts
Specifies that the .rhosts and .shosts files will
not be used in authentication for root. The
default is the value of IgnoreRhosts.
KeepAlive
Specifies whether the system should send keepalive
messages to the other side. If they are sent, a
broken connection or crash of one of the machines
will be properly noticed. However, this means that
connections will die if the route is down temporar-
ily, and this can be annoying in some situations.
On the other hand, if keepalive messages are not
sent, sessions may hang indefinitely on the server,
leaving "ghost" users and consuming server
resources.
The default is yes (to send keepalives), and the
server will notice if the network goes down or the
client host reboots. This avoids infinitely hang-
ing sessions.
To disable keepalives, the value should be set to
no in both the server and the client configuration
files.
KEXs
Specifies the key exchange algorithm to be used.
The supported algorithms are
diffie-hellman-group14-sha1,
diffie-hellman-group1-sha1,
diffie-hellman-group14-sha224@ssh.com,
diffie-hellman-group14-sha256@ssh.com,
diffie-hellman-group15-sha256@ssh.com,
diffie-hellman-group15-sha384@ssh.com,
diffie-hellman-group16-sha384@ssh.com,
diffie-hellman-group16-sha512@ssh.com, and
diffie-hellman-group18-sha512@ssh.com.
Multiple KEXs can be specified as a comma-separated
list. Special values for this option are Any,
AnyStd, AnyKEX, and AnyStdKEX. Any allows all KEXs;
AnyStd allows only those mentioned in the IETF-
SecSh draft (diffie-hellman-group14-sha1, diffie-
hellman-goup1-sha1); AnyKEX and AnyStdKEX are ana-
logous to the first two cases.
The default algorithms are diffie-hellman-group14-
sha1, diffie-hellman-group1-sha1 and diffie-hellman
-group14-sha256@ssh.com.
KnownHostsEkProvider
Specifies the external key provider for accessing
external host public keys used for host-based user
authentication. The value is of the format
"provider:initstring". Currently, the only valid
value for provider on z/OS is zos-saf. For the for-
mat of the initstring, see ssh-externalkeys(5).
ListenAddress
Specifies the IP address of the interface where the
sshd2 server socket is bound. The format for this
option is
ip-address [port] ,
where port is optional. This is to allow the option
to be backwards compatible. The port, if not
defined here, will be the value of the last Port
definition (or the default, 22, if Port has not
been defined). If the specified IP address is any,
sshd2 will listen to all interfaces. If sshd2
should listen to only some interfaces, specify the
ListenAddress parameter for each interface. The
default is any.
ListenerRetryInterval
Declares how often sshd2 tries/retries to create
listeners which fail to open initially or later get
deleted by the operating system.
The interval is given either in seconds (s or noth-
ing after the number), in minutes (m), in hours
(h), in days (d), or in weeks (w).
Default is 0 (zero), which means sshd2 does not
retry but gives up and exits immediately when a
listener fails to open or dies.
LoginGraceTime
The server disconnects after this time if the user
has not successfully logged in. If the value is 0,
there is no time limit. The default is 600 (sec-
onds).
MACs
Specifies the MAC (Message Authentication Code)
algorithm to use for data integrity verification.
The supported algorithms are hmac-md5, hmac-md5-96,
hmac-sha1, hmac-sha1-96, hmac-sha256-2@ssh.com,
hmac-sha224@ssh.com, hmac-sha256@ssh.com, hmac-sha-
384@ssh.com and hmac-sha512@ssh.com.
Multiple MACs can be specified as a comma-separated
list. Special values for this option are Any,
AnyStd, none, AnyMac, and AnyStdMac. Any allows
all MACs including none; AnyStd allows only those
mentioned in the IETF-SecSh draft (hmac-md5, hmac-
md5-96, hmac-sha1, hmac-sha1-96) and none; none
means no cryptographic data integrity method is
used; AnyMac and AnyStdMac are analogous to the
first two cases but exclude none.
The default algorithms are hmac-sha1, hmac-sha1-96,
hmac-sha256-2@ssh.com, hmac-sha224@ssh.com,
hmac-sha256@ssh.com, hmac-sha384@ssh.com and
hmac-sha512@ssh.com.
MaxBroadcastsPerSecond
Specifies how many UDP broadcasts the server han-
dles per second. The default value is 0 and no
broadcasts are handled at all. Broadcasts that
exceed the limit are silently ignored. Received
unrecognized UDP datagrams also consume the capac-
ity defined by this option.
MaxConnections
Specifies the maximum number of connections that
sshd2 will handle simultaneously. This is useful
against flooding attacks (attempts to interrupt the
server from working properly by opening a high num-
ber of new connections). The argument is a posi-
tive number (0 means only system limits).
Note that by using (at least) xinetd you achieve
the same effect on a more generic level.
NoDelay
If yes, enables socket option TCP_NODELAY. The
argument must be yes or no. The default is no.
PasswdPath
Specifies the location of the passwd program (or
equivalent). By default this is set to where the
configure script found it. This program will be run
with the privileges of the user logging in.
PasswordGuesses
Specifies the number of tries that the user has
when using password authentication. The default is
3.
PermitEmptyPasswords
When password authentication is allowed, this spec-
ifies whether the server allows login to accounts
with empty password strings. The argument must be
yes or no. The default is yes.
PermitRootLogin
Specifies whether root can log in using ssh2. The
options are yes, nopwd, and no. The default is
yes, allowing root logins through any of the
authentication types allowed for other users. The
nopwd value disables password-authenticated root
logins. The no value disables root logins through
any of the authentication methods. (nopwd and no
are equivalent unless you have some other means of
authentication for root, e.g. public key.)
Root login with public-key authentication when the
command option has been specified will be allowed
regardless of the value of this setting (which may
be useful for taking remote backups even if root
login is normally not allowed).
PidFile
Specifies the file where the process ID of the
server is written. The default is
/opt/tectia/var/run/sshd2_22.pid.
Port Specifies the port number that sshd2 listens to.
The current default is 22.
PrintMotd
Specifies whether sshd2 should print /etc/motd
(message of the day) when a user logs in interac-
tively. The default is yes. The argument must be
yes or no.
ProxyServer
With this option, sshd2 can use a SOCKS (v4 or v5)
or an HTTP proxy when a client forwards a connec-
tion. The server will use the value of this option
when connecting. With SOCKS, you can specify
whether to use SOCKS5 with the option UseSocks5.
The format of the variable is socks://user-
name@socks_server:port/network/netmask,network/net-
mask ... (with SOCKS proxy) or http://user-
name@socks_server:port/network/netmask,network/net-
mask ... (with HTTP proxy).
For instance, by setting ProxyServer to
socks://mylo-
gin@socks.ssh.com:1080/203.123.0.0/16,198.74.23.0/24,
host socks.ssh.com and port 1080 are used as your
SOCKS server for connections outside of networks
203.123.0.0 (16-bit domain) and 198.74.23.0 (8-bit
domain). Those networks are connected directly.
If this option is set, it should almost always con-
tain the local loopback network (127.0.0.0/8) as a
network that is connected directly.
This option and the option SocksServer behave iden-
tically. Specifying both will cause the later defi-
nition to override the first.
PublicHostKeyFile
Specifies the file containing the public host key
(default /opt/tectia/etc/hostkey.pub).
QuietMode
Nothing is logged in the system log, except fatal
errors. The argument must be yes or no. The
default is no.
RandomSeedFile
Specifies the name of the random seed file.
RekeyIntervalSeconds
The number of seconds after which the key exchange
is done again. The default is 3600 seconds (1
hour). The value 0 (zero) turns rekey requests
off. This does not prevent the client from
requesting rekeys. Other clients (not ssh2) may
not have rekey capabilities implemented correctly,
and they might not be able to handle rekey
requests. This means that they may possibly close
the connection or even crash.
RequiredAuthentications
Analogous to AllowedAuthentications, with one dif-
ference: the authentication methods listed here
must all succeed before a user is considered
authenticated. Leaving this list empty is equiva-
lent to not using the option at all.
If this option is set, AllowedAuthentications is
ignored. Note: Versions of sshd2 before 3.1.0
required RequiredAuthentications to be a subset of
AllowedAuthentications. This is no longer the
case.
RequireReverseMapping
This is used to check whether the hostname DNS
lookup must succeed when checking whether connec-
tions from hosts are allowed using AllowHosts and
DenyHosts. If this is set to yes, and the name
lookup fails, the connection is denied. If set to
no, and name lookup fails, the remote host's IP
address is used to check whether it is allowed to
connect. This is probably not what you want if you
have specified only hostnames (not IP addresses)
with {Allow,Deny}Hosts. See also ResolveClien-
tHostName. The argument must be yes or no. The
default is no.
ResolveClientHostName
This parameter controls whether sshd2 will try to
resolve the client IP at all. This is useful when
you know that the DNS cannot be reached, and the
query would cause additional delay in logging in.
Note that if you set this to no, you should not set
RequireReverseMapping to yes. The default is yes.
The argument must be yes or no.
SettableEnvironmentVars
This keyword can be followed by any number of pat-
terns, separated by commas. Patterns are matched
using the egrep syntax (see sshregex(1)), or the
syntax specified in the metaconfiguration header of
the configuration file. You can use the comma ','
character in the patterns by escaping it with a
backslash '\'. By default, no environment vari-
ables can be set (but the default
/opt/tectia/etc/sshd2_config file specifies some common
and safe environment variables).
With this option, you can allow setting some or all
environment variables. This option is used to
check whether setting is allowed by the client
(ssh2), by the user's $HOME/.ssh2/environment file
or public key options. This is not used when set-
ting variables from /etc/environment or other
"root-only" files, as the user does not have con-
trol over those anyway.
Note that this option only changes the settings of
environment variables before the user's shell is
run. After that, the users are of course free to
set whichever variables they want in the environ-
ment.
SftpSysLogFacility
As SysLogFacility, but defines the log facility the
sft-server-g3 subsystem will use. The default is DAEMON.
SftpSmfType
Defines the SMF record type used in SMF accounting
in sshd2 and the sft-server-g3 subsystem. By
default, this has no value, i.e. no accounting is
performed. The possible values are: none, TYPE119.
ShellAccountCodeset
Defines the CCS expected by the shell and shell
applications.
The default is IBM-1047.
ShellConvert
Defines whether conversions are to be done for
shell access and remote command execution.
Possible values are YES and NO.
The default is YES.
ShellTransferCodeset
Defines the coded character set (CCS) on the line.
The default is ISO8859-1.
ShellTranslateTable
Defines the MVS translate table to be used from
line to shell.
SocksServer
Equal to ProxyServer.
StrictModes
Specifies whether sshd2 should check file modes and
ownership of the user's home directory and .rhosts
files before accepting login using host-based
authentication. This is normally desirable because
novices sometimes accidentally leave their direc-
tory or files world-writable, in which case anyone
can edit the .rhosts files.
If this is set, permissions are checked during pub-
lic-key authentication for the user's .ssh2 direc-
tory, public keys used and the authorization file.
Also the hostkey is checked for invalid permis-
sions. The hostkey must only be readable and
writable by the root user, the user public keys and
authorization file must only be writable by the
user. The permission check of the user's .ssh2
directory (and with host-based authentication, the
user's home directory) can be further controlled by
using the StrictModes.UserDirMaskBits configuration
option.
The argument must be yes or no. The default is yes.
StrictModes.UserDirMaskBits
Specifies the permission mask for the user's .ssh2
directory if StrictModes configuration option is
used. The bits set this with option are not allowed
to be set in the actual permissions. This means
that with StrictModes and this option set to "077",
the user's .ssh2 directory may not have any permis-
sions to group or others (only for the user).
Default is "022".
Subsystem-<subsystem name>
Specifies a subsystem. The argument is a command
that is executed when the subsystem is requested.
sftp2 uses a subsystem of sshd2 to transfer files
securely. In order to use the SFTP server, you
must have the following subsystem definition:
subsystem-sftp sft-server-g3
SysLogFacility
Gives the facility code that is used when logging
messages from sshd2. The possible values are: DAE-
MON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3,
LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is
AUTH.
Terminal.AllowUsers
Lists users that are allowed terminal access to the
server host. This option can be followed by any
number of patterns of the form user or user@host,
separated by commas. The details explained under
the AllowHosts option apply accordingly.
If this configuration option is used, only users
that match the users listed under Termi-
nal.AllowUsers may gain terminal access (provided
that they are not restricted by other configuration
options). By default, all users are allowed termi-
nal access.
Note that all the other login authentication steps
must still be successfully completed. Termi-
nal.AllowUsers and Terminal.DenyUsers are addi-
tional restrictions.
Terminal.DenyUsers
Lists users that are denied terminal access to the
server host. This is the opposite of Termi-
nal.AllowUsers and works accordingly.
If a user matches a pattern in both Termi-
nal.AllowUsers and Terminal.DenyUsers then terminal
access is denied.
Note that when terminal access is denied so is
remote command execution, forced commands (includ-
ing commands related to public-key authentication
and forced password changes), X11 forwarding, and
agent forwarding. As a user has no shell access,
any password changes (using system commands) will
not be possible.
Access to subsystems (such as SFTP) and port for-
warding (TCP tunnelling) are still possible.
If a client requests terminal access (in addition
to any other services, such as port forwarding) the
client may disconnect upon being refused terminal
access. To prevent this, the client should be con-
figured to not request terminal access, for exam-
ple, by using the -S option in the ssh command (the
option may vary with the ssh implementation).
Terminal.AllowGroups
Similar to Terminal.AllowUsers but matches groups
rather than usernames. The details explained under
the AllowGroups option apply accordingly.
Terminal.DenyGroups
Similar to Terminal.DenyUsers but matches groups
rather than usernames. This is the opposite of Ter-
minal.AllowGroups and works accordingly.
UseCryptoHardware
Specifies how cryptographic hardware is utilized.
Currently this option has an effect only on IBM
z/OS platforms. The value for this option is a
comma-separated list of algorithm:support_level
pairs. The list may start with a sole support level
specifier.
Valid values for support level are yes, no, and
must. yes means that cryptographic hardware is
used for this algorithm if available and software
cryptography is used if hardware cryptography is
not available.
no means that software cryptography is used for
this algorithm.
must means that only cryptographic hardware is used
for the algorithm.
Valid values for the algorithm part of this option
are 3des, aes, sha, and rng.
3des and aes mean the Triple DES and AES symmetric
ciphers used for encrypting the session. sha means
the SHA-1 or SHA-2 algorithm used for MAC (Message
Authentication Code). rng means random number gene-
rator. The hardware is used to generate entropy for
the random seed at start up and for reseeding the
random number generator algorithm periodically
during execution.
Example: use hardware for 3des and sha, all others
should use software:
UseCryptoHardware no,3des:must,sha:must
This could be coupled with allowing only AES ciphers
and SHA-based MACs with Ciphers and MACs options.
Another example: use crypto hardware for all
algorithms except for AES:
UseCryptoHardware yes,aes:no
UserConfigDirectory
Specifies where user-specific configuration data is
found. With this the administrator can control
those options that are usually controlled by the
user. This is given as a pattern string which is
expanded by sshd2. %D is the user's home direc-
tory, %U is the user's login name, %IU is the
user's user ID (uid), and %IG is user's group ID
(gid). The default is %D/.ssh2.
UserKnownHosts
Specifies whether $HOME/.ssh2/knownhosts/ can be
used to fetch host public keys when using hostbased
authentication. The argument must be yes or no.
The default is yes.
UserSpecificConfig
As HostSpecificConfig, but these configuration
files are read later, when the username that the
client is trying to log in as is known. Also the
range of configuration options available is
smaller, due to the fact that they would not make
sense in these files. You can use patterns of form
"user[%group][@host]", where the pattern user is
matched with the username and UID, group is matched
with the user's primary and any secondary groups,
both group name and GID, and host is matched as
described under option AllowHosts. See sshd2_sub-
config(5) for more thorough documentation on what
you can set in this subconfiguration file.
UseSocks5
Use SOCKS5 instead of SOCKS4 when connecting to
remote host. Note that you have to set SocksServer
to a meaningful value. The argument must be yes or
no. The default is no (i.e. use SOCKS4).
VerboseMode
Causes sshd2 to print debugging messages about its
progress. This is helpful in debugging connection,
authentication, and configuration problems. Also
causes sshd2 to not fork on connection, so only one
connection is handled at the time.
AUTHORS
Tectia Corporation
For more information, see http://www.tectia.com.
SEE ALSO
sshd2(8), sshd2_subconfig(5), sshg3(1), sshd-check-conf(5),
sshregex(1)
2011 Tectia Corporation