Configuring SSH Target Host to Accept PrivX Connections

Using PrivX does not require any agents or additional software to be installed on the target hosts. This makes it possible for PrivX to access a wide selection of servers, like routers, which can run SSHD server but where is not feasible or possible to install any agent software.

By default, the preferred method of connection to SSH hosts is by using short-lived ephemeral certificates. These certificates have limited validity period (default is 5 minutes) and they're used in-memory and discarded after use. Other available authentication methods are public key authentication, session-interactive and credential authentication. See Supported Authentication Methods

For public key authentication, it is possible to import private keys to PrivX role, allowing PrivX to connect to your existing infrastructure without any additional configuration. This is recommended configuration for accessing target hosts or other devices which are not easy to reconfigure or do not allow certificate authentication.

To access target hosts via PrivX with certificate authentication, the target host SSHD needs to be configured to trust PrivX certificate and to accept PrivX connections. This can be done either manually, using automation tools like Ansible or Chef, or via PrivX provided deploy script.

Deploy script

Deploy script is a Python configuration script, supporting most Linux platforms. It configures the SSHD on the target host, makes the host to trust PrivX certificates and informs PrivX about the new host after successful configuration.

It is also possible to configure the host manually, see Manual Certificate-Authentication Setup. If you have need for additional environments, please contact PrivX Support.

Deploy script can be downloaded via PrivX UI, Administration→Deployment→Deploy and Configure SSH target hosts.

It is also possible to delegate the host configuration to team admins by creating a separate access group for each team and providing the team admins with their own access group specific deploy script.
See "Access groups" for more information.

Allowing access for PrivX roles and principals

To allow PrivX access to target host via certificate authentication, the host can be configured to allow access for specific PrivX roles and principals. See Managing Roles. The host can be configured to allow access from PrivX roles and principals or just by a specific role or principal, or anything in between.

Examples

1. Shared user account on target host with pre-defined role access

To configure target host to accept users with "developers" role to log in as "ec2-user". All other roles or principals are rejected. PrivX does not have permission to log-in to the host with any other role or principal using certificate authentication.
This is the most common way of configuring target host to use shared accounts. Requires re-configuration of the host if new roles are added which need to access this host.

./deploy.py --principals ec2-user=developers

2. Personal user account for pre-defined roles

To configure target host to accept users with "developers" role to log with their own Unix username.
Requires re-configuration if new roles are added which need to access this host. This is the most common way of configuring target host to use personal user accounts.
Personal Unix accounts are user directory specific. For changing which attribute in user directory should be used for resolving user's unix username, see "Attribute mapping" -setting in PrivX directory configuration.

./deploy.py --personal-account-roles developers

3. Both personal- and shared user accounts for pre-defined roles

To configure target host to accept users with "developers" role to log with their own Unix username, but block root logins to the host via PrivX, unless user has "privx-admin" role.
Requires re-configuration if new roles are added which need to access this host.

./deploy.py --personal-account-roles developers --principals root=privx-admin

4. Delegated role configuration for principal

To allow all logins as "ec2-user" to host via PrivX, if PrivX certificate is accepted and certificate principal name matches the target host username.
This delegates all role configuration for principal "ec2-user" to PrivX.
Does not require any additional configuration changes on target host, if you later want to create a new role in PrivX and allow users with that role to log in to the host as "ec2-user".
Requires re-configuring the target host if new target principals are added to the host.x
This feature is supported from PrivX 17 onwards.

./deploy.py --delegated-principals ec2-user

5. Delegated role configuration for all user accounts

To allow all logins to host via PrivX, if PrivX certificate is accepted and certificate principal name matches the target host username.
This delegates all role configuration to PrivX and does not require any additional configuration changes on target host. This is the easiest option for on-prem hosts, if you do not have any management software in place and cannot re-configure hosts easily.
It's enough to run this once on the target host and then do all the role and host configuration on PrivX side. Requires "Directory" account type to be used in PrivX UI host config.
This feature is supported from PrivX 17 onwards.

./deploy.py --delegated-personal-account-roles

6. Delegated role configuration with restrictions

To allow all logins to host via PrivX, if PrivX certificate is accepted and certificate principal name matches the target host username. Prevent root logins via PrivX.
This can be used for example allowing third party to access your servers via PrivX, logging in with their own usernames, but prevent third party PrivX admins for logging in as root to your hosts.
Requires "Directory" account type to be used in PrivX UI host config.
This feature is supported from PrivX 17 onwards.

./deploy.py --delegated-personal-account-roles --principals root=disabled

7. Delegated role configuration for all user accounts and roles

To allow all logins to host via PrivX, if PrivX certificate is accepted without requiring any additional configuration on the target host principals or roles.
This can be used for allowing PrivX to decide which role can access which principal on the target host without changing host configuration if new roles or principals are added.
The PrivX signed certificate used for the SSH access will be tied to the requested principal name and the machine id of the target host.
Delegated-principals-all setting can also be overridden with --principals flag for specific principals, for example for completely preventing root access via certificate login (with --principals root=disabled)
No config changes required to target host at all when adding new roles or accessing new principals.
This feature is supported from PrivX 24 onwards.

./deploy.py --delegated-principals-all

See Script-Based Certificate-Authentication Setup for more information about deploy script options.