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_subconfig

SSHD2_SUBCONFIG(5)             SSH2            SSHD2_SUBCONFIG(5)


NAME
       sshd2_subconfig - advanced configuration of sshd2


DESCRIPTION
       You  can  also  specify configuration options in so-called
       subconfiguration files, which have the same  basic  format
       as the main configuration file. The process forked to han-
       dle the user's connection reads these files. They are read
       at  run-time, so if they are modified, it is not necessary
       to restart the server process.

       If parsing of the subconfiguration files fails,  the  con-
       nection is terminated (for the host-specific subconfigura-
       tion) or access denied (for the user-specific  subconfigu-
       ration) by the server.

       Most  of  the  configuration options that work in the main
       file work also in these, but some do not, where it  either
       does  not  make sense to set them (e.g.  ListenAddress and
       Port, which only affect the daemon  process  listening  to
       the port, and would not affect that behavior in any way in
       a subconfiguration file) or it would  be  confusing  (e.g.
       AllowUsers    in   user-specific   subconfiguration,   and
       AllowHosts in host-specific subconfiguration.).

       The value for {Host,User}SpecificConfig keywords is a pat-
       tern-filename  pair, separated by a whitespace. With User-
       SpecificConfig,    the    pattern     is     of     format
       "user[%group][@host]",  where  the pattern user is matched
       with the user name and UID,  group  is  matched  with  the
       user's  primary  and any secondary groups, both group name
       and GID, and host is matched  as  described  under  option
       AllowHosts.    With  HostSpecificConfig,  the  pattern  is
       "host" (as in UserSpecificConfig).

       Unlike sshd2_config, the subconfiguration files  may  have
       configuration  blocks,  or  stanzas, in them (in ssh2_con-
       fig(5) they are used per-host, but the matching is done as
       a  straight regex match against what was given on the com-
       mand line).  The subconfiguration heading  is  interpreted
       identically  to  what  is described above, i.e. with User-
       SpecificConfig   the   pattern   is    of    the    format
       "user[%group][@host]",  and  with  HostSpecificConfig  the
       format is "host".

       The subconfiguration files  are  divided  into  two  cate-
       gories:  user-specific  and  host-specific.  User-specific
       subconfiguration files are read when the client has stated
       the  username  it is trying to log in with. At this point,
       the server will obtain additional  information  about  the
       user:  does  the  user  exist, what is the user's UID, and
       what groups does the user belong to.  With  this  informa-
       tion,  the server can read the user-specific configuration
       files specified by UserSpecificConfig in  the  main  sshd2
       configuration file.

       The  other  category is host-specific configuration files,
       which are configured with the HostSpecificConfig variable.
       These  files  are  read  immediately  after the daemon has
       forked a new process to handle the connection.  Thus  most
       configuration options can be set in these.

       Note that it is possible to mix these configuration files.
       This is not recommended, because any  global  settings  in
       these  files  would be set multiple times (which would not
       do any harm  per  se,  but  might  lead  to  behavior  not
       intended by the administrator).

       Subconfigurations  are  really  flexible,  and  because of
       that, dangerous if the logic of the files is not carefully
       planned.  You can specify different authentication methods
       for different users, different banner messages for  people
       from certain hosts, and set log messages of certain groups
       to go to different files. There are a lot of possibilities
       here.


OPTIONS
       Configuration  variables that work everywhere, i.e. in the
       main file, the user-specific, and the  host-specific  con-
       figuration files:


              AllowShosts
              AllowTcpForwarding
              AllowedAuthentications
              AuthInteractiveFailureTimeout
              AuthKbdInt.NumOptional
              AuthKbdInt.Optional
              AuthKbdInt.Plugin
              AuthKbdInt.Required
              AuthKbdInt.Retries
              AuthorizationFile
              AuthPublicKey.MaxSize
              AuthPublicKey.MinSize
              Cert.RSA.Compat.HashScheme
              CheckMail
              DenyShosts
              ForwardAgent
              ForwardX11
              HostbasedAuthForceClientHostnameDNSMatch
              IdleTimeout
              IgnoreLoginRestrictions
              IgnoreRhosts
              IgnoreRootRhosts
              PasswdPath
              PasswordGuesses
              PermitEmptyPasswords
              PrintMOTD
              QuietMode
              RekeyIntervalSeconds
              RequiredAuthentications
              SecurIdGuesses
              SettableEnvironmentVars
              SftpSysLogFacility
              StrictModes
              SysLogFacility
              UserConfigDirectory
              UserKnownHosts
              VerboseMode


       Variables  that  work  in  the host-specific configuration
       file and the main file:


              AllowGroups
              AllowTcpForwardingForGroups
              AllowTcpForwardingForUsers
              AllowUsers
              BannerMessageFile
              ChrootGroups
              ChrootUsers
              Ciphers
              DenyGroups
              DenyTcpForwardingForGroups
              DenyTcpForwardingForUsers
              DenyUsers
              DisableVersionFallback
              ExternalAuthorizationProgram
              ForwardACL
              LoginGraceTime
              MACs
              PermitRootLogin
              SSH1Compatibility
              Sshd1ConfigFile
              Sshd1Path


AUTHORS
       SSH Communications Security Corp.

       For more information, see http://www.ssh.com.


SEE ALSO
       sshd2_config(5), sshd2(8), 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