Key Manager Alerts

This section describes the Key Manager alerts.

Key Alerts (100 - 199)

Unmanaged authorized key found

ID

100

Description

This alert is raised when an authorized key (excluding keys added using Key Manager) is newly discovered on a host in the managed state.

This alert may be caused by authorized keys that were manually added to a managed host. As such, there is the possibility that these keys were set up without approval, to grant access for unauthorized people or machines. This alert may also be raised by authorized keys located on file systems that were inaccessible when the host was in the monitored state.

How to resolve the alert

If you believe that the alert was caused by a key that was simply inaccessible during a host scan, you may dismiss the alert. Otherwise, review the key associated to the alert. If you can verify that the target key enables an authorization that is approved by your corporation, then you should Approve the key via Key Manager. Otherwise, you should use Key Manager to blacklist or remove the key in order to prevent unauthorized access.

Log-message example

Apr 14 15:14:52 kmserver sshmgr-worker[8686] WARNING: <host.example.com> ALERT: (100) Unmanaged authorized key found, Host: host.example.com, Key ID: 210, Path: /opt/sshkeys/auth/alice/authorized_keys, Type: ssh-rsa 2048, Fingerprint OpenSSH: fa:b2:8d:85:6f:a4:41:5a:e2:7c:27:b8:b5:fc:90:4e

Unmanaged private key found

ID

101

Description

This alert is raised when a private key (excluding keys added using Key Manager) is newly discovered on a host in the managed state.

This alert may be caused by private keys that were manually added to a managed host. As such, there is the possibility that these keys were set up without approval, to grant access for unauthorized people or machines. This alert may also be raised by private keys located on file systems that were inaccessible when the host was in the monitored state.

How to resolve the alert

If you believe that the alert was caused by a key that was simply inaccessible during a host scan, you may dismiss the alert. Otherwise, review the key associated to the alert. If you can verify that the target key enables an authorization that is approved by your corporation, then you should Approve the key via Key Manager. Otherwise, you should use Key Manager to blacklist or remove the key in order to prevent unauthorized access.

Log-message example

Apr 8 17:02:16 kmserver sshmgr-worker[2343] WARNING: <host.example.com> ALERT: (101) Unmanaged private key found, Host: host.example.com, Key ID: 32, Path: /home/alice/.ssh/id_dsa, Type: ssh-dss 1024, Fingerprint OpenSSH: 65:c1:8d:f4:e7:e4:fc:0d:32:9a:d8:05:4a:b8:94:7f

Managed authorized key lost

ID

102

Description

A managed authorized key (authorized key in the managed state) no longer exists in its intended file location. As a result, the authorizations enabled by this key will most likely not work. The target key file may have been moved or deleted manually. Alternatively, the file system where the target key is located may have been inaccessible during the host scan.

How to resolve the alert

You can use Key Manager to restore missing and deleted authorized keys.

Log-message example

Apr 14 14:22:12 kmserver sshmgr-worker[6799] WARNING: <host.example.com> ALERT: (102) Managed authorized key lost, Host: host.example.com, Key ID: 199, Path: /home/alice/.ssh/authorized_keys, Type: ssh-rsa 2048, Fingerprint OpenSSH: 3b:54:b5:0d:ba:43:c4:fa:c0:c1:8f:5b:98:01:04:88

Managed private key lost

ID

103

Description

A managed private key (private key in the managed state) no longer exists in its intended file location. As a result, the authorizations enabled by this key will most likely not work. The target key file may have been moved or deleted manually. Alternatively, the file system where the target key is located may have been inaccessible during the host scan.

How to resolve the alert

Private keys are not stored by Key Manager, and cannot be directly restored. To re-enable the authorizations associated to the missing private key, you can renew the authorization using Key Manager. Renewing an authorization regenerates all the keys associated to it, and re-enables the selected authorizations.

Log-message example

Apr 14 15:40:04 kmserver sshmgr-worker[9245] WARNING: <host.example.com> ALERT: (103) Managed private key lost, Host: host.example.com, Key ID: 11, Path: /opt/sshkeys/priv/alice/identity, Type: ssh-rsa 2048, Fingerprint OpenSSH: 3b:54:b5:0d:ba:43:c4:fa:c0:c8:8f:5b:98:01:04:84

Legacy authorized key found

ID

104

Description

This alert is raised when an authorized key is newly discovered on a host in the monitored state, after the host has undergone initial host discovery.

This alert may be raised by authorized keys located on file systems that were not accessible during initial host discovery. This alert may also be caused by authorized keys that were manually added to a monitored host. As such, there is the possibility that these keys were set up without approval to grant access for unauthorized people or machines.

How to resolve the alert

