Hitachi ID Privileged Access Manager can be configured to grant privileged access to Unix and Linux computers by temporarily placing an administrative user's personal SSH public key into the trusted keys file of a functional account on the target computer.

This architecture works as follows:

  1. The Privileged Access Manager server gets its own SSH public and private keys.
  2. Every user who may require privileged access to Unix/Linux systems must have:
    1. An SSH client on his PC.
    2. A well known SSH public key.
  3. A copy of the public SSH key for every user is kept on the Privileged Access Manager server or on a Unix/Linux system which Privileged Access Manager can access.
  4. Each managed Unix/Linux computer is configured with:
    1. An SSHD listener.
    2. The SUDO package.
    3. A set of functional accounts (see below).
  5. The /etc/sudoers file on each managed Unix/Linux computer is configured to grant a set of predefined privileges to each functional account. For example:
    • The account dba might be allowed to perform DB-related tasks.
    • The account backup might be allowed to perform filesystem backups.
    • The account procmon might be allowed to perform runaway processes.
    • The account monitor might be allowed to perform stats from /proc.
  6. The .ssh/authorized_keys file of each of the functional accounts is configured to trust the public SSH key of the Privileged Access Manager server.
  7. At access checkout time, Privileged Access Manager modifies the .ssh/authorized_keys file of the functional account to which access was granted to include the public key of the user who needs access to that account.
  8. At access checkin or expiry time, Privileged Access Manager modifies the .ssh/authorized_keys file of the relevant functional account to remove the public key of the user who had access to that account.

The access disclosure process works as follows:

  1. Administrator A requests access to functional account F on computer C.
  2. The request is approved either because A has been pre-approved for such access (typically via membership in an AD group) or because some other user, with ownership rights to F@C, approves the request.
  3. Administrator A "checks out" access to F@C.
  4. Privileged Access Manager retrieves a copy of the .ssh/authorized_keys from F@C, adds A's public SSH key to the file and puts the new .ssh/authorized_keys back in F@C's home directory.
  5. A connects to F@C using SSH. This connection is authenticated using an SSH key exchange (not a password).
  6. A may have to type a password to access his own SSH private key, depending on how whether his SSH key is encrypted with his password.
  7. Eventually A will either check-in the session or the session will time out. When either event happens, Privileged Access Manager will remove A's public SSH key from F@C's .ssh/authorized_keys file.