What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Why does my SSH sensor show an error after updating PRTG?

Votes:

0

After updating PRTG to version 17.1.29, an SSH sensor on a specific Linux device is in down status in my PRTG installation. It shows this error message:

Failed to read password prompt from shell (1). Reason: read_password_prompt timeout

An SSH sensor on another device shows this error message after the update to PRTG 17.1.29:

Failed to read paessh command from shell (1). Reason: read_paessh timeout

Where does this SSH error come from? Is this SSH sensor issue related to the new sudo option in the Linux/SSH section of group and device settings? How can I fix this SSH failure?

error error-messages prtg ssh sudo

Created on Feb 23, 2017 6:22:21 PM by  Gerald Schoch [Paessler Support]

Last change on Feb 27, 2017 1:42:20 PM by  Gerald Schoch [Paessler Support]



3 Replies

Accepted Answer

Votes:

2

This article applies to PRTG Network Monitor 17.1.29 or later

How to Fix SSH Sensors That Stop Working in PRTG 17.1.29

PRTG version 17.1.29 includes several important fixes and improvements for the SSH engine that SSH sensors use by default to retrieve monitoring data from a target device. Among others, SSH rights elevation works more reliable after the update to PRTG 17.1.29 or later.

New Option for SSH Rights Elevation

For this purpose, we added the option to run SSH commands using sudo with an explicitly defined password. You can choose this option for the setting SSH Rights Elevation in section Credentials for Linux/Solaris/Mac OS (SSH/WBEM) Systems of group and device settings.

  • If sudo does not require a password on the target device, choose the new option Run the command as another user using ‘sudo’ (without password).
  • Otherwise, choose the sudo with password option and enter the target user and according password below. This is also the pre-selected option if you have used sudo in previous PRTG versions and might be the cause for your SSH error.

Credentials for Linux/SSH

In previous PRTG versions, SSH sensors tried to run sudo commands with the password specified for the Login. They only tried it without a password if the login password did not work and caused a timeout. The new option to define if sudo requires a password or not makes SSH rights elevation more reliable.

Fixing Red SSH Sensors after Update

After updating PRTG to version 17.1.29 (or later) from PRTG 17.1.28 (or earlier), this change for SSH rights elevation can cause SSH sensor errors in two specific cases. Both are password related and require a change in your Credentials for Linux/Solaris/Mac OS (SSH/WBEM) Systems settings.

(1) read_password_prompt timeout

The first SSH failure case is if you get this error message:

Failed to read password prompt from shell (1). Reason: read_password_prompt timeout

You will receive a read password prompt timeout if you have used the option Run the command as another user using ‘sudo’ in PRTG versions previous to 17.1.29 but sudo does not require a password.

In this case, select the option Run the command as another user using ‘sudo’ (without password) and your SSH sensors will start working again.

Note: Use Multi-Edit to change this option on all devices and groups at once if required.

(2) read_paessh timeout

The second SSH failure case is if you get this error message:

Failed to read paessh command from shell (1). Reason: read_paessh timeout

You will receive a read paessh timeout if you have used the option Run the command as another user using ‘su’ in previous PRTG versions and defined a password for su, but changed to sudo later.

In this case, PRTG used the password that you have specified for the Login to run a command with sudo. After the update PRTG will use the su password again which is still stored in the PRTG configuration. If the passwords are different, the command will fail.

Please enter the correct password for sudo and your SSH sensors will start working again.

Note: Use Multi-Edit to change this option on all devices and groups at once if required.

More

In general, increase the scanning interval of SSH sensors in case of such timeout errors. Check also the target server for jobs that might slow it down and cause timeout errors.

Created on Feb 23, 2017 6:43:11 PM by  Gerald Schoch [Paessler Support]

Last change on Jan 24, 2018 11:55:45 AM by  Gerald Schoch [Paessler Support]



Votes:

0

Hi,

I too am receiving the error "Failed to read paessh command from shell (1). Reason: read_paessh timeout" but your answer didn't fix my problem. I am trying to use SSH Disk Free on two Linux/Unix machines. Before the 17.1.29 update I was using SSH Rights Elevation: Run the command as the user connecting (default). I never used sudo or su before the update. I also have virtual systems running SSH Disk Free which have different username and passwords credentials than the Linux machines. Any ideas why the "read_paessh timeout" is occurring? Thanks

Created on Mar 28, 2017 8:09:38 PM



Votes:

0

Hi nsills,

Have you tried if switching to the other options makes the sensor work again? Otherwise please enable "Write result to disk" in the sensor's "Settings" tab. With the next scan it will write one or several result-files into "C:\ProgramData\Paessler\PRTG Network Monitor\Logs (Sensors)" of your PRTG server (or on the Remote Probe if applicable). All files have the sensor's numeric ID in their filenames. The sensor ID can be found on the sensor's "Overview" tab. Please send us those result-files by email, use "PAE847337" in the subject, that way it stays related to this thread.

Kind regards,

Erhard

Created on Mar 29, 2017 1:09:25 PM by  Erhard Mikulik [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.