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 do my SSH sensors show encryption errors?

Votes:

0

When trying to monitor SSH sensors, I get the following error message in PRTG: The negotiation of encryption algorithm is failed.

What is the reason for this problem? What can I do?

aes cbc cipher ctr encryption error error-messages prtg security ssh

Created on Oct 9, 2013 11:19:01 AM by Gerald Schoch [Paessler Support]



34 Replies

Accepted Answer

Votes:

1

Important note: PRTG includes a new SSH engine as of version 16.2.24 to provide best performance and security for your SSH sensors. Please consider this SSH engine as beta: it still does not support all OpenSSH libraries but we are working on it.

If PRTG's new SSH engine does not yet work in your case, you can still use the old SSH engine as legacy version: select the Compatibility Mode for SSH Engine in the sensor or device settings. In this case, please consider the article below.

This article applies to PRTG Network Monitor 13 through 16.2.23

SSH Sensors and Encryption Errors

PRTG uses an underlying component that currently only provides Cipher Block Chaining Mode (CBC) for encryption of data. Though, encryption with a CBC based cipher is potentially vulnerable to the Plaintext Recovery Attack Against SSH. This security vulnerability may allow a remote unprivileged user to gain access to a portion of plain text information from intercepted traffic.

Because of this security issue, more and more distributions (for example, Solaris 11 and VMware vCenter 5.5) do not accept connections with CBC ciphers by default anymore. Instead, they accept ciphers with Counter mode (CTR) only.

When the ciphers of client and server (CBC vs. CTR) do not match, the handshake will fail and your SSH sensors show the “negotiation of encryption algorithm is failed” error message.

If your SSH sensors show this encryption failure, check also the kernel messages of your Linux distribution with the command dmesg

The corresponding error message will look like this: Client and server could not agree on a common cipher: […]

For details about this security vulnerability in CBC mode, see

Diffie-Hellman Key Exchange (D-H)

The described issue also applies to the Diffie-Hellman key exchange method. SSH sensors currently do not support this method of exchanging cryptographic keys. You see an error message like "Server does not support diffie-hellman-group1-sha1 for key exchange" in this case.

Workaround

Currently, the best recommendation to avoid this issue is to try using other monitoring technologies than SSH. Add, for example, SNMP sensors as an alternative:

Another alternative is to add a weaker cipher to the ssh_config again.

Important notice: Do this at your own risk. We do not recommend it!
However, this approach may be a valid solution in a secure environment (LAN, VPN).

For details, please refer to linuxmanpages.com: SSHD_CONFIG.

Created on Oct 9, 2013 11:22:47 AM by Gerald Schoch [Paessler Support]

Last change on May 13, 2016 1:09:28 PM by Gerald Schoch [Paessler Support]



Votes:

0

Hi

When will there be a server side fix for these SSH sensor's ?

Ie at what point will the underlying component be updated to support CTR counters

Thanks

Created on Jan 7, 2014 2:52:19 PM



Votes:

0

Hello, we are sorry that we cannot answer this question, we still wait for this update. Best Regards

Created on Jan 7, 2014 4:28:37 PM by Waltraud Bestelmeyer (110) ●2 ●1



Votes:

0

Any progress on resolving this issue? We're still seeing these diffie-hellman-group1-sha1 key exchange errors for ssh sensors as of PRTG 15.1.15.1864+. Thanks, Ivan

Created on Apr 2, 2015 9:51:55 AM



Votes:

0

Andrew, I'm sorry this has not been changed, nor are the plans to change it in the near future. Sorry.

Created on Apr 7, 2015 9:53:57 AM by Torsten Lindner [Paessler Support]



Votes:

0

We now also are having problems with SSH sensors. We have upgraded our SFTP server to openSSH 6.9 and openssh is now disabling older cipers and protocols at built time. Hopefully Paessler will be supporting the latest ciphers at some point.

