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.
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 Appendix B.
For more information about enabling debug logging, see the section called “PrivX Log Settings”.
You can verify the microservice statuses on the status page, available at (replace https://privx.example.com with the address of your PrivX server:
https://privx.example.com/status.html
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
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.
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.
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.
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”.
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
You can request technical support and let us know about PrivX issues on the SSH Communications Security support site at https://help.ssh.com/
When submitting a support ticket, please attach PrivX troubleshooting data. To generate troubleshooting data, run the following on your PrivX server:
# /opt/privx/scripts/troubleshoot.sh 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:
Privx-troubleshoot-data-<host>-<timestamp>.tar.gz
Caution
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/troubleshoot.sh -h