Skip to main content

Hosts in the Managed Environment

Symptom: Host names display as IP addresses, instead of DNS names.​

  • Key Manager relies on a functioning DNS server to perform name resolution for the hosts in the managed environment. Make sure that the DNS settings are correct for the Key Manager Server components and the deployment environment.

    This issue is likely to occur in isolated test environments.

Symptom: Key-activity scan fails on some hosts.​

Symptom: Shell-based scans time out on some hosts.​

  • If shell-based scans keep failing due to timeout, change the setting Use exit value optimization under Settings→General→Host page. For more information about this setting, see Host Settings.

Symptom: Key-activity scan fail with KeyActivityScanError: Key activity scan found activities from too far future.​

  • This is likely caused by the host clock being set too far into the future compared to the Key Manager Database clock. Key-activity-scan jobs fail automatically when Key Manager finds key-activity entries that are more than one day ahead of the time given by the Key Manager Database.

    To fix this issue, perform the following on all the hosts where the symptom occurs:

    1. Adjust the system clock of the target host to be within 24 hours of the Key Manager Database clock. Doing so prevents the host from generating key-activity entries with future timestamps.

    2. After synchronizing the system clock, note that key-activity scans continue failing as long as there are log entries with future timestamps. To allow key-activity scans to run successfully, you will still have to perform one of the following procedures:

      • Wait until the system time advances past the latest timestamp found in the logs. After this, there should be no more entries with future timestamps, and key-activity scans should run successfully on the host.

      • Manually adjust the log entries that have future timestamps. Such log entries must be given timestamps that are not in the future. Note that key-activity entries are recorded with the timestamps found in the log entries.

        If the timestamps do not encode the year of the entry and the host clock is moved backwards. Any entries with future timestamps will be discovered and accounted for the previous year upon the next key-activity scan.

      • Key-activity scans can also be fixed by removing the log entries that have future timestamps. Note that Key Manager will be unable to discover and account deleted entries.

    After the fixes, rerun key-activity scans on the affected hosts to verify whether the problem was fixed.

Symptom: Scan jobs fail with alert "Failed to scan user keys '<exampleuser>' - Could not switch to user."​

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

  • Key Manager switches to each user on the target host to read user-key files as the owner. If Key Manager being unable to switch to a certain user account, scans for that user are marked as failed. Consequently, the entire scan is marked as failed.

    To resolve the issue, determine the user accounts that cause the scan jobs to fail. The offending users should be listed in the jobs logs of the failed scan jobs, and in the alerts that resulted from those failed scan jobs.

    After you have determined user accounts that cause the scan jobs to fail, determine why the management user of the host is unable to switch to those users. For example, you can manually log into the host as the management user, then attempt to switch to the offending user using sudo su - exampleuser.

    Resolve the user-switching issues and rerun scan jobs on the target host to see if the problem was fixed. In situations where fixing user switching is not applicable, you may exclude the account from the scans. Excluding accounts is described in a later solution.

    You may also change the Key Manager user-switching behavior with various host settings, such as:

    • Disregarded Unix user account names

    • Prefer su over sudo

    • Comma separated list of invalid user shells

    • Comma separated list of restricted user shells

    • Group listing command on Unix and Linux hosts

    • User listing command on Unix and Linux hosts

    For more information about the host settings available in Key Manager, see Host Settings.

