![]() |
This sections introduces workaround instructions for some problem situations.
Public-Key-PrivX (not configured) is shown instead of the configured PrivX Instance name in PrivX Desktop GUI Authentication method dropdown. Most likely the configuration has not been saved and applied or the Connection Broker is not running. To solve this, In Tectia Connections Configuration GUI click Apply, then quit and reopen the PrivX Desktop GUI.
PrivX TLS server authentication fails with "error in OAuth authorisation:
failure in the authorization HTTPS request Get PrivX_URL
tls: failed to verify certificate: x509: certificate signed by unknown authority / Failed to get credentials from PrivX"
if configured PrivX Instance's TLS server certificate cannot be successfully validated.
To solve this,
ensure that the issuing CA certificate(s) are in the Operating System trust store and it is trusted for TLS server authentication.
For example on macOS, after importing the CA certificate (e.g. company root CA certificate) to the System keychain, follow these instructions:
Open Keychain Access application to change the Trust Settings.
In System keychain select the CA certificate that is the issuer of the PrivX TLS server certificate.
Choose Get info from the alternate menu and expand Trust.
Change Secure Socket Layer (SSL) to Always Trust.
Alternatively, configure the CA certificate for TLS server authentication explicitly for Connection Broker and for your default web browser. See the privx-instance configuration option and PrivX Desktop Quick Start Guide for more information.
Invalid access token If PrivX user does not have sufficient permissions or role(s) in PrivX, the Public-Key-PrivX authentication fails with error "received a non-success status code: 400: Invalid access token: no permission for operation / Failed to get credentials from PrivX"
To solve this, ensure you have used your intended PrivX user account that allows PrivX agent-based connections. PrivX might be used in your organization also for other use cases with different PrivX user account. Please contact your PrivX privileged-access-management system administrator.
Prerequisites on PrivX Instance:
PrivX user a user account that maps to the intended PrivX role(s).
Use with PrivX agent option enabled for the role(s) that grant access to the target(s).
connections-authorize permission enabled for the role(s) that grant access to the target(s).
Pending authentication If PrivX user authentication in web browser fails or the browser tab is closed before completion, the Secure Shell connection remains in AUTHENTICATING state with pending PrivX authentication in browser query until the login-grace-time exceeds on the server-side or the PrivX session connection login-timeout is reached. To be able to try again, either wait for 5 minutes until the PrivX session connection times out with error "login timeout / Failed to get credentials from PrivX" or disconnect the connection. In PrivX Desktop GUI go to Menu→Connection List, select the connection in Connections tab, and choose Disconnect.
Alternatively, check the connection ID(s) and disconnect on command-line:
ssh-broker-ctl list-connections
ssh-broker-ctl close-connection <connection-IDs>
If the problem persists, stop the Connection Broker on command-line:
ssh-broker-ctl stop
Then quit and reopen the PrivX Desktop GUI
If there are multiple public-keys available either via external key providers or in the user-specific configuration directory, the server-side might refuse the connection if too many keys are attempted during publickey authentication. Typically the error shown when attempting to connect to an OpenSSH server that allows six attempts is "Connection open failed Protocol error (remote): too many authentication failures public_keys_tried: 7". If the server configuration cannot be changed to allow more attempts, the workaround on the client-side is to set the Connection profile to prompt the user for the specific key to use or with the sshg3, sftpg3 or scpg3 command-line clients use the -K option to specify the explicit key.
sshg3 -K <path_to_key> <profilename>