Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Getting Started with SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
        Server Configuration Files >>
        Defining Subconfigurations
            Host-Specific Subconfiguration
            User-Specific Subconfiguration
        Configuring Ciphers and MACs >>
        Configuring Root Logins
        Restricting User Logins
        Configuring Code Pages
        Defining Subsystems
        Auditing >>
        Securing the Server >>
    Authentication >>
    System Administration >>
    File Transfer Using SFTP >>
    Secure File Transfer Using Transparent FTP Security >>
    Tunneling >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Man Pages and Default Configuration Files >>
    Log Messages >>

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.

Host-Specific Subconfiguration

User-Specific Subconfiguration

PreviousNextUp[Contents] [Index]


[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2011 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice

===AUTO_SCHEMA_MARKUP===