SSH Privileged Commands


The MID server can run commands on targets via SSH. Some commands may require elevated privileges. The platform provides default privileged commands for the MID Server to use and the ability to add additional commands to the system. If your system cannot use sudo commands, you can configure the hosts in your network to use one of the other privileged commands. You can configure different privileged commands for different hosts. However, only one privileged command per host is supported.

The following example errors could be returned when privileged commands are not properly configured:


The following parameters must be set as follows to ensure the Servicenow SSH Client is used:

MID Server Parameter

mid.ssh.use_snc = true

MID Server Properties = true = true

Documentation for above parameters/properties

Privileged Command Flow

The following is the overall logic used when it is determined a privileged command must be used:

  1. Check table dscy_priv_command_affinity to see if there are any privileged command affinities already set for this MID Server and target combination 
  2. Result found in dscy_priv_command_affinity? 
    • Yes: End logic and use privileged command found in the affinity table
    • No: Continue
  3. Loop through the privileged commands according to the priority set and attempt the command, see table ecc_agent_privileged_command_m2m
  4. Is the command successul?
    • Yes: Add affinity for command/MID combination, end logic
    • No: Try next command available 

Note: For pattern discovery, whatever command is set on MID property mid.ssh.mapping.privileged_command will be used if is set to false. MID property mid.ssh.mapping.privileged_command is not configured OOB.

Sudo Command

Privileged command "sudo" is a special case. Your security team may not be fond of users trying to run combinations of sudo with other commands they are not allowed to run. Therefore, first we try to determine if the user is allowed to run such command. The following logic is run if sudo is to be used:

  1. Is sudo the privileged command?
    • Yes: Continue sudo logic
    • No: End sudo logic
  2. Run "sudo -l" on the target server
  3. Compare output from "sudo -l" with command to be run
  4. Determine if use is allowed to run "sudo commandToBeRun"
  5. Is user allowed to "sudo commandToBeRun"
    • Yes: Run "sudo commandToBeRun"
    • No: Run "commandToBeRun"

Note: The output from "sudo -l" may be truncated due to the terminal width configuration. When this happens, the command may be run without sudo and return permission denied. This will often happen when the output from "sudo -l" is large. If so, set MID server parameter mid.ssh.terminal.width to a larger value (2000 for example), the default is 255.

The privilege check to determine if sudo should be used is dependent on the result returned by "sudo -l". The privileged check can be disabled by setting MID server property "mid.ssh.disable_privilege_check" = true. The output from "sudo -l" would not be compared to the command to be run when mid.ssh.disable_privilege_check is set to false, but "sudo -l" would still run. The determination would fail if there are issues when running "sudo -l", for example if the command requests password but the credential is a private key credential and does not have a password.

Finally, sudo commands may not work with private key credentials if the credential configured does not have a password. A solution is to add the NOPASSWD option to the sudo configuration. For example, you might enter (in the example below the user name would be "disco"):

disco ALL=(root) NOPASSWD:/usr/sbin/dmidecode,/usr/sbin/lsof,/sbin/ifconfig.

See additional requirements on:

Command Location

You may need to add your privileged command path if the command is not in one of the default locations for Servicenow. By default the following locations are in the path:

You may determine the location of the command by running "which commandName" or "command -v commandName". If the location is not one of the locations provided OOB, you can add it to the path via mid.ssh.path_override. See following documentation:


Note: "SUDO ONLY" at a step means the desired privileged command is sudo. Those steps can be skipped when the privileged command is not sudo.

  1. Does "privileged command + command" run successfully on the target (i.e. "sudo lsof")?
    • Yes: Continue
    • No: Work with your server team to correct any errors
  2. Does dscy_priv_command_affinity table have records pointing to other privileged commands?
    • Yes: Remove any incorrect affinities
    • No: Continue
  3. Does ecc_agent_privileged_command_m2m table contain the right privileged command for the MID being used?
    • Yes: Continue
    • No: Follow steps to configured privileged commands for this server
  4. *SUDO ONLY: Does the output of "sudo -l" confirm the user is allowed to run the command?
    • Yes: Continue
    • No: Work with your server team to correctly update the sudoers file
  5. *SUDO ONLY: Is the credential being used a private key credential?
    • Yes: Ensure the sudo configuration contains the "NOPASSWD" option for the command.
    • No: Continue
  6. *SUDO ONLY: Does setting MID server parameter mid.ssh.terminal.width to a larger value, i.e. 2000, resolve the issue?
    • Yes: Done
    • No: Continue
  7. Set MID server to debug and reproduce issue, see "Setup Debug" section of this kb
  8. Review MID server logs

Note: Ensure the user can run "sudo -l" on the target without being requested a password if the credential is of type "SSH Private Key".

Setup Debug

Set mid server parameters as follows:

  1. mid.log.level = debug
  2. mid.ssh.debug = ipOfTargetDevice



Additional Information