PrivX components are optional RPM packages, extending PrivX functionality to NAT networks, adding additional protocol support like HTTPS, allowing SSH connectivity via PrivX agents and support for AWS CLI.
See Setting up PrivX Components for installation instructions.
A PrivX Extender relays host connections, allowing connections to target hosts that are not directly accessible by PrivX, e.g. target hosts without public IP addresses in Virtual Private Cloud or behind other NAT gateways. PrivX Extender acts as reverse proxy, connecting back to PrivX instance via HTTPS endpoint, using secure web sockets.
Using PrivX Extender requires using web load balancer with sticky session support and Round robin routing mode.
You need only one extender per VPN or subnet, connections to target hosts can be relayed through the extender.
Carrier is a PrivX component, which offers auditable HTTP and HTTPS connections for the user in sandboxed environment. Access to shared accounts are provided in a role-based fashion.
PrivX Web Proxy is another component, whose job is to provide access control for those connections and act as a password manager for different sites.
Carrier and Web Proxy are always installed in pairs. For development environments, they can be installed on the same server, but for production it is recommended to have two separate servers.
Carrier is running a separate Firefox web browser on a Docker container for each user session.
By default, PrivX Carrier is creating a separate network for Docker containers, but outgoing traffic from containers is not restricted.
To further harden the installation a firewall rule can be created to block outgoing traffic from Docker network to all but PrivX Web Proxy host address.
Using PrivX Carrier and Web Proxy requires using web load balancer with sticky session support and Round robin routing mode.
PrivX-Carrier and Web Proxy Configuration
Users can connect to target hosts/accounts using the SSH/SFTP/SCP clients installed on their workstations, without needing to use the PrivX GUI. Connections are authenticated against PrivX. Connections are established directly to target hosts.
This configuration requires a PrivX agent to be installed on the user's workstation.
Using PrivX agent also enables using AWS command line client with temporary federated AWS roles via PrivX.
Alternative way of using native SSH clients without installing any additional components would be to use SSH Bastion. SSH Bastion connections are always routed via PrivX instances.
Native SSH and RDP clients
Updated 2 months ago