 |
|
sshd2_config
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 /etc/ssh2/sshd2_config
(or the file specified with -f on the command line). The
file contains keyword-value pairs, one per line. For a
description of the configuration file format, see
ssh2_config(5). However, configuration blocks are not
allowed in sshd2_config.
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 /var/run/sshd2_22.pid`
or, if the directory /var/run/ does not exist:
# kill -HUP `cat /etc/ssh2/sshd2_22.pid`
The following keywords are allowed:
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 section 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.
Note that sshd2 can also be configured to use TCP
wrappers using the --with-libwrap compile-time
configuration option.
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.
AllowX11Forwarding or X11Forwarding or ForwardX11
Specifies whether X11 forwarding is permitted. The
default is yes. See the security note under option
AllowTcpForwarding. The argument must be yes or
no.
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.
AuthorizationFile
Specifies the name of the user's authorization
file.
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.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 /etc/ssh2/ssh_banner_message
(if defined).
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 3des-cbc,
aes128-cbc, aes192-cbc, aes256-cbc, arcfour, blow-
fish-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; AnyStd
allows only those mentioned in the IETF-SecSh draft
plus none; none forbids any use of encryption; Any-
Cipher and AnyStdCipher are analogous to the first
two cases but exclude none. AnyStdCipher is the
default.
|
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
forwardings, 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.
HostKeyFile
Specifies the file containing the private host key
(default /etc/ssh2/hostkey). The directory should
be readable only by root.
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.
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
Specifies whether the server should ignore the
operating system's password expiration policy. Note
that this only affects the hard password expiration
where the user's login is normally denied until the
password is changed or reactivated by the system
administrator. This feature does not affect the
soft password expiration (password aging) where the
user is requested to change his/her password on
login. The argument must be yes or no. The default
is no.
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.
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.
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@ssh.com, and
hmac-sha256-96@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 and none; none
forbids any use of MACs; AnyMac and AnyStdMac are
analogous to the first two cases but exclude none.
AnyStdMac is the default.
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).
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 argument syntax is described in depth in the
ssh2_config(5) man page. (Note, however, that sshd2
does not use the environment variable
SSH_SOCKS_SERVER, it only uses the configuration
option (and the ./configure time --with-socks-
server option).
PublicHostKeyFile
Specifies the file containing the public host key
(default /etc/ssh2/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
/etc/ssh2/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.
SocksServer
Equal to ProxyServer.
StrictModes
Specifies whether sshd2 should check file modes and
ownership of the user's home directory and authen-
tication. 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 no.
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 (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
Terminal.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, sha1, and rng.
3des and aes mean the Triple DES and AES symmetric
ciphers used for encrypting the session. sha1 means
the SHA-1 algorithm used for MAC (Message Authenti-
cation Code). rng means random number generator.
The hardware is used to generate entropy for the
random seed at start up and for reseeding the ran-
dom number generator algorithm periodically during
execution.
Example: use hardware for 3des and sha1, all others
should use software:
UseCryptoHardware no,3des:must,sha1:must
This could be coupled with allowing only the 3des
cipher and sha1 MAC with Ciphers and MACs options.
Another example: use crypto hardware for all
ciphers except 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.
XauthPath
Specifies where to find the xauth program. This
option is mostly useful if you are using binaries
and your X11 programs are installed in a location
unknown to ssh2. The default is set by the config-
ure script.
AUTHORS
SSH Communications Security Corp.
For more information, see http://www.ssh.com.
SEE ALSO
sshd2(8), sshd2_subconfig(5), ssh2(1), sshd-check-conf(5),
sshregex(1)
|
[Contents]
[Index]
[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]
Copyright © 2006 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice
|
|
|
