Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.

SSH Tectia

Managing Host Authentication

When a client connects to SSH Tectia Server, the server host authenticates itself to the client. If the client cannot authenticate the server, the client refuses to continue and disconnects. The server host can authenticate itself using public keys, certificates, or both, allowing for smooth migration from public keys to certificates.

Secure server authentication with public keys requires that the client possesses the public key of the server host before connecting. This means that the server host public keys need to be distributed to client hosts. In large networks (several hundred or more servers) it may not be feasible to send all server host keys to all client hosts because of the time and network traffic involved in copying the keys over the network. Therefore, it is recommended to use certificates for server host authentication in large environments; server certificates do not need to be distributed to client hosts, as distributing the CA certificate of the issuer of the certificates is enough.

Using Certificates

The CA-related configuration options for Internal and External CA Settings are defined in Settings → PKI Settings and require superuser administrator rights. See Configuring PKI Settings for CA.

Once the initial certificate enrollment has been done, SSH Tectia Manager Internal CA will automatically renew the server host certificates. The Internal Root CA Host certificate validity period and Certificate renew marginal can be configured in Settings → PKI Settings → Internal CAs. The changes in validity period will take effect the next time a new certificate is issued, but the changes in the renewal marginal will take effect immediately (Figure 9.21).

SSH Tectia Manager Internal CA publishes HTTP CRL(s) in port 80 when SSH Tectia Manager is running. An external command can be used to specify a script that will publish the CRL for example to LDAP or backup HTTP server. The CRL Distibution Point(s) are included in the issued host certificates. The CRL default update period is 3 hours and the validity period 27 hours (3-hour update period, 24-hour marginal.) The CRL publishing methods, CRL update period, and CRL next update marginal can be configured in Settings → PKI Settings → Internal CAs (Figure 9.22).

[Note]Note

The firewall configuration of the organization must allow the SSH Tectia client-side managed hosts to access the CRL Distribution Points (by default Management Server port 80).

Prerequisites for Using Certificate Authentication

  • If the Require FQDN option is set in the enrollment configuration (by default it is), the managed hosts must have a fully qualified domain name (FQDN).

  • The clocks on all the managed hosts must be approximately on the correct time. The issued certificates have a validity period starting one hour in the past and the issued CRLs likewise have a one hour marginal in their thisUpdate timestamps. This means that a clock that is more than an hour late will cause problems when validating a new certificate or using a just issued CRL.

Configuring Enrollment Settings

The enrollment settings must be configured by creating a configuration profile for certificate enrollment and for assigning it to hosts. There is no need to separately deploy the enrollment settings.

Host certificate enrollment settings can be created in Configurations → Edit Configurations under the PKI tab, Enrollment settings folder.

The following information must be specified:

  • The PKI settings used for enrolling the certificates. The preconfigured Internal Root CA is recommended.

  • Parameters for the keys to be generated: key type and length.

  • The subject name used in the certificate enrollment request. The subject name must be specified in the DN (Distinguished Name) notation. The default value works well in most cases. The following variables can be used within the subject name:

    • %IP_ADDRESS%, substituted with the IP address of the host.

    • %IP_ADDRESS_LIST%, substituted with all of the IP addresses of that host. Usable only in subject altName part (as in IP=%IP_ADDRESS_LIST%), not in the actual subject name.

    • %DNS_NAME%, substituted with the DNS name (fully qualified host name) of the host.

    • %DNS_NAME_LIST%, substituted with all of the DNS names of that host. Usable only in subject altName part (as in IP=%DNS_NAME_LIST%), not in the actual subject name.

    • %HOST_NAME%, substituted with the short host name (DNS name without the domain part).

    • %REFERENCE_NUMBER%, reference number of allocated authorization code for the host. Only needed in Entrust Web Enrollment.

    The subject name field is mostly parsed as a Distinguished Name (DN). However, additional semicolon-separated fields DNS and IP can be used to specify subject alternative names for a request (see example below). Note that this means that a colon has to be used to separate RDNs in the DN. The default value for subject name field is CN=%DNS_NAME%;DNS=%DNS_NAME_LIST%;IP=%IP_ADDRESS_LIST%. For example, this will add multiple subject alternative name DNS entries to the host certificate if the host has reported aliases.

  • Select whether FQDN is required or not. If FQDN required is selected the managed host has to have a fully qualified domain name, which is used in the subject name field so that it will be added as a name in the host certificate. If FQDN is not required, an IP address in certificate will be sufficient. Without FQDN the server authentication in the Secure Shell client will be restricted to connections with explicit IP addresses.

Enrollment Jobs

Host certificate mass enrollment jobs can be started and monitored in Configurations → Enroll certificates. For each new job, select the host group for which host certificates will be enrolled.

Hosts with a certificate that is valid for more than two weeks are excluded from the enrollment by default. The validity is based on the expiration date of the currently managed host certificate. Clear the check box to enroll certificates for all hosts in the selected group, or adjust the time frame to include the intended hosts.

