Host Settings
Settings in the host category define Key Manager host-management characteristics, such as host-scan intervals and timeout periods for job-related actions.
Some host settings limit the maximum duration of certain operations. This is done to detect and clean up jobs that have potentially hanged. In networks with high latency, and on hosts with many users and keys, jobs will naturally require more time to complete. If you suspect that some jobs are timing out due to reasons other than hanging, setting the relevant timeout settings to higher values may fix the problem.
Access Group ID for Zero Trust access
Set the value that will be passed to PrivX when Key Manager has been configured to act as a host store for PrivX.
Additional allow-from addresses for incoming connections
Additional addresses that are automatically included as allowed sources when adding authorizations
to the host(s). Useful in NAT environments where destination hosts perceive connections coming
from a gateway host instead of the original source. Specified as comma-separated IP and/or FQDN
addresses. Parts of the addresses may be substituted with the * wildcard.
Additional allow-from addresses for outgoing connections
Additional addresses that are automatically included as allowed sources when adding authorizations
from the host(s). Useful in NAT environments where destination hosts perceive connections coming
from a gateway host instead of the original source. Specified as comma-separated IP or FQDN
addresses. Parts of the addresses may be substituted with the * wildcard.
Additional allow-from addresses for management keys
Additional addresses from which agentless management keys are usable from. Specified as comma- separated IP or FQDN addresses. Applicable only when Use allow-from options in management keys is set to True. For more information about this setting, see Setting Allow-From Options to Management Keys.
Agent connection interval
The interval at which agent-based hosts fetch job information from Key Manager. Specified in seconds (minimum 60).
Decreasing the connection interval allows agent-based hosts to fetch new job requests more frequently, but introduces more load on the Key Manager back ends. Increasing the connection interval has the opposite effect on response time and back-end load.
Agent connection interval distribution
The maximum time that is randomly added or substracted from the next agent-connection time. Specified as percents of the agent-connection interval. For example, on a host with an agent- connection interval of 3600 seconds, and with an agent-connection-interval distribution of 50, the next agent connection would be scheduled anywhere between 1800 seconds and 5400 seconds. Set this to 50 to evenly distribute connection times. Set this to 0 to connect precisely according to the agent-connection interval.
Distributing agent-connection times can help distribute the load on Key Manager back ends, particularly in environments where agent-based hosts with similar agent-connection intervals have been deployed simultaneously.
Agent log level
Specify the detail at which agents log their actions.
To control the location(s) to which agent messages are logged, see the Agent log output setting.
Agent log output
Enable or disable agent logging. When enabled, the agent can be configured to log to its own log file, to the syslog/event log (on Unix/Windows machines respectively), or to both of these locations.
Agent monitoring messages
A comma-separated list describing the types of agent-monitoring messages that are to be logged to syslog (on Unix hosts) or to the event log (on Windows hosts). For example:
STARTED,CONNECTED,STOPPED
When set to blank or OFF, no agent-monitoring messages are logged.
The available message types and the messages they generate are as follows:
-
STARTED: Agent started.
-
CONNECTION_FAILED: Agent connection failed with every back-end server.
-
CONNECTED: Agent connection succeeded with a back-end server.
-
ERROR: Agent error condition. Agent stopped.
-
STOPPED: Agent stopped.
When this setting is set to ALL, all types of messages are logged.
The messages enabled via this option are always logged to syslog (on Unix hosts) or to event logs (on Windows hosts), regardless of the Agent log output setting.
Agent-monitoring messages are written using the default facility (LOG_USER), and using the
log level Notice (LOG_NOTICE).
Available-host period
The duration for which hosts in the Available state are stored by the Key Manager system. Specified in seconds (minimum 300)
Hosts in the available state have been initially discovered during host addition, but full deployment has not yet been initiated for them. When hosts are added to the managed environment, Key Manager runs automatic discovery jobs for discovering the users, keys, and other relevant data on the host. If the discovery job is successful, the host is automatically put to the monitored state. If a host instead ends up in the available state after host discovery is completed, this indicates that something has gone wrong with the initial discovery jobs.
To manage hosts in the available state, you must rerun host discovery on the host by deploying the host. Make sure that the host is accessible, and that you have provided valid credentials for logging into the host.
In the Key Manager GUI, hosts in the available state are by default hidden by filters. You may have to adjust your filter settings to display the hosts in the available state.
Authorized key backup
When enabled, authorized keys deleted using Key Manager are automatically backed up. When disabled, authorized keys are not backed up.
Backup keys created by Key Manager are placed under the .ssh-mgr-backup directory, relative to
the path of the original key. Individual backup keys are named in the originalname_timestamp
format, where originalname is the original file name, and the timestamp represents when the backup
was taken.
Authorized-key-scan interval
The interval at which Key Manager performs authorized key scans on the agentless hosts.
This setting is a calendar-based setting. For more information about configuring calendar-based settings, see Configuring Calendar-Based Settings.
Authorized keys receiving activity
Authorized keys that are scanned for key activity data. When set to Present, key-activity data is scanned for all the authorized keys on the target host (including those keys that are outside configuration). When set to Active, key-activity data is scanned for all the authorized keys that are specified in the SSH server configuration on the target host.
For other settings that affect key-activity scans, see the host settings OS based syslog paths, Syslog file directories on host, Syslog file name patterns, Syslog content filter patterns for KA, and Syslog pre-filtering pattern.
Broadest permissions for authorized key files
This setting is used when:
-
Evaluating Key permissions policies. Authorized keys with broader permissions are flagged.
-
Performing Set Permissions actions on authorized keys. The permissions of target authorized keys is set to this value.
Broadest permissions for key files' parent folder
This setting is used when:
-
Evaluating Key permissions policies. Key-file parent directories with broader permissions are flagged.
-
Performing Set Permissions actions on user keys. The permissions of target key-files' parent directories is set to this value.
Broadest permissions for private key files
This setting is used when:
-
Evaluating Key permissions policies. Private keys with broader permissions are flagged.
-
Performing a Set Permissions action on private keys. The permissions of target private keys is set to this value.
Comma separated list of invalid user shells
Comma-separated list of strings that match invalid user shells. If a user's shell ends with any of these strings, the user account is considered invalid. Matching users and their objects (such as their user keys) are entirely ignored by Key Manager.
Comma separated list of restricted user shells
Comma separated list of restricted user shells. If a user's shell ends with any of these strings, the user account is considered restricted.
If sudo is not installed on the host, users with restricted shells are not scanned for user keys. Key
Manager raises alerts to help you keep track of users for which key scan is skipped.
Configuration data for the sudo password API
Configuration data for fetching sudo passwords from a password vault. Required on hosts where management account uses sudo with password.
For more information about this setting, see Obtaining sudo Password from a Credentials Vault.
Configuration-scan interval
The interval at which Key Manager performs configuration scans on the agentless hosts.
This setting is a calendar-based setting. For more information about configuring calendar-based settings, see Configuring Calendar-Based Settings.
Custom locations to search for private keys
JSON encoded dictionary. Define a list of paths per user account (regexp) where to look for private keys during scans. Only immediate files in the folders are scanned. For example:
{"^alice$": ["/home/alice/additional_keys/","/home/alice/more_keys/"]}
Currently only implemented for script-based scans.
JSON keys are regexp patterns and found keys are marked to belong to the first user
matching the pattern. It is therefore recommended to always use home directory or username
component (%h or %u) with a regexp pattern that matches multiple users. For example
scanning all "additional_keys" folders under home directories of accounts user01…user99:
{"^user.*$": ["%h/additional_keys/"]}
For this setting to work, you must also set the Host setting Scan ~/.ssh directory to Yes.
Debug mode
When Debug mode is enabled, jobs run on the host generate more-detailed logs, which may help in troubleshooting issues related to managing that host.
Deny actions on shared keys
When enabled, block actions on keys where the same key file is shared between multiple locations, unless a separate per-action, or per-request flag is given to bypass the setting.
Disregarded Unix user account names
Regular expression matching to invalid and unsupported Unix user-account names. Matching users
and their objects (such as their user keys) are entirely ignored by Key Manager. For example, the
default value ^[+#]+.*$ ignores all accounts beginning with a +, or # (such as NIS users, netgroup
entries, and commented user names).
Enforce managed configurations
When enabled, Key Manager automatically rolls back changes in SSH software configurations on hosts. Only applies to SSH software configurations that are in the managed state.
Key Manager detects and rolls back changes during host scans other than key-activity scans.
Execute jobs using a script copied to the host, instead of over interactive SSH connection
When enabled, perform (supported) jobs using a local script instead of Key Manager back-end originated Secure Shell interactive connection. Default is disabled. Use of this operation decreases both database and network load.
Full-scan interval
The interval at which Key Manager performs full scans on the agentless hosts.
This setting is a calendar-based setting. For more information about configuring calendar-based settings, see Configuring Calendar-Based Settings.
Full scan type
Specify whether scans should detect non-local (network/directory) users and keys. Can be set to either of the following values:
-
Scan both locally and remotely stored keys: Detect both local and non-local users and keys. This is the default.
-
Scan only locally stored keys: Only detect local keys. Ignore NFS-mountable users and directory users that do not have local keys.
-
Scan only locally stored keys and network users without keys: Detect local users and keys, and network users that do not have keys.
This setting only applies to hosts that use the Key Manager host utility for scans: either offline scanning or script-based scanning (described in sections Host Discovery with Offline Scans and Choosing the Best Scan Method respectively). Hosts without the Key Manager host utility are always scanned for both local and remote users and keys.
Group-listing command on Unix and Linux hosts
The command used for listing groups on Unix hosts. Defaults to getent group.
The output of this command must be in the same format as the output returned by the command
getent group.
This command is run as-is on the hosts in the managed environment and may result in data loss if configured incorrectly.
Host command filter pattern
By default this setting is disabled.
When enabled, the value is a JSON object, consisting of a list of two element lists, whose head, and tail members are strings (regular expressions). The head of the tuple is a pattern which may contain groups. If the pattern matches, it is replaced with the contents of the tail, which may contain back references to the groups in pattern. Each inner list defined replacement is applied to the input in order they appear on the outer list.
For example, the following setting consumes MAILCHECK/comsat/biff originated host command
output:
[ [ "You have new mail", "" ], [ "\007*", "" ] ]
Host script path
The path of the host script used on host. By default it is /var/sshmgr-host-script.
Host script path on Windows OS
The path of the host utility used on a Windows host. By default is is %localappdata%\ssh-mgr-host-utility.exe.
Job-scheduling mode
Determines when jobs are started on hosts. For this purpose, Key Manager supports two job- scheduling modes:
-
Immediate: Run all jobs as soon as possible.
-
Mediated: Mediated mode can be used to manually control when jobs are run. In mediated mode, jobs that may write changes to hosts are held until manually triggered by an
update-hostscommand (via the command-line client). Running in mediated mode can be useful when you want to make sure that Key Manager does not modify hosts without specific approval. Note that read- only jobs such as scan jobs are still run automatically.The basic syntax of the update-hosts command is:
ssh-mgr-client update-hostsFor more information about the
update-hostscommand, see update-hosts.noteAll held jobs will be run as soon as possible if the job scheduling mode is switched from Mediated to Immediate.
Key action job priority
The priority with which Key Manager runs key-management jobs (all jobs except scan jobs) on hosts. Smaller value means higher priority.
Key-activity-scan interval
The interval at which the Key Manager back end scans the agentless hosts for key activity.
This setting is a calendar-based setting. For more information about configuring calendar-based settings, see Configuring Calendar-Based Settings.
Listen for sudo password prompts
When enabled, Key Manager expects actions on the management account to occasionally raise the sudo password prompt.
For more information about setting up management accounts with sudo passwords, see Obtaining sudo Password from a Credentials Vault.
Maintenance window
The time window during which it is possible to run management operations that write changes to the host. Such operations that are created outside the time window are scheduled to wait until a time window is reached. The execution of read-only operations such as scan jobs are not restricted by this setting. Additionally, jobs started with the emergency priority ignore all maintenance-window restrictions.
This setting is a calendar-based setting. For more information about configuring calendar-based settings, see Configuring Calendar-Based Settings.
Maximum key-activity history during the first scan
Key-activity-log entries older than this value are ignored. Specified in days (minimum 1). You can specify a value of 0 to import all key-activity history.
When hosts are initially brought to the managed environment, such hosts may contain extensive logs about key activity. Lower values can be used to prevent initial key-activity scans from timing out.
Maximum duration of a single job state
The maximum duration that a running job can spend in a single state before it is terminated. Specified in seconds (minimum 300).
The actions of a job are performed in sequential, distinct states during its execution. Key Manager automatically updates the state of a job according to the progress of the job. If the state of a job has not updated in this many seconds, the job is considered to have hanged, and is automatically terminated. The same applies to identity records of the running processes: If the process has not updated its progress in this period, it is assumed to be hanging, and the record is removed from the database.
Maximum amount of retries for a job
The maximum amount of retries for a job which could not run on a host because the host was not available. After reaching this limit the job is failed.
Maximum user and group-data listing command duration
The maximum duration a user-listing or user-group-listing command can take before its associated job is terminated (times out). Specified in seconds (minimum 10).
Some jobs (such as scanning hosts) need to list the users and groups of a host. On some hosts, these commands may take a very long time. For example, listing LDAP-based user and group information may take up to several minutes.
Maximum host-command duration
The maximum duration a host command can run before its associated job is terminated. Specified in seconds (minimum 10).
Host commands constitute the individual shell commands that are run on the hosts to accomplish key-
management and host-scanning jobs. For example, host commands used by Key Manager include cp,
cat, and uname. If the execution of any such command exceeds this number of seconds, the whole
job is considered to have hanged, and the job is automatically terminated.
The execution time of host commands depends on the amount of data on the host. You may have to set the duration to a greater value for hosts with lots of users and keys.
This option does not limit the duration of user-listing and user-group-listing commands. The maximum duration of user-listing and user-group-listing commands is specified by the host option Maximum host, user, and group-data listing command duration.
Passphrase character set
The minimum character set that must be satisfied by the passphrase. Key Manager disallows setting passphrases that fail to meet the character-set requirements.
The available character sets are:
-
alphas: Passphrases must at least contain one lowercase character, and one uppercase character.
-
alphanums: Passphrases must at least contain one lowercase character, one uppercase character, one number, and 2 of the characters must be non-alphabetical.
-
alphanums+symbols: Passphrases must at least contain lowercase character, one uppercase character, one number, and one symbol (special character).
Passphrases can contain the following characters:
Numbers
0123456789
Uppercase characters
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Lowercase characters
abcdefghijklmnopqrstuvwxyz
Symbols
!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
Note that this setting does not enforce that all keys must have passphrases. To specify whether passphrases are mandatory for newly-generated keys, use the host setting Passphrase policy instead.
Also note that this setting only applies to passphrases set via Key Manager. Key Manager is unable to enforce passphrase policy when passphrases are changed manually.
Passphrase length
The minimum length of private-key passphrases (in number of characters).
Note that this setting does not enforce that all keys must have passphrases. To specify whether passphrases are mandatory for newly-generated keys, use the host setting Passphrase policy instead.
Passphrase policy
Defines the passphrase policy for newly generated private keys. The possible values are:
-
Mandatory: Newly generated private keys must be set with passphrases that complies to the other passphrase requirements. If no passphrase is specified, a random passphrase is set for the new private keys.
-
Optional: Newly generated keys can be set with a blank passphrase, or a passphrase that complies to the other passphrase requirements.
Passphrase requirements are defined by the host settings Passphrase length and Passphrase character set.
PATH environment variable
Colon-separated list of directories where common commands are located. Typically this corresponds to the PATH environment variable set for the host. Key Manager uses the PATH variable for locating and running host commands during management actions. If management jobs fail on a host because a command cannot be found, the problem may be fixed by adding the directory where the command is located to this setting.
Prefer su over sudo
When operating as root and performing commands with user privileges, use su even if sudo is
installed.
This option can be enabled to prevent issues on hosts where sudo is not available for some users. By
default, sudo is preferred since it is normally faster than su.
Preference order of client products for new keys
List of preferred client products. Any new keys are added to the first detected product on the list. Key Manager never adds new keys to any products omitted from the list.
Supported products in default order:
-
ssh-g3-client - Tectia SSH Client (generation 3)
-
ssh-g2-client - Tectia SSH Client (generation 2)
-
centrifydc-openssh-client - Centrify-OpenSSH Client
-
attachmate-rsit-client - Attachmate-RSIT Client
-
quest-openssh-client - Quest-OpenSSH Client
-
openssh-client - OpenSSH Client
-
connectsecure-ssh-g3-client - Tectia ConnectSecure SSH Client
-
sunssh-client - SunSSH Client
-
putty-client - PuTTY Client
Preference order of server products for new keys
List of preferred server products. Any new keys are added to the first detected product on the list. Key Manager never adds new keys to any products omitted from the list.
Supported products in default order:
-
ssh-g3-server - Tectia SSH Server (generation 3)
-
ssh-g2-server - Tectia SSH Server (generation 2)
-
centrifydc-openssh-server - Centrify-OpenSSH Server
-
attachmate-rsit-server - Attachmate-RSIT Server
-
quest-openssh-server - Quest-OpenSSH Server
-
openssh-server - OpenSSH Server
-
connectsecure-ssh-g3-server - Tectia ConnectSecure SSH Server
-
sunssh-server - SunSSH Server
Private key backup
When enabled, private keys, and the corresponding public-key files, deleted using Key Manager are automatically backed up.
Backup keys created by Key Manager are placed under the .ssh-mgr-backup directory, relative to
the path of the original key. Individual backup keys are named in the originalname_timestamp
format, where originalname is the original file name, and the timestamp represents when the backup
was taken.
Private key backup as superuser
When enabled, private-key and public-key backups created by Key Manager are owned by the
privileged user on the host (typically root). When disabled, these backups are owned by the same
user who owned the original key files.
Backup keys created by Key Manager are placed under the .ssh-mgr-backup directory, relative to
the path of the original key. Individual backup keys are named in the originalname_timestamp
format, where originalname is the original file name, and the timestamp represents when the backup
was taken.
Product metadata patch
Patch structure to apply to product metadata. Used for configuring Key Manager to detect non- standard SSH product installations on hosts. Examples of non-standard SSH product installations include SSH products installed using packages with custom names, and SSH products installed to custom file-system locations.
This setting can be used for specifying the following custom attributes, which allow Key Manager to correctly detect custom SSH product(s):
-
Specifying the paths of custom SSH software packages and/or binaries.
-
Specifying custom paths where SSH configurations can be found.
-
Specifying the commands for operating the custom SSH product (such as start, and stop).
This setting can be used to partly or fully override the default product-specific definitions. Incorrect configurations may prevent SSH products from being detected.
To obtain a product metadata patch for detecting the custom SSH products in your managed environment, contact SSH Communications Security Corporation support at https://support.ssh.com/.
Scan job priority
The priority with which Key Manager runs scan jobs. Smaller value means higher priority.
Key-activity scans are initiated with a lower (+2) priority. For example, if this setting is set to 10, then key-activity scans are given the priority of 12.
Scan user-specific OpenSSH client configurations
When enabled, IdentityFile locations specified in user-specific client configurations are also scanned
for private keys. Note that only OpenSSH-related (OpenSSH, SunSSH, Quest SSH) configurations
located at ~/.ssh/config are supported.
For more information about how this setting affects host scans, see Keys Detected by Key Manager.
Scan users without home directories (automounted, or on-demand provisioned)
Boolean setting defaulting to true. When set to false, Key Manager first checks whether the user's home directory is available. If there is no home directory, Key Manager will not switch to the user. This allows skipping users whose home directories are provisioned on-demand on the target-host local file system.
Typically automounter is configured so that even when this setting is set to false, all users are properly scanned. This setting is effectively always false for script-based scans (see Choosing the Best Scan Method).
Scan ~/.ssh directory
When enabled, all user-key files in the users' ~/.ssh directory are scanned, regardless of whether
they are specified in the SSH configuration of the host. Disabled by default. Note that enabling this
setting may adversely impact scan performance.
Statistics mode
When enabled, jobs generate internal-statistics information. Internal statistics may be requested by SSH Communications Security Corporation customer support for troubleshooting purposes. In most situations, this setting can be disabled.
Syslog file directories on host
A list of directories, the files of which are scanned for key-activity data. Only files in the listed directories may be scanned for key-activity data. The list must include all the directories containing syslog entries from SSH servers. Default:
["/var/log"]
For other settings that affect key-activity scans, see the host settings Authorized keys receiving activity, OS based syslog paths, Syslog file name patterns, Syslog content filter patterns for KA, and Syslog pre-filtering pattern.
Syslog file name patterns
List of file name patterns within locations specified by the setting Syslog file directories on host. Only the matching files are scanned for key-activity data. Entries must match the names of those files containing syslog entries from SSH servers. Default:
["auth.*","secure.*","messages.*","syslog*"]
For other settings that affect key-activity scans, see the host settings Authorized keys receiving activity, OS based syslog paths, Syslog file directories on host, Syslog content filter patterns for KA, and Syslog pre-filtering pattern.
Syslog content filter patterns for KA
JSON encoded dictionary describing the regular expressions used for parsing the syslog messages
and the application data. Keys for the dictionary must include the SSH server APP-NAMEs (those
defined in the setting Syslog pre-filter patterns), and the fixed key ground.
General format for the JSON dictionary is similar to the following:
{
"sshd": [...],
"sshd2": [...],
"ssh-server-g3": [...],
"BvServer": [...],
"SSH Tectia Server": [...],
"ground": [...],
}
The regular expression at ground must fetch the following backreference information from the syslog
message:
-
date: a time value that can be parsed either in typical syslog format
MON DAY HH:MM:SS, or as an ISO dateYYYY-MM-DD HH:MM:SS[.FRACTION][T]HH:MM -
loghost: The name of the host that produced the message.
-
app: The APP-NAME of the application that produced the message.
-
pid (Optional): The process identifier used for correlating multiple line entries. This may also be produced from the application-specific expression, and does not have to be numeric.
Within the regex entries, @PREFILTERS@ can be used to substitute for the value of the Syslog pre-filtering pattern setting.
Example ground entry:
"ground": ["(?P<date>(\\D+|\\d+)[-\\s/][-+/T.:\\s\\d]+(?=.*?@PREFILTERS@)) \
(?P<loghost>\\S+)\\s(?P<fac>\\S*)\\s*(?P<app>@PREFILTERS@)(\\[(?P<pid>\\d+)\\])?: \
(\\[(?P<log>.*)\\])?\\s*", \
"\\S+\t(?P<date>\\S+\\s+\\S+\\s+\\S+)\t(?P<app>.*?)\t\\d+\t\\S+\t"],
The regular expression for each application must fetch the following backreference information from the syslog message:
-
username: The target-user account name.
-
fingerprint: The fingerprint of the key used for successful login to the target user account.
-
hostname: The IP address or name of the key-activity source host.
-
pid (Optional): The process identifier.
Example application entry:
"sshd": ["(?P<result>(Failed|Accepted)) publickey for (?P<username>\\S+) from \
(?P<hostname>\\S+) port (?P<port>\\d+).*?: (?P<key_alg>\\S+) \
(?P<fingerprint>\\S+)", "Found matching (?P<key_alg>\\S+) key: \
(?P<fingerprint>\\S+)", "(?P<result>Accepted) (publickey|rsa) for \
(?P<username>\\S+) from (?P<hostname>\\S+) port (?P<port>\\d+).*"],
For more information about this setting, please contact SSH Communications Security Corporation support at https://support.ssh.com/.
For other settings that affect key-activity scans, see the host settings Authorized keys receiving activity, OS based syslog paths, Syslog file directories on host, Syslog file name patterns, and Syslog pre-filtering pattern.
Syslog pre-filtering pattern
A regular expression for capturing syslog entries generated by SSH server applications. Matching lines are scanned for key-activity data, non-matching lines are ignored to speed up scanning. This must match all the SSH server APP-NAMEs (syslog strings that indicate SSH servers as message originators) that are expected to be encountered on the hosts. Default:
(sshd2|sshd|ssh-server-g3|SSH Tectia Server|BvSshServer)
For other settings that affect key-activity scans, see the host settings Authorized keys receiving activity, OS based syslog paths, Syslog file directories on host, Syslog file name patterns, and Syslog content filter patterns for KA.
Temporary directory
The path to the temporary directory of the host. Key Manager uses this setting to locate the temporary directory, which is used for storing temporary information during some management actions.
Timezone
The time zone of the host in TZ notation. This setting is only required for hosts where Key Manager is unable to automatically detect the time zone. When set, this setting overwrites the time zone detected on the host.
Key Manager is able to automatically detect the time zone of most hosts. Note that on AIX, HP-UX
and z/OS hosts the TZ environment variable must be set for automatic detection to work.
Key Manager automatically detects the time zone of a host during the initial host scan. The host time zone detected and reported by Key Manager is always functionally equivalent to the actual time zone of the host, though the name of the time zone may differ. For example, Key Manager may detect hosts in the Europe/Helsinki time zone to be in Europe/Mariehamn time.
Unique ID file path
The path where Key Manager stores the unique ID file.
This setting only determines the path where Key Manager checks or writes the Unique ID file to. Changing this setting does not automatically relocate the unique ID file on hosts that have already been deployed. If a host is re-deployed after the unique ID file path is changed, the host may be assigned a different ID value.
Use allow-from options in management keys
When checked, all subsequently created and renewed management keys are set with allow-from options. The allow-from options only permit access from addresses belonging to Key Manager back ends, and from the addresses specified in the Additional allow-from addresses.
For more information about this allow-from options in management keys, see Setting Allow-From Options to Management Keys.
After this option is enabled, management keys need to be renewed after adding new Key Manager back ends to the system. Otherwise said back ends cannot connect to agentless hosts.
Use exit value optimization
When executing shell commands on a host, send the command to return the exit value along with the main command. This is faster but in certain execution environments may result in the exit value being lost and connection to timeout. In this case, disable the optimization. Note that disabling the optimization will result in longer scan times for shell-based scans.
Update host script automatically as needed
Allow Key Manager to upload a more recent version of the host script to the host where the job will be executed as needed.
Note the following details related to the functioning of this setting:
-
On the target host, modifications to the host-utility-script file (such as upload and update) are performed using the basic privileges of the management account.
-
If the management account is non-privileged, host utility is run using the elevated permissions of the management account. The elevated permissions are acquired using permissions whatever privilege-elevation software that is configured for the management account (such as sudo or Powerbroker).
Due to these reasons the target path and its parent directory must be writable by the management user using their basic privileges. Furthermore, in situations where the management user is a regular user with sudo privileges, the user's elevated permissions must allow execution of the host utility.
User-listing command on Unix and Linux hosts
The command used for listing users on Unix hosts. Defaults to getent passwd.
The output of this command must be in the same format as the output returned by the command
getent passwd.
This command is run under as-is on the hosts in the managed environment and may result in data loss if configured incorrectly.