SSHD2_CONFIG(5)

NAME
sshd2_config - format of configuration file for sshd2

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 configuration file, see HostSpecificConfig and UserSpecificConfig. Note that if changes are made in the main configuration file, sshd2 will have to be restarted, for example by sending a signal to it: # kill -HUP `cat /var/run/sshd2_22.pid` or # kill -HUP `cat /etc/ssh2/sshd2_22.pid` if the directory /var/run/ does not exist. The following keywords are allowed:

AllowAgentForwarding or ForwardAgent
    Specifies whether agent forwarding is permitted. This parameter is implemented mainly for completeness. Usually, you should allow users to freely forward agent connections. The argument must be The default is "yes".

AllowedAuthentications
    This keyword specifies the authentication methods that are allowed. Known authentication methods are: keyboard-interactive, password, publickey, pam-1@ssh.com, kerberos-2@ssh.com, kerberos-tgt-2@ssh.com, and securid-1@ssh.com. The default is "publickey, password". pam-1@ssh.com and securid-1@ssh.com are legacy authentication methods, and you should use keyboard-interactive instead, if possible (i.e. the clients that need to be able to connect support keyboard-interactive). See AuthKbdInt.Optional. With RequiredAuthentications, the system administrator can force the users to complete several authentications before they are considered authenticated. 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 metaconfig 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 DenyGroups 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 metaconfig section of the configuration file. If you wish that the pattern will only be matched with the host's IP address (ignoring the canonical host name), 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 host name into a canonical host name. If the name cannot be mapped, the IP address is used as the host name. 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, just 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 that 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)): any user that has a shell can always install her own forwarders. The argument must be The default is "yes".

AllowTcpForwardingForGroups
    The syntax is the same as in AllowGroups, but instead of login, this controls the ability to forward ports in remote or local forwarding. See the security note under option AllowTcpForwarding. The argument must be The default is "yes".

AllowTcpForwardingForUsers
    Syntax is the same as in AllowUsers, but instead of login, this controls the ability to forward ports in remote or local forwarding. See the security note under option AllowTcpForwarding. The argument must be The default is "yes".

AllowUsers
    This option can be followed by any number of patterns 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

AuthInteractiveFailureTimeout
    Specifies the delay, in seconds, that the server delays after a failed attempt to log in using keyboard-interactive 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 AuthKbdInt.Required for required submethods. The default is 0, although if no required submethods are specified, the client must always pass at least one optional submethod.

AuthKbdInt.Optional
    Specifies the optional submethods keyboard-interactive will use. Currently submethods pam, securid, plugin, and password are defined. Note that pam and securid require that you had the necessary libraries and headers when you compiled the distribution. pam submethod is usually available in binary packages, if the architecture supports PAM (Pluggable Authentication Modules). AuthKbdInt.NumOptional specifies how many optional submethods must be passed. The keyboard-interactive authentication method is considered a success when the specified amount of optional submethods and all required submethods are passed. The plugin submethod is special, it can be used if a sysadmin wants to create a new authentication method. See option AuthKbdInt.Plugin. See also AuthKbdInt.NumOptional and AuthKbdInt.Required.

AuthKbdInt.Plugin
    Specify this to point to a program which 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 program does not exist, or cannot be run, the submethod will fail, which may cause the whole authentication for the user to fail. This will not be 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 example 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 authentication method can succeed. See AuthKbdInt.Optional.

AuthKbdInt.Retries
    Specified how many times the user can retry keyboard-interactive. The default is 3.

AuthorizationFile
    Specifies the name of the user's authorization file.

AuthPublicKey.MaxSize
    Specifies the maximum size of a publickey 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 publickey 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 message. The default is /etc/ssh2/ssh_banner_message (if existing).

CheckMail
    Makes sshd2 print information 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 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 environment (e.g. "/home"). This establishes a "jail" that keeps users from sneaking into sensitive areas of 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. Supported values are aes, blowfish, twofish, arcfour, cast, 3des, and des. Multiple ciphers can be specified as a comma-separated 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; AnyCipher 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 with AllowGroups. By default, all users are allowed to log in. If a user's group matches a pattern in both DenyGroups and AllowGroups, login will be denied. Note that all other authentication steps must still be successfully completed. AllowGroups and DenyGroups 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 disallowed 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 forward ports, in remote or local forwarding. See security note under option AllowTcpForwarding. The argument must be Forwarding is enabled by default.

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. The argument must be Forwarding is enabled by default.

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 the all other login authentication steps must still be successfully completed. AllowUsers and DenyUsers are additional restrictions.

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 as a shell-script, for example. If this is set, and the program does not exist, or cannot 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_program_protocol has a description of the protocol used and an example script is called ext_authorization_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 to where. 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. forward-pat is a pattern of format host-id[%port]. This has different interpretations depending on whether the ACL is specified for local or remote forwards. For local forwards, the host-id will match with the target host of the forwarding, as specified under option AllowHosts. port will match with the target port. Also, if the client sent a host name, the IP will be looked up from the DNS, which will be used to match the pattern. For remote forwardings, where the forward target is not known (the client handles that end of the connection), this will be used to match with the listen address specified by the user (and as such is not as usable as with local forwards). port will match the port the server is supposed to be listening with this forward. With local forwards, originator-pat will match with 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 Translation) the originator address will not be meaningful (it will probably be an internal network address). So, you should not rely on the originator address with local forwards, unless you know exactly what you are doing. With remote forwards, 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 that information. If you specify any allow directives, all forwards in that class (local or remote) not specifically allowed will be denied (note that local and remote forwards are separate in this respect; e.g. if you have one "allow remote" definition, local forwards are still allowed, pending other restrictions). If a forward matches with 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 host name given by the client does not match the one found in DNS, fail host-based authentication. Defaults to "no". Note that this differs from 2.4 and earlier releases.

