SSH Tectia  
Previous Next Up [Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Using SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Examples of Use >>
    Man Pages >>
        scp2
        sftp2
        ssh-add2
        ssh-agent2
        ssh-dummy-shell
        ssh-keygen2
        ssh-probe2
        ssh-sft-stage
        ssh2
        ssh2_config
        sshd-check-conf
        sshd2
        sshd2_config
        sshd2_subconfig
        sshregex
    Log Messages >>

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)

Previous Next Up [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