Hitachi ID Bravura Privilege 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

Bravura Privilege 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, Bravura Privilege 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

Bravura Privilege 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 Bravura Privilege 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 Bravura Privilege server or on a Unix/Linux system which Bravura Privilege 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 Bravura Privilege server.
  7. At access checkout time, Bravura Privilege 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, Bravura Privilege 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. Bravura Privilege 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, Bravura Privilege will remove A's public SSH key from F@C's .ssh/authorized_keys file.