sshd_config - sshd configuration file
/etc/ssh/sshd_config
The sshd(1M) daemon reads configuration data from /etc/ssh/sshd_config (or the file specified with sshd –f on the command line). The file contains keyword-value pairs, one per line. A line starting with a hash mark (#) and empty lines are interpreted as comments.
The sshd_config file supports the following keywords. Unless otherwise noted, keywords and their arguments are case-insensitive.
This keyword can be followed by a number of group names, separated by spaces. If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. Asterisk (*) and question mark (?) can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed regardless of the primary group.
Specifies whether TCP forwarding is permitted. The default is yes. Disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.
This keyword can be followed by a number of user names, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. Asterisk (*) and question mark (?) can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default login is allowed regardless of the user name.
If a specified pattern takes the form user@ host then user and host are checked separately, restricting logins to particular users from particular hosts.
Specifies the file that contains the public keys that can be used for user authentication. AuthorizedKeysFile can contain tokens of the form %T, which are substituted during connection set-up. The following tokens are defined: %% is replaced by a literal %, %h is replaced by the home directory of the user being authenticated and %u is replaced by the username of that user. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. The default is .ssh/authorized_keys.
In some jurisdictions, sending a warning message before authentication can be relevant for getting legal protection. The contents of the specified file are sent to the remote user before authentication is allowed. This option is only available for protocol version 2. By default, no banner is displayed.
Specifies a path to chroot(2) to after authentication. This path, and all its components, must be root-owned directories that are not writable by any other user or group.
The server always tries to change to the user's home directory locally under the chrooted environment but a failure to do so is not considered an error. In addition, the path might contain the following tokens that are expanded at runtime once the connecting user has been authenticated: %% is replaced by a literal %, %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user.
The ChrootDirectory must contain the necessary files and directories to support the user's session. For an interactive SSH session this requires at least a user's shell, shared libraries needed by the shell, dynamic linker, and possibly basic /dev nodes such as null, zero, stdin, stdout, stderr, random, and tty. Additionally, terminal databases are needed for screen oriented applications. For file transfer sessions using sftp with the SSH protocol version 2, no additional configuration of the environment is necessary if the in-process sftp server is used. See Subsystem for details.
The default is not to chroot(2).
Specifies the ciphers allowed for protocol version 2. Cipher ordering on the server side is not relevant. Multiple ciphers must be comma separated.
Valid ciphers are: aes128-ctr, aes192-ctr, aes256-ctr, aes128-cbc, aes192-cbc, aes256-cbc, arcfour, arcfour128, arcfour256, 3des-cbc, and blowfish-cbc.
The default cipher list is:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour128, arcfour256,arcfour
Using CBC modes on the server side is not recommended due to potential security issues in connection with the SSH protocol version 2.
When configuring sshd to run OpenSSL in FIPS-140 mode, the default cipher list is: aes128-cbc, aes192-cbc, aes256-cbc. Specifying a non-FIPS approved cipher will return an error.
For the case of ssh with FIPS-140 enabled logging into a non-FIPS-140 sshd, the supported and approved FIPS ciphers must be explicitly specified in sshd_config using “Ciphers” for this scenario.
Sets the number of client alive messages, (see ClientAliveInterval ), that can be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd disconnects the client, terminating the session. The use of client alive messages is very different from KeepAlive. The client alive messages are sent through the encrypted channel and therefore are not spoofable. The TCP keepalive option enabled by KeepAlive is spoofable. The client alive mechanism is valuable when a client or server depend on knowing when a connection has become inactive.
The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive ssh clients are disconnected after approximately 45 seconds.
Sets a timeout interval in seconds after which, if no data has been received from the client, sshd sends a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages are not sent to the client. This option applies only to protocol version 2.
Specifies whether compression is allowed or delayed, until the user has authenticated successfully. The argument must be yes, delayed, or no. The default is yes.
Can be followed by a number of group names, separated by spaces. Users whose primary or supplementary group matches one of the patterns are not allowed to log in. Asterisk (*) and question mark (?) can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed regardless of the primary group.
Can be followed by a number of user names, separated by spaces. Login is disallowed for user names that match one of the patterns. Asterisk (*) and question mark (?) can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed regardless of the user name.
If a specified pattern takes the form user @host then user and host are checked separately, disallowing logins to particular users from particular hosts.
Forces the execution of the command specified by ForceCommand, ignoring any command supplied by the client, and, if present, ~/.ssh/rc. The command is invoked by using the user's login shell with the –c option. This applies to shell, command, or subsystem execution. It is most useful inside a Match block. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Specifying a command of internal-sftp forces the use of an in-process sftp server that requires no support files when used with ChrootDirectory.
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd binds remote port forwarding to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should bind remote port forwarding to the wildcard address, thus allowing remote hosts to connect to forwarded ports.
The argument can be no to force remote port forwarding to be available to the local host only, yes to force remote port forwardings to bind to the wildcard address, or clientspecified to allow the client to select the address to which the forwarding is bound. The default is no. See also RemoteForward in ssh_config(4).
Enables/disables GSS-API user authentication. The default is yes.
Currently sshd authorizes client user principals to user accounts as follows: if the principal name matches the requested user account, then the principal is authorized. Otherwise, GSS-API authentication fails.
Enables/disables GSS-API-authenticated key exchanges. The default is yes.
This option also enables the use of the GSS-API to authenticate the user to server after the key exchange. GSS-API key exchange can succeed but the subsequent authentication using the GSS-API fail if the server does not authorize the user's GSS principal name to the target user account.
Currently sshd authorizes client user principals to user accounts as follows: if the principal name matches the requested user account, then the principal is authorized. Otherwise, GSS-API authentication fails.
Enables/disables the use of delegated GSS-API credentials on the server-side. The default is yes.
Specifically, this option, when enabled, causes the server to store delegated GSS-API credentials in the user's default GSS-API credential store (which for the Kerberos V mechanism means /tmp/krb5cc_ <uid>).
sshd does not take any steps to explicitly destroy stored delegated GSS-API credentials upon logout. It is the responsibility of PAM modules to destroy credentials associated with a session.
Specifies whether to try rhosts-based authentication with public key authentication. The argument must be yes or no. The default is no. This option applies to protocol version 2 only and is similar to RhostsRSAAuthentication. See sshd(1M) for guidelines on setting up host-based authentication.
Specifies the host key algorithms that the server offers. The default for this option is: ssh-rsa,ssh-dss.
Specifies the key types that will be accepted for host based authentication as a comma-separated pattern list. Alternately if the specified value begins with a `+' character, then the specified key types will be appended to the default set instead of replacing them. The default for this option is: ssh-rsa,ssh-dss.
Controls which hostname is searched for in the files ~/.shosts, /etc/shosts.equiv, and /etc/hosts.equiv. If this parameter is set to yes, the server uses the name the client claimed for itself and signed with that host's key. If set to no, the default, the server uses the name to which the client's IP address resolves.
Setting this parameter to no disables host-based authentication when using NAT or when the client gets to the server indirectly through a port-forwarding firewall.
Specifies the file containing the private host key used by SSH. The default is /etc/ssh/ssh_host_rsa_key and/etc/ssh/ssh_host_dsa_key for protocol version 2. sshd refuses to use a file if it is group/world-accessible. It is possible to have multiple host key files. dsa or rsa keys are used for version 2 of the SSH protocol.
Specifies that .rhosts and .shosts files are not used in authentication. /etc/hosts.equiv and /etc/shosts.equiv are still used. The default is yes.
Specifies whether sshd should ignore the user's $HOME/.ssh/known_hosts during RhostsRSAAuthentication . The default is no.
Specifies whether authentication by means of the keyboard-interactive authentication method is allowed. Defaults to yes
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 is properly noticed. However, this means that connections die if the route is down temporarily, which can be an annoyance. On the other hand, if keepalives are not sent, sessions can hang indefinitely on the server, leaving ghost users and consuming server resources.
The default is yes (to send keepalives), and the server notices 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.
Specifies the available KEX (Key Exchange) algorithms. Multiple algorithms must be comma-separated. Alternately if the specified value begins with a `+' character, then the specified methods will be appended to the default set instead of replacing them. The supported and default algorithms are:
diffie-hellman-group-exchange-sha256 diffie-hellman-group-exchange-sha1 diffie-hellman-group14-sha1 diffie-hellman-group1-sha1
A filename for the KMF policy database. If not set, KMF defaults to /etc/security/kmfpolicy.xml. See the Using X.509 Certificates section in the sshd(1M) man page.
A name of the KMF policy to be used. If not set, default is used. See the Using X.509 Certificates section in the sshd(1M) man page.
Specifies what local address sshd should listen on. The following forms can be used:
ListenAddress host| IPv4_addr|IPv6_addr ListenAddress host|IPv4_addr: port ListenAddress [host|IPv6_addr]: port
If port is not specified, sshd listens on the address and all prior Port options specified. The default is to listen on all local addresses. Multiple ListenAddress options are permitted. Additionally, any Port options must precede this option for non-port qualified addresses.
The default is to listen on all local addresses. Multiple options of this type are permitted. Additionally, the Ports options must precede this option.
The server disconnects after this time (in seconds) if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 120 (seconds).
Gives the verbosity level that is used when logging messages from sshd. The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG2 and DEBUG3 each specify higher levels of debugging output. Logging with level DEBUG violates the privacy of users and is not recommended.
Specifies whether or not to reverse lookup the names of client's addresses. Setting this parameter to no can be useful where name resolution might be broken and thus cause sshd to spend a lot of time trying to resolve the client's IP address to a name. Defaults to yes. See VerifyReverseMapping.
It is an error to set up a Match Block with Host matching and also set LookupClientHostnames to no in sshd_config.
If there is a Match Block with Host matching, then even if LookupClientHostnames is set to no, LookupClientHostnames will be re-enabled, so that the security requirements of the match block are honored. In such a case, sshd issues an error message to the console, and will also syslog an ERROR if someone logs in while the misconfiguration remains in the sshd_config file.
Specifies the available MAC (message authentication code) algorithms. The MAC algorithm is used in protocol version 2 for data integrity protection. Multiple algorithms must be comma-separated. The default is hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96, hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512, and hmac-sha2-512-96.
When configuring sshd to run OpenSSL in FIPS-140 mode, the default is hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512 , and hmac-sha2-512-96. Specifying a non-FIPS approved MAC algorithm will return an error.
Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. Match blocks must be located at the end of the file, after all the global settings.
The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, and Address. The match patterns can consist of single entries or comma-separated lists and can use the wildcard (Asterisk * and question mark ?) and negation (!) operators.
The patterns in a Host criteria should be hostname. The patterns in an Address criteria should be an IP address, which can additionally contain addresses to match in CIDR address/masklen format, for example, 192.0.2.0/24 or 2001:DB8::/32. The mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, 192.0.2.0/33 and 192.0.2.0/8 respectively.
Only a subset of keywords can be used on the lines following a Match keyword. Available keywords are AllowTcpForwarding, AuthorizedKeysFile, Banner, ChrootDirectory, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, HostbasedAcceptedKeyTypes, KbdInteractiveAuthentication, MaxAuthTries, PasswordAuthentication, PermitEmptyPasswords, PermitRootLogin, PubkeyAcceptedKeyTypes, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding, and X11UseLocalhost.
The following are four examples of using Match:
Disallowing user testuser to use TCP forwarding
Match User testuser AllowTcpForwarding no
Displaying a special banner for users not in the staff group
Match Group *,!staff Banner /etc/banner.text
Allowing root login from host rootallowed.example.com
Match Host rootallowed.example.com PermitRootLogin yes
Allowing anyone to use GatewayPorts from the local net
Match Address 192.168.0.0/24 GatewayPorts yes
Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default value is 6.
Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon. Additional connections are dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10:30:100.
Alternatively, random early drop can be enabled by specifying the three colon-separated values start:rate:full (for example, 10:30:60). Referring to this example, sshd refuse connection attempts with a probability of rate/100 (30% in our example) if there are currently 10 (from the start field) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches full (60 in our example).
The default is 10:30:100.
Specifies the PAM service name for the PAM session. The PAMServiceName and PAMServicePrefix options are mutually exclusive and if both set, sshd does not start. If this option is set the service name is the same for all user authentication methods. The option has no default value. See PAMServicePrefix for more information.
Specifies the PAM service name prefix for service names used for individual user authentication methods. The default is sshd. The PAMServiceName and PAMServicePrefix options are mutually exclusive and if both set, sshd does not start.
For example, if this option is set to admincli, the service name for the keyboard-interactive authentication method is admincli-kbdint instead of the default sshd-kbdint .
Specifies whether password authentication is allowed. The default is yes.
When password or keyboard-interactive authentication is allowed, it specifies whether the server allows login to accounts with empty password strings.
If not set then the /etc/default/login PASSREQ value is used instead.
PASSREQ=no is equivalent to PermitEmptyPasswords yes. PASSREQ=yes is equivalent to PermitEmptyPasswords no. If neither PermitEmptyPasswords or PASSREQ are set the default is no.
Specifies whether the root can log in using ssh(1). The argument must be yes, without-password, forced-commands-only, or no. without-password means that root cannot be authenticated using the “password” or “keyboard-interactive” methods (see description of KbdInteractiveAuthentication). forced-commands-only means that authentication is allowed only for publickey (for SSHv2, or RSA, for SSHv1) and only if the matching authorized_keys entry for root has a command=<cmd> option.
In Solaris, the default /etc/ssh/sshd_config file is shipped with PermitRootLogin set to no. If unset by the administrator, then CONSOLE parameter from /etc/default/login supplies the default value as follows: if the CONSOLE parameter is not commented out (it can even be empty, that is, “CONSOLE=”), then without-password is used as default value. If CONSOLE is commented out, then the default for PermitRootLogin is yes.
The without-password and forced-commands-only settings are useful for, for example, performing remote administration and backups using trusted public keys for authentication of the remote client, without allowing access to the root account using passwords.
Specifies whether a user's ~/.ssh/environment on the server side and environment options in the AuthorizedKeysFile file are processed by sshd. The default is no. Enabling environment processing can enable users to bypass access restrictions in some configurations using mechanisms such as LD_PRELOAD.
Environment setting from a relevant entry in AuthorizedKeysFile file is processed only if the user was authenticated using the public key authentication method. Of the two files used, values of variables set in ~/.ssh/environment are of higher priority.
Allows you to specify an alternative to /var/run/sshd.pid, the default file for storing the PID of the sshd listening for connections. See sshd(1M).
Specifies the port number that sshd listens on. The default is 22. Multiple options of this type are permitted. See also ListenAddress.
Specifies an executable which is run prior to any of the processed authentication methods. The executable can be used to synchronize user information with a remote user-management facility using an arbitrary communication protocol.
The executable is run before any user validation is conducted by SSHD so the user is not required to be existent before she tries to log in.
The executable is invoked with two arguments in the following order: the name of the current authentication method and the username. The environment variable SSH_CONNECTION is also passed to the executable. If the executable returns a zero exit status, the current authentication method is processed as normal. See sshd(1M).
If the exit status is 1, the current authentication method is ignored and can not be used to validate the user. The executable must be owned by root and have permissions of 0500, otherwise it is treated as if it has exited with status 1.
There is no default value for this property.
Specifies whether sshd should display the date and time when the user last logged in. On Solaris this option is always ignored since pam_unix_session(5) reports the last login time.
Specifies whether sshd should display the contents of /etc/motd when a user logs in interactively. (On some systems it is also displayed by the shell or a shell startup file, such as /etc/profile.) The default is yes.
Specifies the protocol versions sshd should support in order of preference. The option is left for backwards compatibility and only value 2 is supported. The default is 2.
Specifies whether public key authentication is allowed. The default is yes. This option applies to protocol version 2 only.
Specifies the key types that will be accepted for public key authentication as a comma-separated pattern list. Alternately if the specified value begins with a `+' character, then the specified key types will be appended to the default set instead of replacing them. The default for this option is: ssh-rsa, ssh-dss.
Specifies whether sshd should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is yes.
Configures an external subsystem (for example, a file transfer daemon). Arguments should be a subsystem name and a command to execute upon subsystem request. The command sftp-server(1M) implements the sftp file transfer subsystem.
Alternately, the name internal-sftp implements an in-process sftp server. This can simplify configurations using ChrootDirectory to force a different filesystem root on clients.
To specify an option to the internal sftp server, simply add the sftp-server option to the end of line. For example,
#sftp subsystem Subsystem sftp internal-sftp -u 002
By default, no subsystems are defined. This option applies to protocol version 2 only.
Specifies a directory where certificates of trusted anchors are located. Those certificates are used to validate host certificates if used as host keys.
Currently only one level certificate chains are supported. This means that certificates must be signed by a private key that corresponds to a certificate located in the directory set by this option. Host key certificates can be self-signed as well. See the Using X.509 Certificates section in the sshd(1M) man page.
Gives the facility code that is used when logging messages from sshd. The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, and LOCAL7. The default is AUTH.
Specifies whether sshd will run OpenSSL in FIPS-140 mode. The default is no. A yes setting will allow sshd to use the FIPS capable crypto modules in OpenSSL.
Specifies whether sshd should use the OpenSSL PKCS#11 engine to offload cryptographic operations to the Cryptographic Framework. Cryptographic operations are accelerated based on the installed plug-ins. If there is no suitable plug-in present, this option does not have any effect.
The OpenSSL PKCS#11 engine is not enabled by default, and it depends on the hardware platform. It is not enabled for T4, newer SPARC CPUs, and the x86 platform because the latest OpenSSL has hardware support implemented internally.
Specifies whether sshd should try to verify the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address.
A yes setting means verify. This feature is useful for Internet-facing servers. The default is no.
The option is only usable if LookupClientHostnames is set to yes.
Specifies the first display number available for sshd's X11 forwarding. This prevents sshd from interfering with real X11 servers. The default is 10.
Specifies whether X11 forwarding is permitted. The default is yes. Disabling X11 forwarding does not improve security in any way, as users can always install their own forwarders.
When X11 forwarding is enabled, there can be additional exposure to the server and to client displays if the sshd proxy display is configured to listen on the wildcard address (see X11UseLocalhost). However, this is not the default. Additionally, the authentication spoofing and authentication data verification and substitution occur on the client side. The security risk of using X11 forwarding is that the client's X11 display server can be exposed to attack when the ssh client requests forwarding (see the warnings for ForwardX11 in ssh_config(4)). A system administrator who wants to protect clients that expose themselves to attack by unwittingly requesting X11 forwarding, should specify a no setting.
Disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders.
Specifies whether sshd should bind the X11 forwarding server to the loopback address or to the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. However, some older X11 clients might not function with this configuration. X11UseLocalhost can be set to no to specify that the forwarding server should be bound to the wildcard address. The argument must be yes or no. The default is yes.
Specifies the location of the xauth (1) program. The default is /usr/X11/bin/xauth and sshd attempts to open it when X11 forwarding is enabled.
sshd command-line arguments and configuration file options that specify time can be expressed using a sequence of the form: time[qualifier,] where time is a positive integer value and qualifier is one of the following:
seconds
seconds
minutes
hours
days
weeks
Each element of the sequence is added together to calculate the total time value. For example:
600 seconds (10 minutes)
10 minutes
1 hour, 30 minutes (90 minutes)
Contains configuration data for sshd. This file should be writable by root only, but it is recommended (though not necessary) that it be world-readable.
See attributes(5) for descriptions of the following attributes:
|
login(1), sshd(1M), chroot(2), ssh_config(4), attributes(5), kerberos(5), pam_unix_session(5)
OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt, and Dug Song removed many bugs, re-added recent features, and created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0. Niels Provos and Markus Friedl contributed support for privilege separation.