Defining Subconfigurations
Subconfiguration files can be used to specify configuration options that
apply only to connections by specific users or from specific hosts. The
subconfiguration files have the same basic format as the main configuration
file and they are divided into two categories: host-specific and
user-specific.
The process forked to handle the user's connection reads these files. The
process reads the files when in starts up, so if they are modified, it is
not necessary to restart the main server process.
If parsing the subconfiguration files fails, the connection is
terminated (for a host-specific configuration), or the access is denied
by the server (for a user-specific configuration).
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 (for example,
ListenAddress and Port, which only affect the
process listening to the port, and would not affect that behavior in any way in
a subconfiguration file) or if it would be confusing (e.g. AllowUsers
in a user-specific subconfiguration, and AllowHosts in a host-specific
subconfiguration.).
The value for {Host,User}SpecificConfig keywords is a pattern-filename
pair, separated by whitespace. With UserSpecificConfig, the pattern is
of format user[@host], where user is matched with the
username and UID, and host is matched as described under option
AllowHosts. With HostSpecificConfig, the pattern is host (as
in UserSpecificConfig).
Unlike the main configuration file, the subconfiguration files may have configuration
blocks, or stanzas, in them. The subconfiguration heading is interpreted
identically to what is described above, that is with UserSpecificConfig
the pattern is of format user[@host], and with
HostSpecificConfig the format is host.
Note: 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).
Subconfiguration files are very flexible and because of that, dangerous if the
logic of the files is not carefully planned. You can, for example, specify
different authentication methods for different users and different banner
messages for people coming from certain hosts. There are a lot of possibilities
here.
Note: Host-specific subconfiguration files are always read before the
user-specific subconfiguration files.
See the example file sshd2_config.example and the host-specific and
user-specific files in /opt/tectia/etc/subconfig.
