Your browser does not allow storing cookies. We recommend enabling them.


Chapter 11 Configuring SSH Product Settings

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:

  • creating configurations

  • editing configurations

  • importing existing OpenSSH configurations in XML format

  • storing multiple configurations

  • audit log of the changes made

  • online help for the configuration parameters

  • a guided task flow of create/edit → assign → deploy

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.


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.


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).




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now