HostKeyEkInitString
    Specifies the initialization string for the external host key provider. This is ignored when the keyword HostKeyEkProvider is not present or when external key support is not included in the software. See ssh-externalkeys(5) for details about specifying initialization strings.

HostKeyEkProvider
    Specifies the external host key provider. This is ignored when external key support is not included in the software. See ssh-externalkeys(5) for details about specifying providers.

HostKeyEkTimeOut
    Specifies the maximum time in seconds to wait for the keys from the external host key provider. This is ignored when external key support is not included in the software.

HostKeyFile
    Specifies the file containing the private host key (default /etc/ssh2/hostkey).

HostSpecificConfig
    Specifies a subconfiguration file for sshd2. The syntax for this option is

    pattern subconfig-file

    pattern will be used to match the client host, as specified under option AllowHosts. The file subconfig-file will then be read, and configuration data amended accordingly. The file is read before any actual protocol transactions begin, and you can specify most of the options allowed in the main configuration file. You can specify more than one subconfiguration file, in which case the patterns are matched and the files read in the order specified. Later defined values of configuration options will either override or amend the previous value depending on which option it is. The effect of redefining an option is described in the documentation for that 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 in seconds (s or nothing after 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.

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 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, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. On the other hand, if keepalives 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 hanging 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.

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 (seconds).

MACs
    Specifies the MAC (Message Authentication Code) algorithm to use for data integrity verification. Currently, hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-ripemd160, and hmac-ripemd160-96 are supported, of which hmac-sha1, hmac-sha1-96, hmac-md5, and hmac-md5-96 are included in all distributions. 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 server handles 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 capacity defined by this option.

MaxConnections
    Specifies the maximum number of connections sshd2 will handle simultaneously. This is useful against flooding attacks (attempts to interrupt the server from working properly by opening a high amount of new connections). The argument is a positive 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", enable socket option TCP_NODELAY. The argument must be 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. Then, shalt thou count to three. No more. No less.

PermitEmptyPasswords
    When password authentication is allowed, it specifies whether the server allows login to accounts with empty password strings. The argument must be The default is "yes".

PermitRootLogin
    Specifies whether root can log in using ssh2. May be set to "yes", "nopwd", or "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 on. The current default is 22.

PrintMotd
    Specifies whether sshd2 should print /etc/motd when a user logs in interactively. The default is "yes". The argument must be

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 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). Value '0' 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 like rekey requests. This means that they may possibly close the connection or even crash.

RequiredAuthentications
    Analogon to AllowedAuthentications, with one differenece: the authentication methods listed here must all succeed before a user is considered authenticated. Leaving this list empty is equivalent 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 hostname DNS lookup must succeed when checking whether connections from host are allowed using AllowHosts and DenyHosts. If this is set to yes, and if 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 host names (not IP addresses) with {Allow,Deny}Hosts. See also ResolveClientHostName. The default is "no". The argument must be

ResolveClientHostName
    This parameter controls whether sshd2 will try to resolve the client ip at all, or not. 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

SettableEnvironmentVars
    This keyword can be followed by any number of patterns, separated by commas. Patterns are matched using the egrep syntax (see sshregex(1)), or the syntax specified in the metaconfig header of the configuration file. You can use the comma ',' character in the patterns by escaping it with the default /etc/ssh2/sshd2_config file specifies some common and safe environment variables). With this option, you can allow setting of 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 setting variables from /etc/environment or other "root-only" files, as the user does not have control over those anyway. Note that this option only changes the setting of environment variables before the user's shell is run. After that, the user is of course free to set whatever variables she wants on that environment.

SftpSysLogFacility
    As SysLogFacility, but defines what log facility the sftp-server (internal or otherwise) will use. By default, this has no value, i.e. no logging is performed by the subsystem.

Ssh1Compatibility
    With this option, sshd1 is executed when the client supports only SSH 1.x protocols. The argument must be

Sshd1ConfigFile
    This is only used if sshd2 is executed with the -f command line option. Specifies alternate config file for sshd1 for the case that sshd2 runs in compatibility mode. (if -f is not specified, sshd1 will read its configuration from the standard location, typically /etc/sshd_config .)

Sshd1Path
    Specifies the path to the sshd1 executable to be executed in SSH1 compatibility mode. The arguments for sshd2 are passed on to sshd1.

StrictModes
    Specifies whether sshd2 should check file modes and ownership of the user's home directory and rhosts files before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The argument must be The default is "yes". (Only done with host-based authentication.)

Subsystem-<subsystem name>
    Specifies a subsystem. The argument is a command which will be executed when the subsystem is requested. sftp 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 sftp-server (the default way, with the defined command) or subsystem-sftp internal://sftp-server which will execute an sftp-service internally in the child process. Normally, the child process would execute a command using the user's shell, but in this case it will start to handle SFTP requests. This enables better logging in chrooted environments, and does not require any static binaries to be build, as the only binary needed will be sshd2 itself.

SyslogFacility
    Gives the facility code that is used when logging messages from sshd2. The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is AUTH.

UserConfigDirectory
    Specifies where user-specific configuration data is found. With this the administration 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 directory, %U is user's login name, %IU is the user's user ID (uid) and %IG is his 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 The default is "yes".

UserSpecificConfig
    As HostSpecificConfig, but these configuration files are read later, when the user name that client is trying to log into 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 user name 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_subconfig(5) for more thorough documentation on what you can set in this subconfiguration file.

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 to somewhere that ssh2 does not know about. The default is set by the configure script.

AUTHORS

SSH Communications Security Corp. For more information, see http://www.ssh.com.

SEE ALSO
sshd2_subconfig(5), sshd2(8), sshd-check-conf(5), sshregex(1)