Skip to main content

Key Manager Jobs

Troubleshooting information for Key Manager jobs may be obtained from job logs. Job logs can be reviewed on the Logs→Jobs page, by performing a View Log action on the target job. You may also check jobs logs using the command-line client, for example:

$ ssh-mgr-client view-job -i <JOB_ID>

Symptom: Jobs stay queued while no jobs are running

  • Ensure that your Key Manager back end services are running. You can do this by running the following on the back-end machines:

    # supervisorctl status

    Restart the back-end services if necessary:

    # supervisorctl restart backend:
  • Ensure that the back-end setting Maximum processes is greater than zero. The global Maximum processes setting is on the Settings→General→Backend page. To see back-end-specific Maximum processes, go to the Settings→Management servers page and perform a Settings action.

  • Jobs are not run if your Key Manager license has expired. If this is the case, you can obtain a new license by contacting sales at SSH Communications Security.

Symptom: Host is configured to use script-based scanning, but there is no backend:host-executor available for it

  • Ensure that the backend:host-executor service is running on your Key Manager back ends. You can do this by running the following on your Key Manager back ends:

    # supervisorctl status backend:host-executor

    Start the backend:host-executor service as necessary:

    # supervisorctl restart backend:host-executor

    If the service fails to restart, check the service log for additional information:

    # supervisorctl tail -f backend:host-executor
  • Host-executor services use SSL-encrypted connections to connect to Key Manager front ends. Therefore, you must ensure that Key Manager Servers trust each others' server certificates. To ensure and configure that certificates are trusted:

    1. Ensure that each Key Manager Server certificate specifies the correct server name.

      You can see the Key Manager Server names via the Key Manager GUI, on the Settings→Management Servers.

      For each Key Manager Server, ensure that the server certificate CN matches the FQDN of the Key Manager Server. If the certificate specifies any DNS names, at least one of them must match the FQDN of the Key Manager Server. If necessary, create and set up a server certificate that matches these criteria.

  1. Obtain the root-CA certificate(s) of your Key Manager front ends.

  2. On each Key Manager Server running the host-executor service, make the root-CA certificate(s) trusted by the system:

    • Add the root-CA certificate(s) under the system trust-anchors directory

      /etc/pki/ca-trust/source/anchors/

      Then apply the new root-CA certificate(s) to the system:

      # update-ca-trust extract
  3. On the Key Manager Server(s) running the host-executor service, verify that Key Manager front end certificates are trusted (replace frontend.example.com with the address of a Key Manager front end):

    # echo 'Q' | openssl s_client -connect frontend.example.com:443

    If certificates are configured correctly, the command should return 0:

    Verify return code: 0 (ok)

Symptom: Job fails with error Download size mismatch

This is likely caused by unexpected messages printed in the host-management session (by, for example, sudo or broadcast).

Symptom: Scan job fails with Even sudo fallback does not work

Target host is configured to use script-based scans, but the management account lacks permissions to run the host-utility script as root, or is unable to find/execute the host-utility script at the Host script path.

  • Ensure that the management user has read permissions to the directory containing the host-utility script. If you have configured Key Manager to automatically upload the host-utility script, the management user must also have write permissions to the directory.

  • Ensure that the host-utility script exists at the Host script path. The host-utility script must be owned by the management user, and have the permissions rwxr-x-rx (755).

  • If the target-host management user is non-privileged, ensure the privilege-elevation software allows them to run the host-utility script as root.

    For example if using sudo, you will likely need to adjust the sudoers template for the management user. You may then manually trigger a host scan to verify the sudo settings (replace managementuser and /path/to/ssh-mgr-host-utility.sh with the management-user account and the path to the host- utility script respectively):

    # su - managementuser
    $ sudo /path/to/ssh-mgr-host-utility.sh scan-local

    When using sudo, also ensure the host is installed with sudo version 1.7.0 or later.

For more information about the configurations required for script-based scans, see Enabling Script-Based Scans.

Symptom: Key renewal job on a zero trust key fails with VALUE_INCORRECT_FORMAT

PrivX does not support the algorithm you have chosen. Support for the chosen algorithm can be enabled in PrivX settings. See PrivX manual at https://privx.docs.ssh.com/docs/supported-ssh-key-exchange-algorithms.