One Identity Management Console for Unix 2.5.2 - Administration Guide

One Identity Privileged Access Suite for Unix Introducing One Identity Management Console for Unix Installing Management Console for Unix Preparing Unix hosts Working with host systems Managing local groups Managing local users Active Directory integration Authentication Services integration Privilege Manager integration
Getting started Configure a primary policy server Configure a secondary policy server Install PM agent or Sudo plugin on a remote host Security policy management
Opening a policy file Edit panel commands Editing PM policy files Reviewing the Access and Privileges by User report Reviewing the Access and Privileges by Host report
Event logs and keystroke logging
Reporting Setting preferences
User preferences System preferences
Security Troubleshooting tips
Auto profiling issues Active Directory Issues Auditing and compliance Cannot create a service connection point Check Authentication Services agent status commands not available CSV or PDF reports do not open Database port number is already in use Elevation is not working Hosts do not display Import file lists fakepath Information does not display in the console License information in report is not accurate Out of memory error Post install configuration fails on Unix or Mac Privilege Manager feature issues Profile task never completes questusr account was deleted Readiness check failed Recovering from a failed upgrade Reports are slow Reset the supervisor password Running on a Windows 2008 R2 domain controller Service account login fails Setting custom configuration settings Single Sign-on (SSO) issues JVM memory tuning suggestions Start/stop/restart Management Console for Unix service Toolbar buttons are not enabled UID or GID conflicts
System maintenance Command line utilities Web services Database maintenance About us

Managed Unix Hosts

Secure access to the managed Unix hosts is performed using the SSH protocol. Management Console for Unix uses SSH internally to profile hosts, manage users and groups, and run Readiness Check Results reports.

While the SSH protocol encrypts traffic and can use passwords to authenticate users, it uses public key cryptography to authenticate the server. If the server is not correctly authenticated, it is possible for an attacker to act as a 'man-in-the-middle' and obtain the user's logon and root passwords for a host. For this reason, it is important to understand how the options to manage SSH host keys affect the security of your Management Console for Unix installation.

Managing SSH host keys

Management Console for Unix uses SSH as the network protocol to provide secure remote access and administration of Unix hosts. It maintains a list of valid SSH host keys used to authenticate the connections.

The mangement console allows you to directly import these keys, using one of the following methods:

  • By using the Import SSH Host Keys button to upload a new public SSH key for a selected host.

    When you use this command you are prompted to accept the new fingerprint for the selected host.

  • By supplying an OpenSSH known_hosts file when using the Import option on the Add Hosts dialog.

    The known_hostfile contains the host addresses and public key data for known server hosts.

Note: See Known_hosts file format for more information about the supported known_hosts file format.

Alternatively, when profiling a host, new SSH keys are automatically accepted for the selected host by default. However, you can clear the Automatically accept SSH keys option on the Profile Hosts dialog if you want to be prompted to validate the host's SSH key if a key is not already cached for the selected host. If you clear this option, you must accept a host's fingerprint in order to proceed with the profiling process.

Note: While the Automatically accept SSH keys option is enabled by default, clearing this option disables it for subsequent profiles for this user. Regardless of whether the Automatically accept SSH keys option is selected or not, when a modified key is encountered, the profile task will prompt you to accept the new changed keys.

You can view the SSH fingerprint and algorithm used to access a host on the Details tab of a host's properties.

Note: While the Management Console for Unix server automatically accepts SSH host keys by default, to avoid potential "man-in-the-middle" attacks, One Identity recommends that you either disable this option so that you can manually review and accept the key fingerprints, or directly import the keys by using one of the methods described above. This ensures that your SSH connection is secured to a trusted host before supplying your log on or root credentials.

Known_hosts file format

When importing a known_hosts file, the mangement console expects the file to be in a particular file format. The rules for a known_hosts file are:

  • It must contain lines of text consisting of a host's IP address, SSH algorithm, and SSH host key; each field separated by a space. The format is: address algorithm publicKey
  • It must only contain one host entry per line.
  • It does not support Hashed host names.
  • It does not support multiple host names per entry.

The default location for a known_hosts file is: ${user.home}/.ssh/known_hosts

Handling changes to SSH host keys

If an SSH host key is different than what is expected, the mangement console might indicate that the host is experiencing a "man-in-the-middle" attack. More commonly however, it simply indicates that the SSH host key has changed. When profiling, if the mangement console finds a SSH host key that is different than the one that is already cached on the server, it prompts you to accept the changed key.

For other actions, such as adding or deleting a user, a changed host key always results in an error. If you encounter an error, you must update the new SSH key before you can complete the action. See Managing SSH host keys for information about updating the host's SSH Key cached in the mangement console database.

Note: Management Console for Unix caches SSH connections to improve performance when multiple actions need to be performed against a host. Because of this, you might see unexpected behavior. For example, if you profile a host and accept its public key, the mangement console stores the host's public key and caches the SSH connection for a short period of time. If you perform another host action, such as profiling, it uses the cached connection if it is available. You are not prompted to accept a new key while re-using the previously verified and trusted SSH connections obtained from the cache. Once the connection is flushed from the cache, any subsequent host action will identify a new public key and the console will prompt you to accept the new SSH host key.

Documents connexes