Symptom: Host scan cannot find all accounts on Linux when sssd is used​

  • By default, Key Manager uses the getent passwd command to determine the user accounts on a host. Any accounts omitted by getent passwd are not detected. For example when enumeration is disabled, getent passwd only lists local users, while network users (LDAP or AD) are not listed.

    One possible workaround is to configure getenv passwd in a way that lists all users. Alternatively, you may create your own user-listing command that lists the required users, then set the User listing command on Unix and Linux hosts for any hosts that require it. On hosts that use script-based scans, the user-listing command must be executable locally as part of the script.

    Key Manager expects the user-listing command to list individual user data in the /etc/passwd format:

    username:password:uid:gid:GECOS:home_directory:login_shell

    Where the 7 colon-delimited fields correspond to:

    1. User name used for login.

    2. Password. An x character indicates that encrypted and salted password is stored in /etc/shadow file.

    3. User ID (uid).

    4. Primary group ID (gid).

    5. User ID info (GECOS) fields.

    6. Home-directory path.

    7. Path to the user's shell or command.

    In environments with AD and POSIX values, you will need to ensure that user and group entries have proper values.

    If you have AD users that do not use Windows SID values, AD group needs to have the POSIX attribute for gidNumber. Additionally, AD users must have POSIX attributes for at least the following fields:

    • uidNumber

    • gidNumber

    • unixHomeDirectory

    • loginShell

    If some defaults are not set, you can use the fallback options in sssd.conf. For example:

    fallback_homedir = /home/%u@%d

    Example /etc/sssd/sssd.conf configuration:

    [sssd]
    domains = 1111111
    config_file_version = 2
    services = nss, pam

    [domain/111111]
    ad_domain = 111111
    krb5_realm = 111111
    realmd_tags = manages-system joined-with-adcli
    cache_credentials = True                        ❶
    offline_credentials_expiration = 3              ❷
    id_provider = ad
    krb5_store_password_if_offline = True
    default_shell = /bin/bash                       ❸
    ldap_id_mapping = False                         ❹
    use_fully_qualified_names = False
    fallback_homedir = /home/%u@%d                  ❺
    access_provider = simple                        ❻
    simple_allow_groups = group1, group2, group3    ❼

    ❶ Log in with previously cached credential if no connection to ensure_directory.

    ❷ Cache calidity period.

    ❸ Fallback if not set on LDAP or AD.

    ❹ If True, Windows AD SID is used for user and group IDs.

    ❺ Fallback home directory if not set on LDAP or AD.

    ❻ The chosen access method.

    ❼ The list of groups allowing access to this host.

Symptom: Key relocation fails with Relocate host user​

  • Key relocation was attempted with Key Manager having out-of-date host information. This can happen, for example, if a user on the host was deleted after the last host scan.

The issue may be fixed by running a host scan, after which you should try performing the key-relocation action again.

Symptom: Key-relocation job fails with message sudo: sorry, you must have a tty to run sudo​

  • Key Manager performs certain host operations using passwordless sudo. Such operations fail when sudo is configured to require a tty. To solve this issue, change the configuration so that a tty is not required for the management user of the host.

    Typically, tty requirements (requiretty) for sudo are defined in the /etc/sudoers file, by a line like the following:

    Defaults requiretty

    You can disable requiretty for the host by changing the line to the following:

    Defaults !requiretty

    Alternatively, you can disable requiretty just for the management user (replace sshmgr with the name of the management user of the host):

    Defaults:sshmgr !requiretty

    Save your changes to the /etc/sudoers file and retry the previously-failed operation to verify whether the problem was fixed.

Symptom: Certain jobs fail repeatedly on some hosts.​

  • For information about why a job fails, review the job log generated from the failed job.

You can enable debug mode on hosts to get more detailed job logs from jobs pertaining to those hosts. For instructions about setting debug mode, see Enabling More-Detailed Job Logs.

Symptom: Unix-host scan job fails with error No users found on host​

  • If Key Manager is unable to find any users from a host during a host scan, the scan is marked as failed with an error message like the following:

    No users found on host (you may need to use a custom user listing command on this host)

    Key Manager detects users on the host by running the command that is defined in the host setting User listing command on Unix and Linux hosts. If this setting is undefined, Key Manager defaults to using the command getent passwd. You must ensure that the user-listing command returns at least one user entry. This can be done as follows:

    1. Optional: Determine the command used for listing users on the host. One way to do this is by running a command-line client command similar to the following:

      $ ssh-mgr-client list-host-settings -I "hostname=server.example.com" \
      -F "name=user_list_command" -C value

      If an empty string is returned, then the user-listing command is the default getent passwd.

    2. Optional: On the host where the scan jobs are failing, run the user-listing command as root. The output of the command may provide more information about why Key Manager is unable to find users on the host.

      Ensure that the command returns at least one user, and that the user information is returned in the same format as used by the getent passwd command. If the user-listing command fails to satisfy these conditions, proceed to the next step.

    3. For the target host, specify a new user-listing command that returns at least one user, and that the user information is returned in the same format as used by the getent passwd command. You can set the user-listing command using the command-line client, with a command similar to the following:

      $ ssh-mgr-client set-host-setting -I "hostname=server.example.com" -d \
      category=host,name=user_list_command,value=custom_user_listing_command

      After setting a new user-listing command, run a scan job on the host to test whether the problem has been fixed.