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 it 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​​]
(doc:certificate-authentication-setup-via-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, Settings/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

📘

Note

To make the example commands below to function, you also need to define the host service provider, like '--aws', '--azure' or '--google-cloud', or '--standalone' for on-prem hosts. This flag is used for discovering host unique identifier and IP addresses of the host.

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

📘

Note

If target host has been configured to accept both Explicit logins (principal) and Directory logins (personal-account-roles) for the same principal, Explicit login configuration is always used. For example, configuring shared account 'root' in /etc/ssh/auth_principals/ will override any config in /etc/ssh/personal_account_roles for that principal.

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

📘

Note

PrivX functions only as a Zero Trust access solution and does not configure user accounts on the target hosts for you. For automatically creating missing SSH user accounts during login, see XXX and Pluggable Authentication Modules