This section describes the usual solutions to fixing issues related to, for example, setup, initial login, and services being unavailable. Also restarting PrivX and accessing debug logs are instructed.

Reading Debug Logs

Messages in syslog /var/log/messages and /var/log/privx/*.log may provide additional information about issues in the setup and in client connections.

  • /var/log/privx/auth.log - Logs for the OAuth2 microservice.

  • /var/log/privx/authorizer.log - Logs for the authorizer microservice.

  • /var/log/privx/connectionmanager.log - Logs for the connection manager microservice.

  • /var/log/privx/hoststore.log - Logs for the hoststore microservice.

  • /var/log/privx/indexerservice.log - Logs for the indexer microservice.

  • /var/log/privx/keyvault.log - Logs for the keyvault microservice.

  • /var/log/privx/monitorservice.log - Logs for the monitor microservice.

  • /var/log/privx/rdpmitm.log - Logs for the RDP-Bastion microservice.

  • /var/log/privx/rdpproxy.log - Logs for the RDP-proxy microservice.

  • /var/log/privx/redemption.log - Logs for the RDP-trail-encoder microservice.

  • /var/log/privx/rolestore.log - Logs for the role-store microservice.

  • /var/log/privx/sshmitm.log - Logs for theSSH-Bastion microservice.

  • /var/log/privx/sshproxy.log - Logs for the SSH-proxy microservice.

  • /var/log/privx/trail-indexer.log - Logs for the trail-indexer microservice.

  • /var/log/privx/userstore.log - Logs for the user-store microservice.

  • /var/log/privx/watchdog.log - Logs for the watchdog microservice.

  • /var/log/privx/workflowengine.log - Logs for the workflow-engine microservice.

For more details about what each microservice does, see the section called "PrivX Architecture".

For more information about enabling debug logging, see the section called “PrivX Log Settings”.

Checking microservice statuses

You can verify the microservice statuses on the status page, available at (replace with the address of your PrivX server:

Restarting PrivX

Some issues may be fixed by restarting the PrivX service. You can do this by running the following command on your PrivX servers:

# systemctl restart privx

Services Are Down

If microservices report 502 errors, check the database connectivity. Make sure the pg_hba.conf on the PostgreSQL server allows PrivX servers to connect to the PrivX database with md5 authentication.

More information about the error may be provided by the microservice logs.

Connections fail with error Too many Authentication Failures

PrivX connects using all the available credentials (such as certificate, public key, and stored credentials). For target users who allow many roles, the OpenSSH MaxAuthTries may be exceeded before PrivX offers the correct authentication method.

To fix the error, increase the MaxAuthTries in the target-host OpenSSH configuration, restart the target-host OpenSSH server, then try connecting again.

Problems Related to Authentication

More information about authentication issues may be found from syslog messages.

Since PrivX uses short-term certificates for user authentication, deviations in system times (minutes or more) will easily result in failing authentications. It is extremely important to synchronize the clocks between all the involved systems:

  • PrivX servers

  • Hosts serving as connection endpoints.

We strongly recommend using authenticated NTP clock synchronization on all the involved systems.

Directory Users Are Not Listed

PrivX applies a default pre-filter for matching user records. The pre-filter may need to be adjusted depending on your user-directory structure. For more information about adjusting how users are matched, see the section called “Adjusting User Matching”.

List Users View Does Not Display All Attributes

Sometimes in List users view some of the columns show Anonymous, or are empty. In this case it is possible you may need to adjust the attribute mapping in your directory settings. For example in default OpenLDAP setup you could have the following attribute mappings:

  • sn=full_name

  • uid=principal

Contacting Support

You can request technical support and let us know about PrivX issues on the SSH Communications Security support site at

When submitting a support ticket, please attach PrivX troubleshooting data. To generate troubleshooting data, run the following on your PrivX server:

# /opt/privx/scripts/ info

And attach the generated troubleshooting-data package to the support ticket. By default the package is generated to the current working directory, with the name:



Troubleshooting data may contain security critical data, and must be distributed with appropriate care.

For additional usage instructions related to the troublehsooting script, you may run:

# /opt/privx/scripts/ -h