PrivX users can authenticate to target hosts using one of the following methods.
|Stored password||SSH, RDP, Web||Not supported with agent-based SSH connections|
|Certificate (for SSH connections)||SSH||Only for supported OpenSSH versions described in SSH Certificate Authentication.|
|Public key||SSH||Not supported with agent-based SSH connections|
|Certificate (for RDP connections)||RDP||Target hosts must satisfy the prerequisites from RDP Certificate Authentication.|
Not supported with native-client connections.
|User-provided password||SSH, RDP, Web|
Users are authenticated using passwords stored in PrivX. Users do not need to input credentials when connecting.
Advantages: Easy to set up.
Disadvantages: Weak passwords may compromise security.
Users are authenticated using just-in-time certificates. PrivX automatically issues certificates as needed; users do not need to input credentials when connecting.
Advantages: Automatically expiring certificate that is never exposed to users, making this method the most secure option.
Disadvantages: Routers or older hardware might not support certificates. System times must be synchronized for certificate-based authentication to work correctly.
Users are authenticated using public keys provided by PrivX. Users do not need to input credentials when connecting.
Advantages: Public-key authentication is largely supported even on older and non-mainstream SSH servers.
Disadvantages: Public keys must be manually provisioned to target users on target servers. Public keys never expire, so they need to be manually renewed.
Users are prompted for password when connecting.
Advantages: No additional target-host configuration required.
Disadvantages: Users must provide the target-user password when connecting. Weak passwords may compromise security.
If a target supports multiple methods, the topmost supported method is used. User-provided password is enabled on all target hosts by default.
Also see Connection method vs feature matrix
Updated about 2 years ago