Skip to main content

Key Manager Limitations

The following subsections describe the features and the limitations related to Key Manager functionality.

General Limitations​

The following limitations apply generally to Key Manager operations:

  • When running management jobs, Key Manager uses terminal output to determine the outcome of individual actions. Broadcast messages occurring during job execution may cause the job to fail. As with all jobs, the reason of failure can be determined by reviewing the job log. Most management jobs that failed due to a broadcast message can be rerun later.

  • Key Manager is currently unable to automatically detect the host time zone on AIX platforms.

Key Manager is only able to perform automatic time-zone detection on hosts that use the Olson time- zone format; automatic time-zone detection is not supported on hosts using the POSIX time-zone format (including AIX hosts). However, the time zone for such hosts can be specified manually into the Key Manager system.

  • Key Manager disallows creating new authorizations with SSH1 keys as they are considered insecure. However, Key Manager does support actions for managing existing SSH1 keys and authorizations, including SSH1 key restoration and renewal.

  • Key relocation is not supported on the following types of hosts:

    • Hosts running SunSSH or OpenSSH versions 4.3 or older.
    • Hosts running any version of Attachmate RSIT.
    • Hosts with user keys located in shared home directories.
    • Hosts where Tectia SSH Server is run without a configuration file.
    • Windows hosts running OpenSSH Server.
    • z/OS hosts.

  • Authorizations with validity periods are not added and/or removed precisely in accordance to their validity periods. In all cases, the start of a validity period specifies the earliest moment when the authorization may be added. Similarly, the end of a validity period specifies the earliest moment when the authorization may be removed. Under typical operation, jobs for adding/removing temporary authorizations are created before the temporary authorization is to be added/removed, and the jobs are scheduled to run in accordance to the timestamps specified by the authorization validity period. However, note that the execution of those jobs follows the standard Key Manager job lifecycle, and that following factors may delay their execution:

    • On busy Key Manager systems, the jobs for adding/removing temporary authorizations are queued until the system is able to run the creation/removal jobs.

    • On agent-based hosts, authorization-adding jobs are run during the next agent connection after the beginning of the validity period. Similarly, authorization-removal jobs are run during the next agent connection after the end of the validity period. Handling of temporary authorizations may be significantly delayed on agent-based hosts with long agent-connection intervals.

    • No jobs can be run on a host while it is unavailable.

  • To encrypt the Key Manager Database with a passphrase that contains non-ASCII characters, the passphrase must be provided as a command-line option. For example, instead of running:

# /opt/sshmgr/bin/ssh-mgr-setup

Run (replace example_pässphräse with your database-encryption passphrase):

# /opt/sshmgr/bin/ssh-mgr-setup --encryption-passphrase=example_pässphräse

Managed-Host Limitations​

  • On z/OS hosts, Key Manager only supports managing the following products, configurations, and SSH keys:

    • Tectia Server for IBM z/OS configurations and keys stored in Unix System Services (USS). Note that for configurations, the supported actions are limited to discovery.

    • OpenSSH configurations and keys stored in Unix System Services (USS). Note that for configurations, the supported actions are limited to discovery.

    • OpenSSH configurations and keys stored in System Authorization Services (SAF). Note that for SAF keys, the supported key actions are limited to discovery, setting authorized-key options, removal, and restoration; for configurations, the supported actions are limited to discovery.

    • On agentless hosts where the home directory of the management user is shared with other users, it is possible to remove the management key. You can recreate a management key by redeploying the host.

  • On Ubuntu hosts that use eCryptfs (encrypted home directories), the SSH user keys located under encrypted home directories are not accessible when the user is logged out. This prevents both the SSH server and Key Manager from reading or using the keys located on an encrypted home directory, unless the user owning that home directory is currently logged in. To allow SSH keys to be used at all times on hosts with encrypted home directories, you can relocate user keys to centralized locations outside the encrypted home directories.

    User-key relocation can be performed using Key Manager key-relocation utilities. For more information, see the Administrator Manual section about relocating user keys.

  • Externally-monitored Windows hosts cannot be directly deployed to the monitored state.

  • On Windows hosts, Key Manager only detects users that have a profile directory on the host. The profile directory is created upon the user's first logon.

  • On hosts with OpenSSH versions 4.x or 5.x, the first key-activity scan may be falsely marked as successful, whereas subsequent scans fail due to insufficient logging level. Workaround is to Ensure the OpenSSH LogLevel is set to VERBOSE.

  • On Windows hosts, OpenSSH can only be installed as a Windows Optional Feature in the following supported Windows releases:

    • Windows Server 2019 (OpenSSH 7.7p1)

    • Windows Server 2022 (OpenSSH 8.1p1)

    • Windows 10 (build 1809 and later) (OpenSSH 7.7p1)

    The Windows hosts where the optional OpenSSH has been installed are subject to the following limitations:

    • Key Manager only supports user-specific key files. Match Group rules in sshd_config are not supported.

    • Key activity scan does not return OpenSSH server login details.

    • OpenSSH server authorized keys can not be relocated.

    • Passphrases can not be changed for existing private keys.

