SSH Privileged Commands - Support and Troubleshooting

SSH Privileged Commands Summary 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:

Permission denied User has no right to run command under sudo Host required password, but no password was available. Verify that proper credentials are defined Table of Contents Settings Privileged Command Flow Troubleshooting Setup Debug Settings 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 mid.property.ssh.use_snc = true

mid.sa.ssh.use_sncssh = true

Documentation for above parameters/properties MID Server parameters MID Server properties Privileged Command Flow The following is the overall logic used when it is determined a privileged command must be used:

Check table dscy_priv_command_affinity to see if there are any privileged command affinities already set for this MID Server and target combination Result found in dscy_priv_command_affinity? Yes: End logic and use privileged command found in the affinity table No: Continue Loop through the privileged commands according to the priority set and attempt the command, see table ecc_agent_privileged_command_m2m 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 mid.sa.ssh.use_sncssh 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:

Is sudo the privileged command? Yes: Continue sudo logic No: End sudo logic Run "sudo -l" on the target server Compare output from "sudo -l" with command to be run Determine if use is allowed to run "sudo commandToBeRun" 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:

MID Server privileged commands 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:

/usr/sbin /usr/bin /bin /sbin 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:

SSHCommand path SSH Discovery parameters Troubleshooting 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.

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 Does dscy_priv_command_affinity table have records pointing to other privileged commands? Yes: Remove any incorrect affinities No: Continue 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 *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 *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 *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 Set MID server to debug and reproduce issue, see "Setup Debug" section of this kb 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:

mid.log.level = debug mid.ssh.debug = ipOfTargetDevice Related Links MID Server privileged commands