General Troubleshooting

This article outlines general troubleshooting practices applicable to various PrivX problem scenarios.

Checking Microservice Status

You can verify the status of PrivX microservices by visiting the status page. Replace https://privx.example.com with the address of your PrivX server:

https://privx.example.com/privx/status

Restarting PrivX

Some issues can be resolved by restarting the PrivX services. To do this, run the following command on your PrivX servers:

systemctl restart privx

If microservices return HTTP 502 errors, check the database connection. If using a local PostgreSQL server, ensure that its pg_hba.conf file allows PrivX servers to connect using MD5 authentication (PostgreSQL 9.2–9.6 on CentOS 7) or SCRAM-SHA-256 authentication (PostgreSQL 10 and later).

More information may be available in the microservice logs.

Getting Debug Logs

Debug logging can be enabled per microservice, as described in the PrivX Log Settings documentation.

By default, microservice logs are located in /var/log/privx/ as follows:

Microservice	Log Location
Authorizer	`/var/log/privx/authorizer.log`
Connection Manager	`/var/log/privx/connectionmanager.log`
Hoststore	`/var/log/privx/hoststore.log`
Keyvault	`/var/log/privx/keyvault.log`
Monitor	`/var/log/privx/monitorservice.log`
OAuth2	`/var/log/privx/auth.log`
RDP Bastion	`/var/log/privx/rdpmitm.log`
RDP Proxy	`/var/log/privx/rdpproxy.log`
RDP-Trail Encoder	`/var/log/privx/redemption.log`
Role Store	`/var/log/privx/rolestore.log`
SSH Bastion	`/var/log/privx/sshmitm.log`
SSH Proxy	`/var/log/privx/sshproxy.log`
Trail Indexer	`/var/log/privx/trail-indexer.log`
Userstore	`/var/log/privx/userstore.log`
Watchdog	`/var/log/privx/watchdog.log`
Workflow Engine	`/var/log/privx/workflowengine.log`

In addition, logs are also written to /var/log/messages.

Troubleshooting Authentication Issues

For authentication-related issues, refer to the system logs -- and take a look at Authentication and Login issues Troubleshooting section.

PrivX uses short-lived certificates for user authentication. Therefore, even small time differences (a few minutes) between systems can cause authentication to fail. It is essential to keep clocks synchronized between all involved systems, including:

PrivX servers
Target hosts (connection endpoints)

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

Contacting Support

You can request technical support and report issues through the SSH Communications Security support portal.

When submitting a support ticket, include the following details:

Detailed description of the issue
- Cause: Describe the steps leading to the error. Include screenshots and any relevant error messages.
- Occurrence: Is the issue reproducible? Has it occurred before?
- Impact: Does the issue affect a single user, connection, or host, or is it widespread?
Relevant configurations (PrivX admin UI)
- For example, if a user cannot connect to a host, include screenshots of the host configuration, the user's details, and roles.
Troubleshooting data
- To generate troubleshooting data, run the following command on a PrivX server:
```
/opt/privx/scripts/troubleshoot.sh info
```
- By default, the data package is created in the current directory with a name like PrivX-troubleshoot-data-<host>-<timestamp>.tar.gz -- include it in the support ticket.

If the PrivX service is fully or partially down, run the troubleshooting script and collect data while the issue is occurring.

Caution

The troubleshooting data may include sensitive information. Handle and share it with appropriate care.

By default, the troubleshooting script uses /tmp as its working directory. If /tmp is not available or has limited space, use the --t or --tempdir option to specify another location.

To reduce the size of the collected data, use the -s or --log-since option to specify the number of days of logs to include.

For more usage options, run:

/opt/privx/scripts/troubleshoot.sh -h