In this Administrator Manual you will find instructions for deploying and operating PrivX.
PrivX provides you with:
A web-based solution for accessing target hosts using SSH and RDP, removing the need for dedicated clients.
A customizable workflow-based mechanism for requesting and granting access through roles.
Integration with existing user and host directories.
Just-in-time, role-based access to target hosts – no SSH keys used, no need to rotate keys – access can be revoked at any time
Roles can be granted within PrivX, or they can be mapped from existing user groups and/or roles.
Problems with Common PAM Solutions
Traditional ways of provisioning access to servers rely on outdated methods and processes that are not compatible with the cloud. Additionally, credentials that provide access for privileged users are often left unprotected on client endpoints susceptible to theft or misuse.
Traditional Privileged Access Management (PAM) is based on password vaulting and automatic password rotation with special agent/client software to be installed on network machines. Password vaults become single points of failure, they are also expensive and difficult to deploy. Similarly, agents and clients need to be patched and kept up to date. All of this makes deploying, maintaining, and using traditional PAM expensive and complex.
The Solution: PrivX
PrivX uses short-term credentials to provide just-in-time access to servers. Access is granted based on the user’s role. Provisioned credentials are created on demand, only valid for a short time, and never stored to disk.
- Improve security
Access to endpoints is provisioned using on-demand short-lived certificates that are valid for only a few minutes and never written to disk nor exposed to end-users. This completely eliminates the risk of credential theft, removing the greatest security risk in privileged access management.
- Reduce costs
PrivX works using existing SSH clients and servers, so there is no need to add or replace components of the SSH infrastructure. The lack of dependence on external components translates to minimal disruptions to network infrastructure, and reduced maintenance costs.
Using short-lifetime access certificates provided by PrivX eliminates the need for certificate revocation or key rotation.
This Administrator Manual is intended for technical personnel responsible for installing software to the company network, those responsible for security software, and personnel maintaining and auditing secure access in the corporate network.
Readers are expected to be familiar with the operating systems on which the PrivX will be installed.
Readers should also be familiar with the Tectia Server and any Secure Shell software used in their environment.
Deploying PrivX involves the following steps:
Onboard users. Define roles for granting access privileges (Chapter 6).
Set up passwordless authentication methods for target hosts (Chapter 7).
To prevent having to reconfigure hosts later, we strongly recommend you set up the necessary roles in your environment before configuring authentication methods on target hosts.
Use PrivX to connect to target hosts (Chapter 8).
Tip
For an introduction to the PrivX main features, see the examples in Chapter 4.
The following terms are used throughout the documentation.
- authorizer
Authorizer creates certificates with user’s roles as needed for users connecting to target hosts.
- certificate
A certificate is a signed document that binds together the trusted issuer, and subject information such as public key, subject name, list of principals (role memberships), and information about access restrictions. Certificates on PrivX are short term, issued by the Authorizer, and verifiable using the Authorizer public key.
- directory (in UI)
A directory in the PrivX UI refers to a source of user accounts, for example, an AD/LDAP directory.
- host service
Services by which PrivX users establish connections: SSH servers, RDP servers, and Web-login pages.
- host store
Host stores save host information, such as addresses, SSH/RDP services, and target-user-to-role mappings. Host stores also import hosts from existing directories.
- known host
When the connection information of a host is stored in PrivX, that host is considered a known host. Known hosts enable PrivX features including passwordless and certificate-based connections.
- local user directory
Local user directory provides an easy way to create local users for authentication and role mapping. Authentication is done via username or email, and a password.
- native client
SSH and RDP clients supported by users' operating systems, such as OpenSSH client (ssh) or Remote Desktop client (mstsc).
- OAuth2 service
OAuth2 service provides an authentication mechanism for a user to provide a username and password, and provides the given credentials against SSH PrivX Local User Store, and authentication providers, such as LDAP and AD.
- principal
Principals are unique identities used in OpenSSH certificates, such as user names, or the UUIDs of PrivX roles.
- PrivX deployment
PrivX servers using the same database. A PrivX deployment consists of one or more PrivX servers.
- PrivX user
Any user account that is available via PrivX. Includes both PrivX local users, and users from AD/LDAP directories users that have been added to PrivX.
- role
PrivX provides role-based access permissions: For a user to receive access permissions, they must be assigned to a role. Each role in the system has a unique principal (UUID) that represents the role in certificates and target host configurations.
- role store
In PrivX, role store integrates against user directories and identity providers, for example, LDAP and AD. Role store contains rules which are evaluated to automatically map existing LDAP/AD user groups and roles into PrivX roles which are in turn used to access target hosts.
- target
An identity and a host service that PrivX user(s) may connect to (for example, connecting to a host as root using SSH).
PrivX regards each unique idenity-service combination as a separate target. For example, connecting to a host as root using SSH is different from connecting to the host as root using RDP.
See also host service, target host and target user.
- target host
Any destination host for a connection that has been authenticated/authorized using PrivX. In other words, any host to which access is granted using PrivX.
- target user
The identity that PrivX users assume on target hosts.
The following typographical conventions are used in SSH Communications Security documentation:
Table 1.1. Documentation conventions
| Convention | Usage | Example |
|---|---|---|
| Bold | Menus, commands, GUI elements, strong emphasis | Click Apply or OK. |
| → | Series of menu selections | Select File → Save |
Monospace | Filenames, directories, URLs etc. | Refer to readme.txt |
| Italics | Placeholder values in examples, reference to other documents or products, emphasis | See the Tectia SSH Client User Manual |
| # | In front of a command, # indicates that the command is run as a privileged user (root). | # rpm --install package.rpm |
| $ | In front of a command, $ indicates that the command is run as a non-privileged user. | $ sshg3 user@host |
| OS#, OS$ | In front of a command, OS# or OS$ indicates that the command is specific for certain operating systems. Multiple operating systems are separated with a /. | SUSE$ sudo zypper update RedHat/CentOS# yum upgrade |
| \ | At the end of a line in a command, \ indicates that the command continues on the next line, but there was not enough space to show it on one line. | $ ssh-keygen-g3 -t rsa \ -F -c mykey |
Note
A Note indicates neutral or positive information that emphasizes or supplements important points of the main text. A Note supplies information that may apply only in special cases (for example, memory limitations, equipment configurations, or specific versions of a program).
Caution
A Caution advises users that failure to take or to avoid a specified action could result in loss of data.