They old ciphers are being disabled because of security issues.

I have disabled these sensors for now (disk space)

Created on Aug 4, 2015 1:55:44 PM



Votes:

1

it is nearly two years since the topic has been opened... not a good performance at paessler, or?

Created on Aug 18, 2015 12:12:23 PM



Votes:

0

Fritz, we still have this on our list, and also its security implications on our mind. It is a rather complex task though, as it will mean a complete re-write of our SSH Sensor engine. So nothing to take lightly. Please bear with us.
We do see the point and value in this request of course, have to decide how we 'use' the limited developer time we have, to implement features which benefit all or at least most of our PRTG users (also with all points to this SSH discussion in mind).

Created on Aug 19, 2015 2:18:12 PM by Torsten Lindner [Paessler Support]



Votes:

1

Not a good statement from PRTG, as we are getting dinged on audits and had to disable the weak ciphers... and really do need to use ssh monitors due to inflexibility of built in PRTG monitors. Our management is now making us consider a different vendor's monitor due to this issue.

Created on Sep 16, 2015 2:24:09 PM

Last change on Sep 17, 2015 4:28:27 AM by Felix Saure [Paessler Support]



Votes:

0

Hi, as mentioned above, we are aware of the incompatibility of the SSH sensors and are working on an update. This requires extensive changes in the source code, so I'm afraid that I cannot give you an exact date for the release yet. Please bear with us.

Best regards, Felix

Created on Sep 25, 2015 7:43:46 AM by Felix Saure [Paessler Support]



Votes:

2

Hi Our monitoring solution also depends on SSH sensors, so I most urgently would ask you to prioritize rewriting the SSH engine. Thanks, Jon

Created on Nov 26, 2015 12:31:15 AM



Votes:

0

It's in the works already :)

Created on Nov 26, 2015 10:51:37 AM by Stephan Linke [Paessler Support]



Votes:

0

Any news on this fix for the SSH handshake and using the latest ciphers

Created on Jan 12, 2016 11:44:06 AM



Votes:

0

The latest version already should support the symmetric ciphers AES192 and AES256. What version are you currently running?

Created on Jan 12, 2016 12:26:58 PM by Stephan Linke [Paessler Support]



Votes:

0

Im on version 15.4.21.5216 ... im just running an update ;-)

Created on Jan 12, 2016 12:53:30 PM



Votes:

0

That version already should support it... Did you try to recreate the sensors?

Created on Jan 12, 2016 12:55:54 PM by Stephan Linke [Paessler Support]



Votes:

0

Ok I have updated to version 15.4.21.5482 deleted old sensors and recreated new ones for Memory, load average and Disk. All SSH based and they still fail with authentication errors

I can log in ok via SSH onto the server using the credentials using an SSH client.

I will check which cyphers are in our corporate build

Created on Jan 12, 2016 1:15:35 PM



Votes:

0