If you believe that the alert was caused by a key that was simply inaccessible during initial host discovery, you may dismiss the alert. Otherwise, review the key associated to the alert. If you can verify that the target key enables an authorization that is approved by your corporation, then you should Manage the key (switch the state of the key to managed) via Key Manager, to indicate that the key is managed. Otherwise, you should use Key Manager to blacklist or remove the key in order to prevent unauthorized access. Note that the host must be in the managed state before you can perform actions on its keys.

Log-message example

Apr 15 14:24:53 kmserver sshmgr-worker[8086] WARNING: <host.example.com> ALERT: (104) Legacy authorized key found, Host: host.example.com, Key ID: 227, Path: /home/alice/.ssh/authorized_keys, Type: ssh-rsa 2048, Fingerprint OpenSSH: b6:b2:e5:0d:61:86:bf:d7:88:4a:3b:92:fc:f0:88:f0

Legacy private key found

ID

105

Description

This alert is raised when a private key is newly discovered on a host in the monitored state, after the host has undergone initial host discovery.

This alert may be raised by private keys located on file systems that were not accessible during initial host discovery. This alert may also be caused by private keys that were manually added to a monitored host. As such, there is the possibility that these keys were set up without approval to grant access for unauthorized people or machines.

How to resolve the alert

If you believe that the alert was caused by a key that was simply inaccessible during initial host discovery, you may dismiss the alert. Otherwise, review the key associated to the alert. If you can verify that the target key enables an authorization that is approved by your corporation, then you should Manage the key (switch the state of the key to managed) via Key Manager, to indicate that the key is managed. Otherwise, you should use Key Manager to blacklist or remove the key in order to prevent unauthorized access. Note that the host must be in the managed state before you can perform actions on its keys.

Log-message example

Apr 15 14:24:53 kmserver sshmgr-worker[8086] WARNING: <host.example.com> ALERT: (105) Legacy private key found, Host: host.example.com, Key ID: 48, Path: /home/alice/.ssh/id_rsa, Type: ssh-rsa 2048, Fingerprint OpenSSH: b6:b2:e5:0d:61:86:bf:d7:88:4a:3b:92:fc:f0:88:f0

Legacy authorized key lost

ID

106

Description

A legacy authorized key (authorized key in the legacy state) no longer exists in its intended file location. As a result, the authorizations enabled by this key will most likely not work. The target key file may have been moved or deleted manually. Alternatively, the file system where the target key is located may have been inaccessible during the host scan.

How to resolve the alert

Ensure that the filesystem where the key is located is available, then scan the host again. If the key is still reported as missing, you can assume that the key has been moved or deleted. You can use Key Manager to restore missing and deleted authorized keys.

Log-message example

Apr 24 17:50:28 kmserver sshmgr-worker[24984] WARNING: <host.example.com> ALERT: (106) Legacy authorized key lost, Host: host.example.com, Key ID: 226, Path: /opt/user_keys/auth/root/authorized_keys, Type: ssh-rsa 2048, Fingerprint OpenSSH: fc:10:f3:c4:a3:6b:a9:3a:0b:46:ec:df:41:8c:5a:1f

Legacy private key lost

ID

107

Description

A legacy private key (private key in the legacy state) no longer exists in its intended file location. As a result, the authorizations enabled by this key will most likely not work. The target key file may have been moved or deleted manually. Alternatively, the file system where the target key is located may have been inaccessible during the host scan.

How to resolve the alert

Private keys are not stored by Key Manager, and cannot be directly restored. To re-enable the authorizations associated to the missing private key, you can renew the authorization using Key Manager. Renewing an authorization regenerates all the keys associated to it, and re-enables the selected authorizations.

Log-message example

Apr 22 13:48:08 kmserver sshmgr-worker[9526] WARNING: <host.example.com> ALERT: (107) Legacy private key lost, Host: host.example.com, Key ID: 45, Path: /home/alice/.ssh/id_dsa, Type: ssh-dss 1024, Fingerprint OpenSSH: 27:0a:44:0f:62:6d:bb:4c:c6:6d:a1:ff:b4:22:9c:eb

Private key renewal failed

ID

108

Description

A private-key renewal job has failed due to Key Manager being unable to generate a new private key on a host.

For generating new keys, Key Manager uses the SSH software (ssh-keygen or equivalent) that is available on the host. Therefore, this alert may be caused by Key Manager being unable to use such software. Particularly on hosts managed using sudo permissions, this may be caused by Key Manager not having the necessary permissions to run the key-generation commands. The alert may also be generated if the SSH software on the host has changed recently.

How to resolve the alert

Update the information about SSH software by using Key Manager to scan the host where the target key is located. Also ensure that the management account on the host is able to run ssh- keygen, and that the management account is able to modify files in the directory where the target key is located. After that, try running key renewal again.

