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

📘

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

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".
This feature is supported from PrivX 17 onwards.

./deploy.py --delegated-principal 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. 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.
This feature is supported from PrivX 17 onwards.

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

📘

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.

You can run './deploy.py --show-config' on target host to see more information about your host config (since PrivX 17).

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 Automatic Account and Home Directory for Directory Users.


Did this page help you?