When using J2SSH and sudoers on target does not have either "ALL" rights, or explicit rights to the sudo command itself, the probe fails because sudo is sent twice to the target.
Although using SNCSSH is recommended, it is sometime necessary to use J2SSH as a workaround for some other problem with Discovery SSH probes.
This issue was introduced in Kingston.
You can see this from the MID Server agent log with debug log level turned on: e.g.
sudo -p '===Service-Now_Password_Prompt===' sudo dmidecode …
Steps to Reproduce
- Enable MID server property: mid.property.ssh.use_snc=false to force use of J2SSH instead of SNCSSH. Restart MID Server.
- Pick target host where sudoers does not have either "ALL" rights, or explicit rights to run sudo command itself, but does have rights to run the shell command in the probe used in step 2.
- Using a non-root user credential, run one of the below probes:
Linux - Hardware Information (dmidecode)
Linux - Memory Modules (dmidecode)
Unix - Active Connections (lsof)
A few workarounds may be possible in your environment:
- Set Mid server property "mid.property.ssh.use_snc" to true
- Make sure that the sudoers does have either "ALL" rights, or explicit rights to run sudo command itself
- Edit the 4 probes to remove the "sudo " prefix from command string in the ECC Queue Name field. If you later decide to enable SNC SSH per workaround #1, you will need to add "sudo " prefix back in again if you run these probes on any targets which run an unsupported shell.
Related Problem: PRB1315435