SSH through Jump Agent gives protocol error

SSH through Jump Agent gives protocol error

avatar

Hi,

I installed RDM and RDM Jump onto a Windows server. On my local machine I have RDM installed too. Both are on v2025.2.28.0 (free).

I want to connect to a Switch over SSH, but this requires custom algorithm support and the Jump host to be used, due to firewall rules.

On my local machine I created an SSH terminal entry with:

  • The IP address of the switch as Host
  • All algorithms enabled on all tab pages of the custom algorithm support window
  • The correct credentials
  • The "Connect using Jump" option enabled.


When I open this session, the SSH session is opened in the RDP window of the Jump host but fails with a "Protocol Error". If I temporarily disable the firewall rule and disable the "Connect using Jump" option, I the session works as expected.

I created the same entry in RDM on the jump host, without enabling Connect using Jump, the session opens without error. So the jump host is allowed to access the switch on port 22.

The log of the switch shows:

 %SSH-3-NO_MATCH: No matching mac found: client hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 server hmac-sha1,hmac-sha1-96

All Comments (7)

avatar

Some additional information. I used my Devolutions Hub Personal data source on both machines and noticed that the entry was not working on the jump host when using "Direct (no RDM Jump)". When I edited the entry on the jump host, I checked the Custom algorithm settings and found them not all checked as they are on my local machine using the same data source. After checking all algorithms the session works on both machines by either using Jump or not.

Is there a logical explanation for this?

avatar

Hello,

Thank you for reaching out to us regarding this,

Did you have the Algorithms enabled in the SSH Sessions Properties or globally under File – Settings – Entry types – Sessions – Terminal – Algorithm support?

Let me know,

Best regards,

Samuel Dery

avatar

@Samuel Dery

Although all is working now, there is still a flaw in this somewhere.

So, if I temporarily add the same data source used on the the local client to the remote jump host, and I, again, check all Algorithms in each session config on the remote jump host, it works. When I switch to a different data source locally, it is not working any more. So when using Algorithm settings within a session, they are not respected on the remote jump host.

I tried with two different data sources on both machines and I enabled all algorithms globally on the jump host under File – Settings – Entry types – Sessions – Terminal – Algorithm support. Again leading to a Protocol Error. This was still when using a session with its own algorithm settings. After setting the Algorithm support to default all went well.

So, long story short: using custom algorithm settings in a session, requires using the same shared data source on both the local client and the remote jump host. Using the global approach makes both machines work independently when it comes to custom algorithm settings.

avatar

Hello Jasper,

Thank you for your reply,

I see, I believe I can reproduce the behavior. I'm unsure what would be expected in this case, and will need to confirm.

I will keep you updated with any news I receive,

Best regards,

Samuel Dery

avatar

Hello Jasper,

Thank you for your patience,

I wanted to inform you that following my discussion with the development team, I have created an internal case for your issue.

It has been linked to your forum thread and we will keep you updated with any news we have,

Best regards,

Samuel Dery

avatar

Patiently waiting upon the outcome of your discussion, I was thinking this over once more and just want to add something to your discussion. For me it seems a security flaw when I need to enable insecure algorithms on a global level.

avatar

Hello Jasper,

Thank you for your reply,

As mentioned in my previous reply, following my discussion with our development team, I created an internal case to resolve this issue.

It has been linked to this thread so that we can keep you updated with any news we have,

Best regards,

Samuel Dery