Log-message example

Apr 15 16:03:47 kmserver sshmgr-worker[12676] WARNING: <host.example.com> ALERT: (108) Private key renew failed, Host: host.example.com, Key ID: 13, Path: /home/user/.ssh/identity, Type: ssh-rsa 2048, Fingerprint OpenSSH: 5a:cb:98:79:63:87:ea:07:1d:78:94:6c:11:83:a4:d2

Authorization changed locally

ID

109

Description

The authorized-key options of an authorized key have been changed manually. Changes to authorized-key options can significantly change the behavior of the authorization. For example, the authorization may become usable from different network locations, and the authorization may allow different actions to be performed by those who use the authorization.

How to resolve the alert

Review the alert details to determine how the authorized-key options were modified. You can use Key Manager to set the desired authorized-key options for the authorized key. The Key Manager GUI provides functionality to set commonly supported authorized-key options. The Key Manager command-line client can be used to set any authorized-key options.

Changes to authorized-key options are reported in the details of the alert event. The changes are reported in the following format:

{option_name: [former_options, new_options], option_name2: [old_options2, new_options2], ...}

For example, an example key had the following authorized-key options:

• allow-from : 192.0.2.*
• deny-from : 192.168.1.*
• command : echo "Hello!"

If the address range 192.168.3.* is added to the allow-from options, and the deny-from and the command options were entirely removed, the resulting alert would report the changes as:

Authorized key options changed: {u'command': [[u'echo "Hello!"'], None], u'allow-from': [[u'192.0.2.*'], [u'192.0.2.*', u'192.168.3.*']], u'deny- from': [[u'192.168.1.*'], None]}

Log-message example

Apr 16 13:56:49 kmserver sshmgr-worker[13082] WARNING: <host.example.com> ALERT: Authorized key options changed: {u'command': [[u'echo "Hello!"'], None], u'allow-from': [[u'192.0.2.*'], None], u'deny-from': [[u'192.168.1.*'], None]}

Authorization with blacklisted public key detected

ID

110

Description

A copy of a blacklisted authorized key has been discovered on a host.

How to resolve the alert

Keys are blacklisted when they are suspected to be compromised, or otherwise intended to be permanently decommissioned. You should use Key Manager to remove blacklisted keys as soon as possible. We highly recommend that you investigate the reasons for the appearance of such keys.

Log-message example

Apr 16 16:39:31 kmserver sshmgr-worker[5713] WARNING: <host.example.com> ALERT: (110) Authorization with blacklisted public key detected, Host: host.example.com, Key ID: None, Path: / root/.ssh/authorized_keys, Type: ssh-dss 1024, Fingerprint OpenSSH: 32:d9:0e:06:e5:57:96:17:bc:d2:ff:b5:49:8e:bf:14

Blacklisted private key detected

ID

111

Description

A copy of a blacklisted private key has been discovered on a host.

How to resolve the alert

Keys are blacklisted when they are suspected to be compromised, or otherwise intended to be permanently decommissioned. You should use Key Manager to remove blacklisted keys as soon as possible. We highly recommend that you investigate the reasons for the appearance of such keys.

Log-message example

Apr 16 16:36:17 kmserver sshmgr-worker[5598] WARNING: <host.example.com> ALERT: (111) Blacklisted private key detected, Host: host.example.com, Key ID: None, Path: /root/.ssh/id_dsa, Type: ssh-dss 1024, Fingerprint OpenSSH: 32:d9:0e:06:e5:57:96:17:bc:d2:ff:b5:49:8e:bf:14

Bad authorized key option detected

ID

112

Description

An authorized key has an illegal authorized-key option.

How to resolve the alert

Review the alert details to determine the affected authorized key, and its illegal authorized-key option. You can use Key Manager to set the desired authorized-key options for the authorized key.

Log-message example

Aug 14 16:53:28 kmserver sshmgr-worker[5788] WARNING: <host.example.com> ALERT: (112) Bad authorized key options detected, Host: host.example.com, Key ID: 352, Path: /opt/user_keys/auth/alice/ authorized_keys, Type: ssh-dss 1024, Fingerprint OpenSSH: 9d:c3:d7:06:a7:4a:4c:a4:bc:f6:04:32:84:15:9f:c9, Message: Invalid key options in file '/opt/user_keys/auth/alice/authorized_keys' line 1: 'from="10.1.54.67,192.0.2.83,fd00:10:1:55:a00:27ff:fe37:9d53,fe80::a00:27ff:...': Unquoted command option ls

Authorized key from stanza changed locally

ID

113

Description

The authorized-key options of an authorized key have changed to allow or disallow access from different network addresses. Furthermore, this change was done without using Key Manager, which may mean that the change was done manually.