SSH Product-Specific Limitations​

  • Key Manager is unable to discover SSH1 key activity on hosts running certain OpenSSH versions with specific OpenSSH configurations. This happens when an OpenSSH host meets all of the following conditions:

    • The OpenSSH server version is earlier than 5.9, or later than 6.2.

    • The OpenSSH server on the host uses protocol 1.

    • The host contains SSH1 authorized keys.

    • UsePrivilegeSeparation is set to yes or sandbox.

    In the described scenario, the OpenSSH server may generate incomplete SSH1 key-activity entries, such as entries with missing key fingerprints. When Key Manager detects this scenario on a host, Key Manager raises alerts when incomplete key-activity entries are found. To ensure that the OpenSSH server generates complete key-activity entries, you need to make changes to the host so that at least one of the previously-described conditions no longer holds true.

    Note that even after you have changed the conditions of the host, there may still be incomplete key- activity entries from the time before the changes. Any incomplete key-activity entries discovered during a key-activity scan are logged in the job log. Additionally, Key Manager raises alerts when incomplete key-activity entries are found.

  • On hosts that have been installed with multiple SSH product families, keys are generated for the preferred product. For example, on hosts where both Tectia and OpenSSH client and server are installed, authorizations are generated for the Tectia client and server. When renewing or restoring user keys, these are always renewed/restored to the preferred product (even if they originally belonged to another

    The preferred-product order can be customized on a system-wide basis, to control which product is regarded as the preferred product on hosts where multiple SSH products are installed.

  • On hosts where Quest Authentication Services are enabled, host scans fail if QAS users have user names that are longer than the user-name-length limit on the host. This is because Key Manager is unable to read the SSH keys of such users, causing the entire host scan to fail. The problem can be resolved by raising the user-name-length limit on the hosts where this problem occurs.

  • On Tectia hosts with duplicate keys in both authorization file and authorized_keys directory, one of the keys will be incorrectly flagged as missing after relocation.

  • Adding agentless Tectia host fails if the server has been configured to use only openssh-authorized- keys-file for public-key authentication.

  • For authorized keys present on hosts where multiple SSH servers are installed, login counts reported in key activity logs may be higher than actual usage.

    Key Manager parses login information on a host, once per each installed SSH server. On hosts where multiple SSH servers are installed, single login entries may be incorrectly matched and logged multiple times.

  • OpenSSH authorized keys with multiple from stanzas are not handled correctly. Key Manager consolidates all from stanzas into a single from stanza. Compare to OpenSSH behavior where an address is allowed only if it exists in all the from stanzas.

The following limitations apply to SSH configurations:

  • For hosts running Attachmate RSIT server or Tectia Server for IBM z/OS to be manageable via Key Manager, the SSH server configuration must not contain HostSpecificConfig or UserSpecificConfig elements.

  • Key Manager does not support OpenSSH-based hosts where the SSH configuration contains AuthorizedKeysCommand keywords. Key Manager automatically fails any host scans run on such hosts.

    OpenSSH-based products include Centrify SSH, OpenSSH, SunSSH, and Quest OpenSSH.

  • When deploying a Tectia Server configuration to Windows platforms, if the configuration contains 64- bit paths (such as C:\Program Files (x86)\SSH Communications Security), it will fail to deploy on 32-bit Windows platforms, and vice versa.

The following features and limitations apply to managing hosts running PuTTY Client:

  • PuTTY Client support is limited to Windows hosts managed using offline scans. If a host with PuTTY keys is deployed to use agentless or agent-based connections, all visibility to PuTTY keys is lost.

  • Key Manager is unable to correctly determine the the PuTTY version in situations where it was not installed using the PuTTY installer.

  • By default, key discovery is limited to those keys that have been saved in PuTTY sessions.

  • Discovery of SSH1 keys is not supported. However, the host utility raises warnings when it detects PuTTY SSH1 key files. Instructions for capturing warnings raised by the Key Manager host utility are provided in the Administrator Manual.

Features and Limitations of Key Renewal​

These features and limitations apply when renewing user keys using Key Manager:

  • When using staged renewal, the SSH client configuration on the target host must be in the managed state. This is because Key Manager adds new identity-file locations to the client configuration, in order to accommodate for the staged keys. Also note that the added identity-file locations are not automatically removed from client configurations after staged renewal is completed.

  • Key Manager does not automatically renew duplicates of the selected private keys. Authorizations for unselected duplicates of renewed private keys will stop working after the renewal process, unless they are selected for renewal as well. Make sure to select and renew all the copies of a private key if you want to preserve existing authorizations. You can find all the known copies of a private key using the fingerprint of the private key.

  • Key Manager does not renew keys if the renewal operation causes other keys to be overwritten. This occurs in the following scenarios:

    • Attempting to renew a key object that has the same file location as another existing private key. For example, after you have renewed a key more than once, and when you attempt to renew a deleted entry that describes an earlier "revision" of that key. If you absolutely need to renew your key entry, you must first delete key that is currently occupying the specified file location. We strongly recommend that you thoroughly review the present key before deleting it.

    • Attempting to renew multiple key objects that have the same file location. For each unique file location, you can only select one private key for renewal.

  • Key Manager only renews active parts of the authorization. Renewal ignores undiscovered keys (such as keys outside the managed environment) and keys outside of SSH configurations (such as keys in the Missing state).

  • Passphrases are only inherited if the passphrase of the key is stored in Key Manager. In situations where you renew a passphrase-protected key, the passphrase of which is not stored in Key Manager, the passphrase for the key is set as follows:

    • If the passphrase policy (on the host where the private key is) is set to optional, the new private key is not passphrase-protected.

    • If the passphrase policy (on the host where the private key is) is set to mandatory, the new private key is protected with a random passphrase. Consult the Key Manager administrators to obtain the passphrase.

  • Renewed keys are given new key IDs in the Key Manager system.

  • On OpenSSH hosts, a renewed private key retains the file name of the old key. For example, a private key called id_rsa will (even if renewed with the DSA algorithm) still have the name id_rsa.

  • On Tectia and Attachmate hosts, a restored authorized key has a different file name than the original key.

  • Actual staging time for staged renewals may differ slightly from the specified time. Deviations of several minutes should be expected.

    When performing staged renewal, note that the period starts from when the main job is created. Also note that staged renewals are resumed according to regular job-wakeup procedures.

  • Key Manager does not allow renewing authorizations where one or more keys keys have the appeared status (typically these are keys that have been manually added to the host, without using Key Manager). Before such authorizations can be renewed, the appeared keys must be either approved or removed.

  • On hosts with multiple SSH products, keys are renewed to the preferred product (even if the original keys are from another product).

Limitations in AD Authentication​

  • AD authorization to Key Manager is granted per AD group. Note however that authorization to Key Manager is only granted to the direct members of the groups. Nested groups are not automatically given any permissions.

  • Key Manager looks up AD group memberships from the domain controller an AD user is found from, and domain controllers do not contain information about user memberships in other domains. For this reason, AD authorization is possible only for AD users whose account belongs in the same domain as its parent group.

Limitations in Upgrade Scenarios​

  • When upgrading from 1.1.0, site-wide settings are reset to their default values.

  • If you are using 1.2 agents on Windows platforms, the IP-address information of the host is not displayed in later versions of Key Manager. Upgrading the agent to version 1.3 or later fixes this.

  • When using Key Manager 1.2.3 and AuthorizedKeysFile2 was not defined in the SSH server configuration Key Manager was incorrectly reporting keys within that file as authorized. This is now corrected in 1.2.4 & 1.3 so that only the keys that are configured are shown as authorized. However if upgrading from 1.2.3 to a newer version these keys will now show as missing. Attempting to delete those keys will show them as deleted but they will remain on disk on the target host.

  • Application-key associations defined in pre-1.5.1 system versions are not in any way supported by Key Manager versions 1.5.1 and later. If you have defined application-key associations in a pre-1.5.1 system, you must manually redefine the application-key associations after upgrade to 1.5.1 and later versions.

  • Pending action requests from pre-1.6.0 system versions cannot be resolved after upgrade to 1.6.0 or later. You must resolve (approve and execute, deny, or cancel) all action requests before upgrading.

Other Limitations​

  • If syslog rotation occurs between host deployment and the first key-activity scan on the host, SSH logins from this time may not be picked up by the key-activity scan.