SSH fails to strip off sudo prefix for certain commands when disallowed in target host's sudoers fileDescriptionMID Server SSH is supposed to remove the "sudo " (or sudo alternative) prefix from a command before sending the command to target device if the command is disallowed by the target device's sudoers file.But SSH fails to strip off "sudo " prefix before sending command X in this case: if sudoers contains command Y with no arguments, and name Y matches the start of name X up to the length of name Y. This may trip security alarms on some target systems.Failure example: Command in probe is "sudo lsblk", and sudoers contains "entry /bin/ls" and no entry for lsblk. Result is MID server incorrectly sends "sudo lsblk" to the target device even though lsblk is not in sudoers file. In sudoers file, having arguments listed after the command name correctly causes MID server to strip off "sudo " prefix before running the command lsblk. Example: Command is "sudo lsblk"; sudoers contains entry "/bin/ls x" and no entry for command lsblk.Steps to Reproduce 1. Create non-root account myuser on the target Linux/Unix device.2. On target host, have a sudoers file that has this line:myuser ALL=NOPASSWD: /bin/ls3. Enable MID config param mid.log.level=debug4. Using credential myuser, run an SSHCommand probe to send the command "lsblk". Or can any command 3 or more characteers that starts with "ls".Notice in agent log there will be one line similar to this, showing it incorrectly ran lsblk command as sudo:DEBUG: Command being executed: PATH="$PATH:/usr/sbin:/usr/bin:/bin:/sbin";export PATH; sudo -S -p "___SNC_PWD_PROMPT___e03e1313bf0201101228d02f4ed8a63e" lsblkWorkaroundThis problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this article to be notified when more information becomes available.Related Problem: PRB1561762