Select Revoke previous certificate if the currently managed host certificate should be revoked after a successful enrollment.

Enrolling certificates

Figure 9.23. Enrolling certificates

The progress of running and finished enrollment jobs (including certificate renewal jobs initiated by SSH Tectia Manager) can be monitored in Configurations → Enroll certificates. The running enrollment jobs can be aborted.

In case the External CA settings require a pre-shared key (PSK) to authenticate the enrollment requests to the CA enrollment service, the enrollment job will be pending until PSKs have been provided. The required PKSs for hosts can be viewed and entered in Configurations → Enroll certificates → Required PSKs.

Managed Host Certificate

When a host certificate is enrolled for a host, the private key and certificate request are generated on the managed host. The Management Server verifies that the certificate request matches the configuration and enrolls the certificate. The certificate issued by the CA is entered under management and installed on the host.

The Management Agent reports the installed host certificate to the Management Server periodically. The installed host certificate can be viewed and downloaded, and the managed certificate(s) can be revoked in the Secure Shell software → Host certificate tab on the View host page of each managed host. See Figure 9.24.

Host certificate

Figure 9.24. Host certificate

Configuring SSH Tectia Server

After a certificate has been enrolled for a host, if the host has a deployed configuration, the configuration is automatically updated and the certificate is taken into use. No further configuration steps are necessary to enable authenticating the host using the certificate.

If the host has an assigned configuration that is not yet deployed, the certificate is enrolled for the host, but it is taken into use only after the configuration is deployed. Once deployed, the configuration will automatically use the certificate information.

If the host does not have an assigned configuration, only the certificate is enrolled for the host and no configuration is deployed to the host. To use the certificate for authenticating the host, you have to create a configuration for the host, and assign and deploy it. Once deployed, the configuration will automatically use the certificate information.

Configuring SSH Tectia Client/ConnectSecure

SSH Tectia Client and SSH Tectia ConnectSecure need to be separately configured to authenticate server hosts using host certificates. The authentication settings can be configured in Configurations → Edit Configurations → SSH Tectia → Client under the PKI page.

The following settings need to be configured:

  • The list of trusted CA certificates. These are used to check the validity of host certificates.

    In case SSH Tectia Manager Internal CA is used, defining the trusted certificate is the only required setting. To use the Internal CA, select Internal Root CA as the CA certificate.

  • The LDAP servers used to retrieve CRLs and subordinate CA certificates in a CA hierarchy should be configured. These settings are necessary only if the host certificates themselves do not contain valid Authority Info Access and/or CRL Distribution Point extensions.

  • If OCSP should be used instead of CRLs and the host certificates themselves do not contain the information, the default OCSP responder URL should be configured.

If CRL checking is disabled, the LDAP server and OCSP responder URLs do not need to be configured. CRL checking should be disabled for testing purposes only.

Activating the settings requires assigning the configuration to the appropriate hosts and redeploying the configurations.

Host Key Distribution

SSH Tectia Manager automates the distribution and maintenance of the server host public keys (also called host keys). It makes the management of these keys completely transparent. Host key authentication can be used when PKI is not available.

Using automated host key distribution eliminates new-key-approval or key-changed messages that may confuse the users. It also makes it feasible to update host keys in small and medium size networks.

Host key distribution to managed hosts can be enabled or disabled for the whole environment from Settings → System Settings. By default, host key distribution is enabled.

Host Key Locations on the Managed Hosts

When host key distribution is enabled, the Management Server collects the public host keys of the managed hosts that have supported Secure Shell server software installed and distributes them automatically to the local host key databases common to all users on the managed hosts.

  • On Unix:

    /etc/ssh2/hostkeys
    
  • On Windows XP and Server 2003:

    C:\Documents and Settings\All Users\Application Data\SSH\HostKeys
    
  • On Windows Vista:

    C:\ProgramData\SSH\HostKeys
    

To allow host-based authentication on Unix, the public host keys are also distributed to the /etc/ssh2/knownhosts directory.

When verifying host keys, SSH Tectia Client first reads the current user's host key database:

  • On Unix: $HOME/.ssh2/hostkeys

  • On Windows: %APPDATA%\SSH\HostKeys

Next, it reads the host key database common to all users.

If Secure Shell software has already been installed on the managed host, make sure that the user-specific host-key locations do not contain any keys for the hosts that should be centrally managed.

See Host Key Distribution Process for more details on host key distribution.

Resending Host Keys to a Managed Host

Host keys of managed server hosts can be resent to a host from the Host view page of a host.

To do this, select the Secure Shell software tab and the Host key distribution tab. Click Resend all host keys to this host to send all server host public keys from the Management Server to the host.

If an automatic host key update has failed, the page will display the next update time. The update can also be retried manually by clicking the Retry host key distribution now button. It will only send information on changed host keys that need to be updated.

===AUTO_SCHEMA_MARKUP===