The dropdown that lists available scripts for type 'SSH Script Advanced' is blank and I can't figure out why.

Other SSH sensors against this target work great.
The following directories exist: /var/prtg, /var/prtg/scripts, and /var/prtg/scriptsxml
These directories have '777' permissions to ensure it's not a permissions issue.
This target is accessed by PRTG using the root credentials.

No errors are given in the PRTG web UI, so I have nothing to start my troubleshooting.


Article Comments

Hello,

first troubleshooting in this case would be if the sshd actually gets a connection request from the PRTG server. Depending on your used sshd there are different troubleshooting steps required for this

Please also check the remarks in Monitoring via SSH in our manual regarding remarks and possible limitations like usable encryption ciphers.


Kind regards,
Johannes Beyerlein, Technical Support Team


Dec, 2022 - Permalink

For those of you following along at home...

Start by logging in to the PRTG console and pause all of the sensors pointing at your target so additional SSH traffic will not be logged.

Obtain the IP address of your probe: "aaa.bbb.ccc.ddd". Use this IP address to filter the SSHD logs on the target.

journalctl -t sshd -f | grep -i 'aaa\.bbb\.ccc\.ddd'

Look at the last timestamp in the log as shown on screen. Ignore this date and everything that came before it.

Go back to PRTG and add a new sensor to this VM. Technology Used? SSH Monitor What? Custom Sensors Choose: "SSH Script Advanced"

At this point, the web browser will show a spinny wheel for 2 or 3 seconds, then present a page to select your custom script. Also during this time, a new log entry should show up on the target system showing how the probe attempted and succeeded or failed.

In my case, the log on attempt succeeded. So yes Johannes, SSHD actually gets a connection request from the PRTG server and it succeeded. What is the next troubleshooting step?


Dec, 2022 - Permalink

Hello,

PRTG uses the following commands to retrieve a list of the available scripts.

LANG=C ls -la /var/prtg/scripts/ | grep [w-]''x''[r-] | awk '!/^d/ {for (i = NF; i >= 1; i--) { if (($i ~ /^[0-9][0-9]:?[0-9][0-9]$/)) {for (j=i+1; j <= NF; j++) { if ($j == "->") break; printf $j } break;}} print ""}'

LANG=C ls -la /var/prtg/scriptsxml/ | grep [w-]''x''[r-] | awk '!/^d/ {for (i = NF; i >= 1; i--) { if (($i ~ /^[0-9][0-9]:?[0-9][0-9]$/)) {for (j=i+1; j <= NF; j++) { if ($j == "->") break; printf $j } break;}} print ""}'

Please make sure to have your scripts executable, otherwise it will not show up.
Please also make sure you have ls, awk and grep available in your SSH shell.
If there are no scripts showing up here, then the sensor won't show any sensors in the selection menu.


Kind regards,
Johannes Beyerlein, Technical Support Team


Dec, 2022 - Permalink

AH HA!!!!

The commands you posted above were failing at grep. PRTG was configured to use a specific account to talk to this Linux box. I connected via SSH using that account to run this command... LANG=C ls -la /var/prtg/scriptsxml/ | grep [w-]''x''[r-] ...which would fail with this message: zsh: no matches found: [w-]x[r-]

When I saw "zsh" in the output, I started to get suspicious. I created a new account on the Linux VM and ensured that its environment used bash instead of zsh. Then I updated the account credentials that are registered inside PRTG and attempted to add another custom sensor. This time the names of the scripts appeared in the list.

Problem solved.


Dec, 2022 - Permalink

Thank you for this information!

Glad you found the issue and could resolve this.
I will keep this for the future in mind, that our current script requires bash as default shell for this sensor and will relay the information to my team.


Kind regards,
Johannes Beyerlein, Technical Support Team


Dec, 2022 - Permalink