How to resolve the alert

Review the alert details to determine what addresses were allowed or disallowed by the change. You should also investigate the causes of this change. You can use Key Manager to modify the allowed and disallowed addresses if necessary.

Log-message examples

Aug 21 16:46:33 kmserver sshmgr-worker[6124] WARNING: <server.example.com> ALERT: (113) Authorized key from stanza changed locally, Host: server.example.com, Key Id: 352, Path: /opt/user_keys/auth/ alice/authorized_keys, Type: ssh-dss 1024, Fingerprint OpenSSH: 9d:c3:d7:06:a7:4a:4c:a4:bc:f6:04:32:4b:15:98:c9, Message: From stanza changed, Old value: allow-from="server100.example.com", New value: allow- from="server100.example.com",allow-from="server101.example.com"

Aug 21 16:46:33 kmserver sshmgr-worker[6124] WARNING: <server.example.com> ALERT: (113) Authorized key from stanza changed locally, Host: server.example.com, Key Id: 353, Path: /opt/user_keys/auth/ alice/authorized_keys, Type: ssh-dss 1024, Fingerprint OpenSSH: 8d:f5:aa:d5:e6:c0:b4:17:7a:0f:94:fe:a0:85:74:ce, Message: From stanza removed, Old value: allow-from="server100.example.com"

Aug 21 16:46:33 kmserver sshmgr-worker[6124] WARNING: <server.example.com> ALERT: (113) Authorized key from stanza changed locally, Host: server.example.com, Key Id: 354, Path: /opt/user_keys/auth/ alice/authorized_keys, Type: ssh-dss 1024, Fingerprint OpenSSH: 93:05:a9:66:e9:e6:c2:a3:e9:a9:58:f8:59:a4:c2:44, Message: From stanza set, Value: allow-from="server100.example.com"

Private key passphrase change detected

ID

114

Description

The passphrase of a private key has been changed manually, without using Key Manager. This alert is raised during full scans if Key Manager detects that the passphrase of a private key has unexpectedly changed since the last scan.

How to resolve the alert

Review the alert details to determine which keys were affected. If the passphrase changes were unauthorized, you should immediately set a new passphrase for them. You can set new passphprases for keys by renewing them via Key Manager. Alternatively, if the passphrase changes are expected, and if you know the new passprhases, you should update the passphrases stored in Key Manager.

note

In order for Key Manager to correctly detect passphrase changes, the public-key (.pub) files must be located in the same directory as the corresponding private-key files. In situations where the .pub file cannot be found, changes to private-key passphrases may be incorrectly detected a new private-key entries instead.

Log-message example

Nov 23 15:18:19 kmserver sshmgr-worker[6124] WARNING: <server.example.com> ALERT: (114) Private key passphrase change detected, Host: server01.example.com, Key Id: 27, Path: /opt/sshkeys/priv/alice/ id_rsa, Type: ssh-rsa 2048, Format: openssh, Fingerprint OpenSSH: 10:bd:0b:b7:11:a6:22:aa:ac:09:c0:f6:62:df:4b:bd, Fingerprint SSH1: fd:d3:b2:3a:62:b0:51:da:b8:94:51:20:f0:86:7c:59, Message: Private key passhrase was set

Authorized key comment changed locally

ID

115

Description

The comment of an authorized key has been changed manually, without using Key Manager.

Comments have no impact on user-key functionality. Comments are used purely for describing keys.

How to resolve the alert

You may review the alert details to determine which keys were affected. The alert details provide both the old and the new comment value.

Key Manager cannot be used for modifying key comments. Corrections to key comments need to be performed manually.

Log-message example

Oct 12 13:36:32 kmserver sshmgr-worker[30280] WARNING: <server.example.com> ALERT: (115) Authorized key comment changed locally, Host: Host #27 server.example.com, Key Id: 5992, Path: / home/alice/.ssh/authorized_keys, Type: ssh-rsa 2048, Fingerprint OpenSSH: 3b:fe:bd:d8:f6:79:4d:34:9d:80:76:f8:78:37:17:9d, Message: Key comment changed, Old value: ssh-mgr authorized key from alicemargatroid@bilberry.example.com [2017-10-06 12:15:47 UTC], New value: Kilroy was here

Appeared authorized key lost

ID

116

Description

An authorized key added using unknown means has since been removed. This alert is raised in the following event:

1. A Key Manager scan detects a new key that was added using unknown means (Key Manager sets the key status as appeared).

2. On a subsequent scan, Key Manager no longer detects the key.

   This alert may indicate that somebody set up unauthorized access to the managed environment, and later removed the key in an attempt to avoid detection. Alternatively, this alert may also be caused by keys on filesystems that are not always available.

