Tectia

Chapter 11 Configuring SSH Product Settings

Table of Contents

Configuring Tectia
Configuration Options
Configuration Task Flow
Tectia Configuration Commands
Advanced XML Configuration
Configuring OpenSSH
Creating New OpenSSH Configurations
Importing OpenSSH Configurations
Enabling SFTP Logging on OpenSSH Server
Viewing and Comparing Configurations
Assigning Configurations per Group
Deploying Configurations
Automatically Detected Changes in Managed Files
Configuring Certificate Authentication
Configuring Certificate Authentication on Tectia Server
Configuring Certificate Authentication on Tectia Client/ConnectSecure
User Certificate Authentication
Other Host Management Options
Stopping and Starting Secure Shell Servers Remotely

Tectia and OpenSSH SSH clients and servers can be configured via Tectia Manager. The administration interface of Tectia Manager provides a graphical view into the configurations of Tectia Client, ConnectSecure, and Server. In addition, you can handle both Tectia and OpenSSH configurations in XML format via the administration interface.

Tectia Manager administration interface enables:

The Tectia configuration provides flexible and fine-grained setups for the managed Tectia software. Once the administrator has specified the Tectia configurations, Tectia Manager generates the XML format configuration files dynamically for different Tectia software versions.

[Tip]Tip

The administration interface of Tectia Manager does not support all Tectia configuration options, but advanced configurations can be entered directly in XML format. For a description of the settings, see Advanced XML Configuration.

Tectia Manager handles all OpenSSH configurations in XML format. Existings configurations can be imported from the hosts or the administrator can create a suitable configuration in Tectia Manager, and then assign and deploy them as updates to the managed OpenSSH Hosts.

The SSH configuration management consists of the following steps:

  1. Create/edit the configurations (Configurations → Edit Configurations).

    • Create the configuration and files to be distributed based on the environment, configuration requirements, and company security policy.

      Note that it is possible to separate the administrator roles so that the engineering staff creates the configurations and assigns them to hosts, and the operational staff deploys them during the next scheduled maintenance period.

  2. Assign the configurations to the hosts and host groups (Configurations → Assign configurations).

    • Define the configuration to be used per host group or per host.

    • If no configuration is defined, the configuration of the parent group will be used.

    After the definitions for all host groups have been created, only the edit and deploy actions (steps 1 and 3) are needed. By default the settings are inherited from a parent group, so creating a default setting and assigning it to the root of the host view is recommended.

  3. Deploy the configurations to the hosts (Configurations → Deploy configurations).

    • Distribution will be started after the administrator launches the deployment.

    • Configuration updates will be queued and executed in parallel to a predefined number of hosts.

    • Old pending configuration updates will be overridden if a new update is launched before all the old ones have been successfully completed.

The actual configuration deployment to the SSH products works as follows:

  1. The Management Server creates the configuration files based on the host group assignment and the SSH software versions of the managed hosts.

  2. The configuration files are sent to the Management Agent over the management connection.

  3. The Management Agent makes a backup of the old configuration, installs the new configuration files, and restarts/reconfigures the SSH product when applicable.

  4. After a few seconds, the Management Agent checks whether the updated SSH product appears to be running normally. If so, it reports success to the Management Server. Otherwise it reverts to the previous configuration, restarts the SSH product again, and reports failure to the Management Server.

[Tip]Tip

It is a good practise to set up a group of test machines, where each new configuration can be tested before applying it into production environment. In case strict configuration verification policy is in use, the person making the actual deployment should not be the same person who created or changed the configuration (checking/verification of the new settings made).