Hitachi ID Privileged Access Manager can be used both to discover and analyze existing SSH trust relationships and to inject SSH public keys into .ssh/authorized_keys files as a form of temporary access disclosure.

Discovering and analyzing the web of trust

Privileged Access Manager can discover SSH public keys and trust relationships, to build a trust graph.

For example, if the public key of account A on system S1 (i.e., A@S1/.ssh/ appears in the authorized keys file of account B on system S2 (i.e., B@S2/.ssh/authorized_keys), then A@S1 has access to the B@S2 account. Moreover, if A@S1's private key has no password, as is typical, then any user or account with root access on S1 could also connect to B@S2. These relationships -- from A@S1 to B@S2 and from root@S1 to B@S2, represent trust and collectively they form a trust graph.

The SSH trust graph is important because it may allow unanticipated access. Building on the above example, if a user is authorized access to A@S1, he implicitly also gains access to B@S2. Is that intentional? Did approval for the user to sign into A@S1 consider this additional access?

In addition to discovering the SSH trust graph, Privileged Access Manager can also take trust relationships into consideration when computing required approvals for access, and report on the trust relationships. Trust graph analytics, in turn, can identify high risk accounts (for example, that are widely trusted) and to disable unnecessary trust relationships.

SSH trust injection

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.