How to resolve the alert

Review the alert details to determine the involved key(s). You may review any associated key- activity entries for more information about where the key was used from and when. Associated key-activity entries can be found by filtering key-activity logs by the fingerprint of the involved key(s).

Log-message example

Oct 12 11:29:35 kmserver sshmgr[28389] WARNING: ALERT: (116) Appeared authorized key lost, Host: Host #27 server.example.com, Key Id: 5998, Path: / root/.ssh/authorized_keys, Type: ssh-rsa 3072, Format: openssh, Fingerprint OpenSSH: 97:ee:2d:cb:87:3d:df:b1:1f:af:31:7b:e3:47:61:09, Fingerprint SSH1: 42:8a:a7:6c:35:4a:09:51:be:b8:48:f3:f0:ba:15:09, Message: None

Appeared private key lost

ID

117

Description

A private key added using unknown means has since been removed. This alert is raised in the following event:

1. A Key Manager scan detects a new key that was added using unknown means (Key Manager sets the key status as appeared).

2. On a subsequent scan, Key Manager no longer detects the key.

This alert may indicate that somebody set up unauthorized access from the managed environment, and later removed the key(s) in an attempt to avoid detection. Alternatively, this alert may also be caused by keys located on filesystems that are not always available.

How to resolve the alert

Review the alert details to determine the involved key(s). You may review any associated key- activity entries for more information about where the key was used from and when. Associated key-activity entries can be found by filtering key-activity logs by the fingerprint of the involved key(s).

Log-message example

Oct 12 11:29:35 kmserver sshmgr[28389] WARNING: ALERT: (117) Appeared private key lost, Host: Host #27 server.example.com, Key Id: 164, Path: / home/bob/.ssh/id_rsa, Type: ssh-rsa 3072, Format: openssh, Fingerprint OpenSSH: 97:ee:2d:cb:87:3d:df:b1:1f:af:31:7b:e3:47:61:09, Fingerprint SSH1: 42:8a:a7:6c:35:4a:09:51:be:b8:48:f3:f0:ba:15:09, Message: None

Host Alerts (200 - 299)

Job failed

ID

200

Description

A job has failed on a host.

Key Manager performs management operations on hosts via jobs. Job failures mean that certain management actions are not performed successfully.

How to resolve the alert

Review the alert details for an overview of the failure. Also review the job log of the failed job to determine the issues that may have caused the failure. When reviewing the job log, you should enable more verbosity to display all the details recorded of that job. After you have fixed the issues, try running the job again.

Log-message example

Apr 16 15:33:02 kmserver sshmgr-worker[14116] WARNING: <host.example.com> ALERT: Job scan-full #30466 failed for host.example.com with 'getting_user_public_keys'

Host key has changed

ID

201

Description

This alert is raised when the host key of a host changes. The host key may change when SSH software is installed, reinstalled, or replaced on a host. Sometimes, the host key may have been deliberately changed by the administrator of the host. In other cases, it is also possible that somebody is eavesdropping on the management connection (man-in-the-middle attack).

How to resolve the alert

Determine what has caused the host key to change. If the host key has been changed by an authorized system administrator, or if the SSH software on the host has been changed on the host, this alert may be dismissed. If none of the previously-described actions have caused the hostkey change, you should investigate the possibility of man-in-the-middle attacks. If you suspect that somebody is performing a man-in-the-middle attack, switch the host to the suspended state via Key Manager, to prevent any management connections to the host. Once the cause has been resolved, you can switch the host to the monitored (and/or managed) state to resume management operations.

Log-message example

