sshd_config man page on SunOS

Man page or keyword search:  
man Server   20652 pages
apropos Keyword Search (all sections)
Output format
SunOS logo
[printable version]

sshd_config(4)			 File Formats			sshd_config(4)

NAME
       sshd_config - sshd configuration file

SYNOPSIS
       /etc/ssh/sshd_config

DESCRIPTION
       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 con‐
       tains  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 keywords listed below. Unless	other‐
       wise noted, keywords and their arguments are case-insensitive.

       AllowGroups

	   This	 keyword can be followed by a number of group names, separated
	   by spaces. If specified, login is allowed only for users whose pri‐
	   mary 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.

       AllowTcpForwarding

	   Specifies  whether TCP forwarding is permitted. The default is yes.
	   Note that disabling TCP forwarding does not improve security unless
	   users  are  also  denied  shell  access, as they can always install
	   their own forwarders.

       AllowUsers

	   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.

       AuthorizedKeysFile

	   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.

       Banner

	   In some jurisdictions, sending a warning message before authentica‐
	   tion	 can be relevant for getting legal protection. The contents of
	   the specified file are sent to the remote user  before  authentica‐
	   tion is allowed. This option is only available for protocol version
	   2. By default, no banner is displayed.

       ChrootDirectory

	   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  directo‐
	   ries	 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).

       Ciphers

	   Specifies the ciphers allowed  for  protocol	 version  2.  Multiple
	   ciphers must be comma-separated. The default is:

	     aes128-ctr, aes128-cbc, arcfour, 3des-cbc, blowfish-cbc,
	     aes192-ctr, aes192-cbc, aes256-ctr, aes256-cbc

       ClientAliveCountMax

	   Sets	 the number of client alive messages (see ClientAliveInterval,
	   below) 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.  It is important to note that the use of client alive
	   messages is very different from KeepAlive (see below).  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 (below)  is  set  to
	   15,	and  ClientAliveCountMax  is left at the default, unresponsive
	   ssh clients are disconnected after approximately 45 seconds.

       ClientAliveInterval

	   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.

       Compression

	   Controls whether the server allows the client to negotiate the  use
	   of compression. The default is yes.

       DenyGroups

	   Can	be  followed  by a number of group names, separated by spaces.
	   Users whose primary or supplementary group matches one of the  pat‐
	   terns 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.

       DenyUsers

	   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.

       GatewayPorts

	   Specifies whether remote hosts are allowed to connect to ports for‐
	   warded for the client. By default, sshd binds remote port  forward‐
	   ings 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  forwardings to the wildcard
	   address, thus allowing remote hosts to connect to forwarded	ports.
	   The argument must be yes or no. The default is no.

       GSSAPIAuthentication

	   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.

       GSSAPIKeyExchange

	   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.  Note  that  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	 prin‐
	   cipal 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.

       GSSAPIStoreDelegatedCredentials

	   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 creden‐
	   tial	  store	  (which   for	 the   Kerberos	  V   mechanism	 means
	   /tmp/krb5cc_<uid>).

	   Note -

	     sshd does not take any steps to explicitly destroy	 stored	 dele‐
	     gated  GSS-API  credentials upon logout. It is the responsibility
	     of PAM modules to destroy credentials associated with a session.

       HostbasedAuthentication

	   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.

       HostbasedUsesNameFromPacketOnly

	   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.

       HostKey

	   Specifies the file containing the private host key used by SSH. The
	   default  is	/etc/ssh/ssh_host_key  for  protocol  version  1,  and
	   /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for	proto‐
	   col	version	 2.  Note  that	 sshd  refuses	to use a file if it is
	   group/world-accessible. It is possible to have  multiple  host  key
	   files. rsa1 keys are used for version 1 and dsa or rsa are used for
	   version 2 of the SSH protocol.

       IgnoreRhosts

	   Specifies that .rhosts and .shosts files are not used in  authenti‐
	   cation.  /etc/hosts.equiv and /etc/shosts.equiv are still used. The
	   default is yes. This parameter applies to both protocol versions  1
	   and 2.

       IgnoreUserKnownHosts

	   Specifies	 whether     sshd    should    ignore	 the	user's
	   $HOME/.ssh/known_hosts during RhostsRSAAuthentication. The  default
	   is no. This parameter applies to both protocol versions 1 and 2.

       KbdInteractiveAuthentication

	   Specifies whether authentication by means of the "keyboard-interac‐
	   tive" authentication method (and PAM) is allowed. Defaults to  yes.
	   (Deprecated: this parameter can only be set to yes.)

       KeepAlive

	   Specifies  whether the system should send keepalive messages by way
	   of the socket 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  tem‐
	   porarily,  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  in‐
	   finitely hanging sessions.

	   To  disable	keepalives,  the value should be set to no in both the
	   server and the client configuration files.

	   KeepAlive is a meaningless option on the server side	 when  the  -i
	   command-line option is in use.

       KeyRegenerationInterval

	   In  protocol	 version  1, the ephemeral server key is automatically
	   regenerated after this many seconds (if it has been used). The pur‐
	   pose	 of regeneration is to prevent decrypting captured sessions by
	   later breaking into the machine and stealing the keys. The  key  is
	   never stored anywhere. If the value is 0, the key is never regener‐
	   ated. The default is 3600 (seconds).

       ListenAddress

	   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. Addition‐
	   ally, any Port options must precede this option for non-port quali‐
	   fied 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.

       LoginGraceTime

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

       LogLevel

	   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.

       LookupClientHostnames

	   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.

       MACs

	   Specifies  the  available  MAC  (message authentication code) algo‐
	   rithms. 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.

       MaxStartups

	   Specifies the maximum number of concurrent unauthenticated  connec‐
	   tions  to the sshd daemon. Additional connections are dropped until
	   authentication succeeds or the LoginGraceTime expires for a connec‐
	   tion. The default is 10.

	   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 con‐
	   nections. The probabillity increases linearly  and  all  connection
	   attempts  are  refused if the number of unauthenticated connections
	   reaches full (60 in our example).

       PasswordAuthentication

	   Specifies whether password authentication is allowed.  The  default
	   is  yes.  Note that this option applies to both protocol versions 1
	   and 2.

       PermitEmptyPasswords

	   When password authentication is allowed, it specifies  whether  the
	   server  allows  login  to  accounts with empty password strings. In
	   /etc/default/login, if PASSREQ is not set, or PASSREQ=YES, then the
	   default is no; if PASSREQ=NO, then the default is yes.

       PermitRootLogin

	   Specifies  whether  the  root can log in using ssh(1). The argument
	   must be yes, without-password, forced-commands-only, or  no.	 with‐
	   out-password	 means	that  root  cannot  be authenticated using the
	   "password" or "keyboard-interactive" methods	 (see  description  of
	   KbdInteractiveAuthentication	  above).  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 CON‐
	   SOLE 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.

       PermitUserEnvironment

	   Specifies  whether  a  user's ~/.ssh/environment on the server side
	   and environment options in the  AuthorizedKeysFile  file  are  pro‐
	   cessed  by sshd. The default is no. Enabling environment processing
	   can enable users to bypass access restrictions in  some  configura‐
	   tions 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 pub‐
	   lic	key  authentication  method.  Of the two files used, values of
	   variables set in ~/.ssh/environment are of higher priority.

       PidFile

	   Allows you to specify  an  alternative  to  /var/run/sshd.pid,  the
	   default  file for storing the PID of the sshd listening for connec‐
	   tions. See sshd(1M).

       Port

	   Specifies the port number that sshd listens on. The default is  22.
	   Multiple  options  of  this	type are permitted. See also ListenAd‐
	   dress.

       PrintLastLog

	   Specifies whether sshd should display the date and  time  when  the
	   user last logged in. The default is yes.

       PrintMotd

	   Specifies  whether  sshd  should  display the contents of /etc/motd
	   when a user logs in interactively. (On some systems it is also dis‐
	   played by the shell or a shell startup file, such as /etc/profile.)
	   The default is yes.

       Protocol

	   Specifies the protocol versions sshd should	support	 in  order  of
	   preference. The possible values are 1 and 2. Multiple versions must
	   be comma-separated. The default is 2,1. This means that  ssh	 tries
	   version  2  and  falls back to version 1 if version 2 is not avail‐
	   able.

       PubkeyAuthentication

	   Specifies whether public key authentication is allowed. The default
	   is yes. Note that this option applies to protocol version 2 only.

       RhostsAuthentication

	   Specifies  whether  authentication using rhosts or /etc/hosts.equiv
	   files is sufficient. Normally, this method should not be  permitted
	   because  it	is  insecure.  RhostsRSAAuthentication	should be used
	   instead, because it performs RSA-based host authentication in addi‐
	   tion	 to  normal  rhosts  or	 /etc/hosts.equiv  authentication. The
	   default is no. Note that this parameter applies  only  to  protocol
	   version 1.

       RhostsRSAAuthentication

	   Specifies   whether	 rhosts	  or  /etc/hosts.equiv	authentication
	   together with successful RSA host authentication  is	 allowed.  The
	   default  is	no.  Note that this parameter applies only to protocol
	   version 1.

       RSAAuthentication

	   Specifies whether pure RSA authentication is allowed.  The  default
	   is yes. Note that this option applies to protocol version 1 only.

       ServerKeyBits

	   Defines  the	 number	 of  bits  in the ephemeral protocol version 1
	   server key. The minimum value is 512, and the default is 768.

       StrictModes

	   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.

       Subsystem

	   Configures an external subsystem (for example, a file transfer dae‐
	   mon). 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.

	   By default, no subsystems are defined. This option applies to  pro‐
	   tocol version 2 only.

       SyslogFacility

	   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.

       UseOpenSSLEngine

	   Specifies whether sshd should use the OpenSSL  PKCS#11  engine  for
	   offloading cryptographic operations to the Cryptographic Framework.
	   Cryptographic operations are accelerated according to the available
	   installed  plug-ins.	 When  no  suitable  plug-ins are present this
	   option does not have an effect. The default is yes.

       VerifyReverseMapping

	   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.

       X11DisplayOffset

	   Specifies  the  first  display number available for sshd's X11 for‐
	   warding. This prevents sshd from interfering with real X11 servers.
	   The default is 10.

       X11Forwarding

	   Specifies  whether X11 forwarding is permitted. The default is yes.
	   Note that 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 con‐
	   figured  to	listen	on  the	 wildcard address (see X11UseLocalhost
	   below). However, this is not the default. Additionally, the authen‐
	   tication  spoofing and authentication data verification and substi‐
	   tution 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.

       X11UseLocalhost

	   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.  How‐
	   ever,  some older X11 clients might not function with this configu‐
	   ration. X11UseLocalhost can be set to no to specify that  the  for‐
	   warding  server  should be bound to the wildcard address. The argu‐
	   ment must be yes or no. The default is yes.

       XAuthLocation

	   Specifies the location of the  xauth(1)  program.  The  default  is
	   /usr/openwin/bin/xauth  and	sshd attempts to open it when X11 for‐
	   warding is enabled.

   Time Formats
       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 fol‐
       lowing:

       <none>	 seconds

       s | S	 seconds

       m | M	 minutes

       h | H	 hours

       d | D	 days

       w |	 weeks

       Each  element  of the sequence is added together to calculate the total
       time value. For example:

       600	600 seconds (10 minutes)

       10m	10 minutes

       1h30m	1 hour, 30 minutes (90 minutes)

FILES
       /etc/ssh/sshd_config    Contains configuration data for sshd. This file
			       should be writable by root only, but it is rec‐
			       ommended (though	 not  necessary)  that	it  be
			       world-readable.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:

       ┌─────────────────────────────┬─────────────────────────────┐
       │      ATTRIBUTE TYPE	     │	    ATTRIBUTE VALUE	   │
       ├─────────────────────────────┼─────────────────────────────┤
       │Availability		     │SUNWsshu			   │
       ├─────────────────────────────┼─────────────────────────────┤
       │Interface Stability	     │Committed			   │
       └─────────────────────────────┴─────────────────────────────┘

SEE ALSO
       login(1), sshd(1M), ssh_config(4), attributes(5), kerberos(5)

AUTHORS
       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 fea‐
       tures, and created OpenSSH. Markus Friedl contributed the  support  for
       SSH  protocol versions 1.5 and 2.0. Niels Provos and Markus Friedl con‐
       tributed support for privilege separation.

SunOS 5.10			  9 Jan 2011			sshd_config(4)
[top]

List of man pages available for SunOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net