Alright, let me know :) The SSH framework also just got revamped (but that hasn't reached the stable or preview builds yet); this might also be helpful once it's released.

Created on Jan 12, 2016 1:28:27 PM by Stephan Linke [Paessler Support]



Votes:

0

Where are we up to with this?

We have been using SSH sensors to monitor HP MSA and P2000 SANs due to their lack of useful SNMP and PRTG not supporting SMI-S however as of the latest firmware for these devices, it appears they are no longer support CBC mode and we are getting "The negotiation of encryption algorithm is failed" errors on all of the sensors.

I appreciate you are working on it as noted. I was hoping we would be closer to an ETA given the most recent comments regarding the SSH framework revamp.

Created on Mar 8, 2016 11:40:37 PM



Votes:

0

The new SSH framework is (should be) currently in the Canary channel of PRTG. Can you set up a test instance of PRTG on a VM, set the update channel to canary and test it with your MSA?

Created on Mar 9, 2016 8:33:46 AM by Stephan Linke [Paessler Support]



Votes:

0

Is your P2000 running the latest available firmware?

Created on Mar 17, 2016 1:05:48 PM by Stephan Linke [Paessler Support]



Votes:

0

""Another alternative is to add a weaker encryption system to ssh_config again.""

Based on a possible temporary solution. Someone could show me how to modify the ssh config, which parameters should perform so you can comunicarser with ssh sensor prtg.

Created on Mar 31, 2016 8:18:24 PM



Votes:

0

Open up /etc/sshd/sshd_config with an editor of your choice and search for the line starting with Ciphers. Make it look like the following line: 

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Restart your SSHd service and PRTG should be able to connect again.

Created on Apr 4, 2016 11:35:23 AM by Stephan Linke [Paessler Support]



Votes:

1

I have updated my Mac Mini to "El Capitan" and since then I got errors on my PRTG dahsboard like "the negotitation of encryption algorithm is failed". It runs PRTG Network monitor 16.1.211422. The SSH configuration on Mac OSX is stored in /private/etc/sshd_config . I edited "/private/etc/ssh/sshd-config" and added the aforementioned lines to sshd_config as they were not there yet, en restarted sshd . To stop and start sshd:

 sudo launchctl stop com.openssh.sshd
 sudo launchctl start com.openssh.sshd

It works!

Created on Apr 13, 2016 2:40:25 PM



Votes:

0

Thanks for sharing, Paul! :)

Created on Apr 13, 2016 3:49:52 PM by Stephan Linke [Paessler Support]



Votes:

0

In response to Stephan Linke [Paessler Support].

Sorry for not replying sooner. Our MSA is at current firmware GL220R005(A).

We have PRTG build 16.2.24.3686 running and with the new SSH libraries we no longer get encryption errors.

However, what we are now seeing is SSH time outs such as "Timed out while waiting for SANs response. It might help to restart the SSH controller. (code: PE241)".

We know SSH is working because we can SSH to the SAN from the same server as the PRTG Probe without any issues.

Created on May 14, 2016 6:21:17 AM



Votes:

0

The problem is known and we're working on a fix :)

Created on May 16, 2016 6:30:33 AM by Stephan Linke [Paessler Support]



Votes:

0

Any News on this? also getting "Timed out while waiting for SANs response. It might help to restart the SSH controller. (code: PE241)"

Created on May 24, 2016 7:23:11 AM



Votes:

0

As of right now, the SAN still is not working properly with our SSH sensors and we'll need more time to debug this. Sorry for the inconvenience!

Created on May 24, 2016 7:49:03 AM by Stephan Linke [Paessler Support]



Votes:

0

Latest build 16.2.24.4274 appears to have fixed this. Thanks!

Created on Jun 9, 2016 10:32:22 PM



Votes:

0

Dear All,

my apologies for bringing up again this apparently long retired subject.

I wonder as to the status of support for "diffie-hellman-group-exchange-sha256" in the ssh framework von PRTG v18.4.47.* as I have a proprietary device, forcing me to use said cipher algorithm.

Any help would be greatly appreciated.

Many thanks in advance and kind regards

Christopher

Created on Feb 20, 2019 10:28:26 AM



Votes:

0

You should be able to use the compatibility mode in the Linux Credential settings of the device (under "SSH Connection"). Let me know if it worked :)

Created on Feb 21, 2019 1:15:33 PM by Stephan Linke [Paessler Support]



Votes:

0

Dear Stephan,

Many thanks for your reply.

When using compatibility mode I get

"invalid key exchange algorithm"

For the avoidance of doubt, I presume the sensor needs to be deployed vis-á-vis the controller directly and not the service processor?

Created on Feb 22, 2019 9:19:59 AM



Votes:

0

I'm not sure I understand the last sentence correctly :( Would something like a reverse SSH Proxy work by any chance? Something like outlined here.

PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Feb 22, 2019 12:58:43 PM by Stephan Linke [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.