Mar 12 15:24:39 kmserver sshmgr-worker[12009] WARNING: <host.example.com> ALERT: Host key of host.example.com (#8) has changed! Monitored configuration was locally modified

Monitored configuration was locally modified

ID

202

Description

The configuration of an SSH product on a host has been manually modified. Such changes will most likely change the behavior of the SSH product. For example, changes in configuration may allow or disallow authentication using certain authentication methods, or allow/disallow authentication using SSH keys in different file locations.

How to resolve the alert

Review the alert to determine what configuration was modified. You can then use Key Manager to review the target configuration file, and to replace the modified configuration by assigning and deploying one of your approved configurations to the host where the SSH product is located. When assigning and deploying configurations, note that both the host and the configuration must be in the managed state.

Log-message example

Apr 17 13:50:57 kmserver sshmgr-worker[22713] WARNING: <host.example.com> ALERT: Monitored configuration (#33) of openssh-server on (#13) has changed: No diff

Managed configuration was locally modified

ID

203

Description

The configuration of an SSH product on a host has been manually modified. Such changes will most likely change the behavior of the SSH product. For example, changes in configuration may allow or disallow authentication using certain authentication methods, or allow/disallow authentication using SSH keys in different file locations.

How to resolve the alert

Review the alert to determine what configuration was modified. You can then use Key Manager to review the target configuration file, and to replace the modified configuration by assigning and deploying one of your approved configurations to the host where the SSH product is located.

Log-message example

Apr 2 13:47:29 stormberry sshmgr-worker[4335] WARNING: <bilberry.example.com> ALERT: Managed configuration (#26) of openssh-server on (#2) has changed: No diff

A (potential) gap in key activity scan data found

ID

204

Description

This alert is raised when Key Manager suspects a gap in key-activity logs. Key-activity gaps can be caused when key-activity logs on the hosts in the managed environment are rotated to unknown locations before they are scanned.

How to resolve the alert

You can use the key-activity-import tool to import potentially undetected key-activity data. To do this, you will also need the SSH server logs of the target host from the time span specified in the alert. For instructions about using the key-activity-import tool, see Importing Key-Activity Information Manually.

Log-message example

Apr 17 16:25:41 kmserver sshmgr-worker[28945] WARNING: <host.example.com> ALERT: Key activity scan data from 2014-04-17T16:22:41+03:00 2014-04-17T16:25:06+03:00 (0:02:25) possibly missing!

Unknown key activities found

ID

205

Description

This alert occurs when Key Manager detects key activity for authorized key that is not known in Key Manager. Typically such situation occurs if Key Manager is not used solely for managing authorizations, and there is a long gap between authorized keys scan, and the key activity scan, and the following event sequence occurs:

1. AK scan
2. Add user, and authorizations
3. User login using the keys
4. KA scan performed.

The alert is not raised during the first key activity scan as the log files may contain activities for potentially large number of keys no longer present at the monitored host. The unknown activities encountered during the first key activity scan are visible on the Job log, if agentless, or agent-based scanning is used. Subsequent key activity scans will raise the alert for logins addressing unknown keys.

On hosts that have been part of the managed environment for a longer time, this may indicate that an authorization was created manually, used to gain access to the monitored target host, then removed before a host scan has managed to discover the key. Therefore, there is a possibility that somebody has gained unauthorized access to the host, or at minimum keys at the host are being modified locally, outside of the Key Manager.

How to resolve the alert

You should review the key activity entries associated to the alert to determine details about the unknown key activities, such as what hosts and counts were accessed, where they were accessed from, and when they were accessed.

Log-message example

Apr 15 14:24:40 kmserver sshmgr-worker[2663] WARNING: <host.example.com> ALERT: Found 1 new key activity entry with 1 unknown fingerprint: to user root fingerprint e7:e8:ca:1a:17:83:b9:2c:e2:56:7e:ca:cd:a2:30:ff from 10.10.10.10

Failed to scan user keys

ID

206

Description

Key Manager is unable to scan the user keys belonging to certain users.

Key Manager scans for user keys by reading user-key files as their owning user. This alert may be raised when Key Manager is unable to switch to a user. On hosts without su or sudo installed, user-key scans fail for users with invalid or restricted shells. This alert may also be raised when a host command times out when scanning the user keys of a particular user. A host-command timeout may be caused by a command returning an unexpected prompt, or by unstable network connectivity to the host.

How to resolve the alert

Check the host-scan job log for more details about why user-key scans are failing. On the host where user-key scans are failing, verify that the management-account user is able to use su or sudo. If user-key scans are failing persistently due to host-command-timeout issues, contact the SSH Communications Security Corporation support for possible solutions to the problem.

Log-message example

Apr 22 17:14:12 kmserver sshmgr-worker[6243] WARNING: <host.example.com> ALERT: Failed to scan user keys: [u'user2', u'user4', u'user8', u'user19'

Incomplete key activities found

ID

207

Description

One or more incomplete key-activity entries have been detected on a host.

With certain configurations, OpenSSH servers may generate incomplete SSH1 key-activity entries, such as entries with missing key fingerprints. 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.

If a host has at any point in time met all of these conditions, it is possible that the OpenSSH has recorded incomplete key-activity entries as a result. Key Manager raises an alert when such entries are discovered.

How to resolve the alert

Review the alert details for a complete list of incomplete key-activity entries. If possible, you should verify that the incomplete key-activity entries correspond to approved connections. To this end, Key Manager can be used, for example, for listing known authorizations by fingerprint or source/destination addresses.

Log-message example

Aug 21 09:39:31 kmserver sshmgr-worker[29394] WARNING: <server.ukm.ssh.com> ALERT: Incomplete log messages found in key activity logs.#012Accepted authentications with no fingerprints logged:#012Jul 21 18:18:19 server sshd[30070]: Accepted rsa for sshmgr from 192.0.2.100 port 37573#012Jul 21 18:12:25 server sshd[29790]: Accepted rsa for sshmgr from 192.0.2.100 port 58220#012Jul 21 18:11:35 server sshd[29714]: Accepted rsa for sshmgr from 192.0.2.101 port 58219

Host timezone not detected

ID

208

Description

Key Manager was unable to scan user keys for one or more users. This may occur if the user account cannot be accessed, if required privileges are missing, or if the user shell is restricted.

How to resolve the alert

You can configure Key Manager to use a specific time zone for managing this host. To do this, set the Timezone setting for this host. For instructions about setting host-specific settings, see Configuring Settings for Individual Hosts.

Log-message example

Nov 27 17:14:12 kmserver sshmgr-worker[6243] WARNING: <host.example.com> ALERT: Timezone was not detected on host host.example.com (#3097). Configure host timezone in host settings.

Unsupported configuration entries detected

ID

209

Description

Key Manager has detected unsupported entries in the SSH configuration of a host. This alert is commonly displayed when a Bitvise SSH host possesses user keys belonging to virtual user accounts, groups, or Windows groups, of which Key Manager is unable to gather comprehensive information.

How to resolve the alert

The purpose of this alert is to inform that a host contains some entries that Key Manager is unable to manage. You can get more information about the unsupported entries from the alert details. Ensure that the listed entries do not constitute security threats to your host environment, then resolve the alert. Note that unsupported entries generate an alert each time the host is scanned. Recurring alerts of this type may be dismissed.

Log-message example

Nov 27 17:14:12 kmserver sshmgr-worker[6243] WARNING: <host.example.com> ALERT: Configuration has entries that Key Manager does not support: winGroups contains keys in Bitvise SSH Configuration, virtGroups contains keys in Bitvise SSH Configuration

Ambiguous authorizations detected

ID

210

Description

This alert is raised when Key Manager detects active Tectia authorized keys that are present in both the Tectia authorization file and the Tectia authorized-keys directory. In other words, this alert is raised when Key Manager detects the following condition on a host:

• A user's Tectia authorization file refers to a public-key file that is located in the Tectia authorized-keys directory. Furthermore, the authorization file specifies non-empty options for the key.

• The Tectia SSH Server on the host allows authentication using a Tectia authorizations file. The Tectia SSH Server also allows authentication using keys from the Tectia authorized-keys directory.

In such situations the user is able to log in using key as if no authorized-key options were set for the key, bypassing any restrictions such as allow-from options and/or command options.

How to resolve the alert

Move the target key out of the Tectia authorized-keys directory. This ensures that the authorized- key options specified in the Tectia authorization file are respected.

By default the user-specific authorized-keys directory is located at the following path on Unix hosts:

~/.ssh2/authorized_keys

And on Windows:

%APPDATA%\SSH\UserKeys

Note that on Unix, the default convention is to store Tectia public-key files immediately under the ~/.ssh2/ directory, and not under the ~/.ssh2/authorized_keys directory.

Log-message example

Aug 26 16:41:36 kmserver sshmgr-worker[11689] WARNING: <server01.example.com> ALERT: Ambiguous authorizations to alice@server01.example.com found: key location - '/home/alice/.ssh2/authorized_keys/id_rsa.pub' : auth. origins - ['authorized-keys-directory', '/home/alice/.ssh2/authorization']

Host deployment denied

ID

211

Description

Host redeployment was attempted on a host that was not explicitly prepared for redeployment. Redeployment was denied to prevent accidental or malicious reuse of host entries.

This alert is also generated when you attempt to add a host that was already added to the managed environment.

How to resolve this alert

This alert may be raised when something is trying to impersonate the target host. Therefore you should carefully determine whether the host-redeployment attempt was legitimate.

To legitimately redeploy a host, the target host must first be marked for redeployment. To do this, perform a Redeploy action on the host. Subsequently deploying the host will not generate this alert. For more information about host redeployment, see Host-Group Management.

If this alert was generated on an arbitrary host after an attempt to add a new host to the managed environment, this alert may have been caused by the new host having the same unique ID as another host already in the managed environment. Before you can successfully add the new host to the managed environment you will have to remove its unique-ID file (Unix hosts) or unique- ID registry entry (Windows hosts).

Log-message example

Aug 26 16:28:03 kmserver sshmgr-worker[10657] WARNING: <internal> ALERT: Host server02.example.com (#2) was not marked for redeployment (set to management state 'available') when server02.example.com from 192.0.2.102 with clashing unique id N2EOENElui95XAqyw3BRWr1BEwb493f9sQprGTva attempted deployment

Host redeployed alert

ID

212

Description

The target host has been successfully redeployed.

How to resolve this alert

If the alert was raised as the result of a legitimate redeployment procedure, this alert can be resolved or dismissed. Otherwise, something on the network may be attempting to impersonate the target host, and the incident should be investigated.

Log-message example

Aug 26 16:32:15 kmserver sshmgr-worker[10912] WARNING: <internal> ALERT: Host server02.example.com (#2) was marked for redeployment (set to management state 'available') and now redeployed as server02.example.com from 192.0.2.102 with the existing unique id N2EOENElui95XAqyw3BRWr1BEwb493f9sQprGTva

Unsupported product versions found

####ID 213

Description

During host deployment, Key Manager detected unsupported SSH products installed on the host.

How to resolve the alert

Review the alert details to determine the SSH products that are not supported by Key Manager. Note that Key Manager may not be able to correctly perform actions on SSH configurations and SSH keys belonging to unsupported SSH products. For a complete list of supported SSH products, see the PrivX Key Manager Installation Manuals.

Non-standard installations of actually-supported SSH products, such as installations performed to non-standard paths and/or with installation packages using custom names, may also raise this error. If this error is raised by an SSH product that should be supported by Key Manager, you can prevent future occurences of this error by adjusting the product-metadata settings for the host.

Log-message example

Aug 26 17:31:42 kmserver sshmgr-worker[14785] WARNING: <internal> ALERT: Host has unsupported product versions: ssh-g3-server: 5.2.3 on Linux CentOS release 6.7 (Final) rejected

Found key activities were skipped

ID

214

Description

This alert occurs when Key Manager detects key activity which it cannot process for some reason. The alert text indicates the more specific reason.

How to resolve the alert

Source host IP not resolved: Typical reason might be that instead of having an IP address of the source host on the system, the target encodes a DNS name that does not forward resolve into an IP address in Key Manager. Corrective actions may involve arranging similar name services for Key Manager that are available on the monitored hosts. Additional information describes how many distinct source addresses were not resolved during the scan.

Log-message example

Mar 13 09:59:43 kmserver sshmgr-worker[14791] WARNING: <internal> ALERT: Skipped key activities from 2 sources: Source host IP not resolved. Sample: server01.example.com, server02.example.com.

Host executor not available for the host

ID

215

Description

This alert is raised on hosts where a script-based scan fails for any reason. In such situations Key Manager falls back to scanning the host using regular agentless behavior, and raises this alert.

This alert is also raised if the host-executor service is not running, or if the host-executor service is unable to contact Key Manager front ends.

How to resolve the alert

Review the alert to determine the target host and other additional information. Also review the logs from any jobs associated to this alert.

To determine whether the alert was caused by inactive host-executor services, check the host- executor-service status on your Key Manager back ends:

# supervisorctl status backend:host-executor

Start the services if necessary:

# supervisorctl start backend:host-executor

Also ensure that your Key Manager back ends are able to connect to your Key Manager front ends. Note that Key Manager Servers communicate over TLS-protected connections, and therefore require valid certificate configurations. You can verify the connection using s_client, by running a command similar to the following from your Key Manager back ends (replace frontend.example.com:443 with the address of your Key Manager front end):

$ openssl s_client -connect frontend.example.com:443

Back-end-to-front-end connections will fail if back ends cannot verify the front-end server certificates. If this is the case for you, you can resolve it by adding the root-CA certificate of your Key Manager front end to the system trust store on your Key Manager back ends. To do this, run the following command on your Key Manager back ends (replace /path/to/ca.crt with the path where you have the root-CA certificate of the Key Manager front end):

# cp /path/to/ca.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust

Log-message example

May 10 10:13:43 kmserver sshmgr-worker[14791] WARNING: <internal> ALERT: Due to lack of availability or misconfiguration of a host executor, job scan-full #73841 used interactive agentless method instead

Managed configuration local change rollback launched

ID

216

Description

This alert is raised when all of the following conditions are met:

• An SSH software configuration was modified outside of Key Manager, and Key Manager detects the change during a host scan.

• The SSH software configuration is in the managed state.

• The host setting Enforce managed configurations is enabled.

Key Manager detected a change in a managed SSH software configuration on a host. The SSH software configuration on the host has been reverted to match the managed SSH software configuration stored in Key Manager.

How to resolve the alert

Determine what caused the SSH configuration change on the host. You should investigate whether the change was used to gain unauthorized access to the host.

Typically this alert is accompanied by another alert Managed configuration was locally modified (203), which describes the exact changes made to the SSH configuration.

Log-message example

May 10 11:26:43 kmserver sshmgr-worker[14791] WARNING: <internal> ALERT: Managed configuration (#7) of ssh-g3-server on host #4 has locally changed to (#9) and a rollback was launched