SSH Shell terrible slow on 2026.3.5.0 64bit RDM

Hello,

Could you please give 2026.3.8.0 a try? Also, which Workspace are you using?

Maybe the SSH logs can reveal the issue. Please refer to this KB topic for more information.

Regards,
Min

We’re using RDM with self-hosted DVLS and have encountered a similar regression with RDM 2026.3.x. I've also emailed support with some additional info.

We’re seeing a repeatable ~5–10 second delay launching SSH/SSH Tunnel sessions.

Tested

• DVLS 2026.02 + RDM 2026.2.17 / 2026.2.18 / 2026.2.19: Success
• DVLS 2026.02 + RDM 2026.3.5 / 2026.3.8: Issues
• DVLS 2026.03 + RDM 2026.3.8: Issues

Findings

• Existing vault, unfiltered navigation: slow
• Same SSH entry with a search filter active: fast
• New SSH entry in existing vault: slow
• New vault + new SSH entry: fast
• Fresh DVLS instance: fast
• Downgrading RDM 2026.3.x back to 2026.2.19.0 resolves it.

As recommended above, I enabled SSH ProtocolsSharp logs on a few entries. This narrows the delay to after the SSH KEX reply and before the server is reported as successfully authenticated. I have included example logs below.
---
[9/21/2026 12:40:22 AM] Devolutions.ProtocolsSharp: 2026.8.18.1 OS: Windows
[9/21/2026 12:40:22 AM] Starting SSH, verbose level: 2
[9/21/2026 12:40:22 AM] Connecting to: X.X.X.X:22 (IPV_ANY)
[9/21/2026 12:40:22 AM] SSH version banner: SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u7
[9/21/2026 12:40:22 AM] Sending kex init
[9/21/2026 12:40:22 AM] Received kex init
[9/21/2026 12:40:22 AM] Selected algorithms: sntrup761x25519-sha512(strict), ssh-ed25519, chacha20-poly1305@openssh.com, chacha20-poly1305@openssh.com, implicit by cipher, implicit by cipher, none, none
[9/21/2026 12:40:22 AM] Sending sntrup x25519 kex init
[9/21/2026 12:40:23 AM] Received sntrup x25519 kex reply

[9/21/2026 12:40:31 AM] Successfully authentified server

[9/21/2026 12:40:31 AM] Sending new keys message
[9/21/2026 12:40:31 AM] Received new keys message
[9/21/2026 12:40:31 AM] Starting public key authentication
[9/21/2026 12:40:31 AM] User authenticated successfuly using public key method
---

With a search filter active, the same sequence completes immediately with no delay between the KEX reply and Successfully authentified server.

This now looks less like a generic DVLS/RDM compatibility issue and more like an interaction between RDM 2026.3.x and existing vault/navigation state.

I updated to RDM to version 2026.3.8 and the problem still happens and is even worse as now ssh wont even login.
On one of my atemtps to login via ssh shell to one host i got this error "unable to read beyond the end of the stream"
I found devolution post https://forum.devolutions.net/topics/55345/unable-to-connect-to-certain-ssh-servers---unable-to-read-beyond-the-e end disabled mentioned there cipher but it didn`t help, also there were no changes to cipher in 2026.3.* changelog.


here is the log output:
----------------------- Terminal Log (Print Output) 9/21/2026 10:32:57 AM -----------------------

i tested another connection were i authorized with login and password not key, and once the login was fast, second time there was error that machine doesn`t allowe it, third time it connected after +30 seconds. On older version 2026.2.* everything was working perfectly and connection were instantly.

Hello,

I'm having a similar problem in both version 2026.3.5 and version 2026.3.8.
Connecting to various SSH servers always takes 25+ seconds.

Hi all,

Thanks for the detailed diagnostics, the verbose SSH log is very helpful. It narrows the delay window to between the KEX reply and the "successfully authenticated" step, and confirms it clears immediately when a search filter is active. That points us away from a generic SSH/DVLS compatibility problem and toward something in how RDM 2026.3.x resolves session/vault state for an unfiltered navigation tree before it finishes authentication — we're actively looking into that.

@przemyslawwirkus and @vladimir_holub — could you also grab a verbose SSH log the same way (KB: Send SSH shell logs and verbose) so we can confirm you're hitting the same signature?

@przemyslawwirkus — the "unable to read beyond the end of the stream" failure on 2026.3.8 looks like it may be a separate issue from the launch delay rather than the same regression getting worse. Is it reproducible on demand against that specific host, or intermittent? A verbose log from a failing attempt would help us tell whether it's related.

We'll keep this thread updated as we make progress.

Hi Carl,

I've yet to hear anything in response to the email support case, however, I'd like to note that this issue remains with the recently released RDM 2026.3.9.0.

I and my frient updated to 2026.3.10.0.
On my station i think the situation is better but i just started testing it.
On my friends station the problem still occurs. Also the SSH shell is very slow in responding after he is loged in. He can enter anty command for couple seconds and then the screen unfreeze.
I attached log from his station.

Thanks for highlighting the release of 2026.3.10.0. I had not noticed the release, as we typically rely on Intune deploying the package from the Microsoft Store.

It appears there is some delay between an RDM release being published and becoming available through the Microsoft Store. We have also noticed some inconsistency in Microsoft Store availability across the 2026.3 releases. I asked about the publishing process in a separate email request, which I have not yet received a response to. Ordinarily, a short delay in receiving an RDM release would go largely unnoticed. However, given the issues we have encountered across the 2026.3 releases, we are currently keen to adopt patch releases as soon as they become available.

I have since tested an upgrade from RDM 2026.3.9 to 2026.3.10 using DVLS 2026.3.5, as well as a completely fresh RDM 2026.3.10 installation. For the fresh installation, I removed %USERPROFILE%\AppData\Local\Devolutions, uninstalled RDM, removed the relevant registry configuration, and then reinstalled RDM.

Unfortunately, the SSH session launch delay that has affected us since RDM 2026.3 continues to persist in 2026.3.10.

Has there been any internal advancement on diagnosing this issue?

Hello Przemysław,
Thank you for your follow-up.
This is not something on your side. It is a known regression introduced in Remote Desktop Manager 2026.3.x. SSH Shell and SSH Tunnel sessions pause for roughly 15–30 seconds while connecting. We have reproduced the pattern across several customers and different SSH servers. The delay happens inside RDM itself, not on the network or on your SSH server, which is why native OpenSSH connects instantly from the same machine.
Our R&D and QA teams are actively investigating, and your case is linked to the internal ticket. I will update you as soon as a fixed build is available.
Workaround in the meantime: install RDM 2026.2.19.0, the last version without this delay. You can download it from our website's version history page: https://devolutions.net/remote-desktop-manager/release-notes/. Your data source and settings are not affected by the downgrade.
If you'd like to help speed up the investigation, you can send us an SSH verbose log from 2026.3.x:

1. Edit the SSH Shell entry → Advanced → set Verbose level to 3.
2. Connect once and wait for the session to open.
3. Send the log output.

Best regards,

Hey Carl,

Agreed that downgrading/rolling back is the definitive workaround, although this is not a straightforward option for us at scale. We would need to systematically uninstall RDM across the company, with the associated user disruption, before deploying the older version.

For staff who have elevation rights, we have already completed manual rollbacks where required. The larger issue is our frontline staff, who do not have those rights and therefore depend on centrally managed deployment. This is why we have been keen to “roll forward” instead, adopting patch releases as they become available.

In doing so, however, we have encountered a number of regressions across the 2026.3 series, including the SSH session-launch issue as well as various RDP rendering and UI issues. Some of these appear to have been introduced between individual 2026.3 patch releases rather than being present from the initial 2026.3 release.

From an operational perspective, this has made the non-LTS release stream feel less predictable than we would normally expect, particularly when deploying RDM broadly through Intune.

However, I understand that 2026.3 was an unusually significant release given the final transition to the new UI framework, and that this likely introduced a larger-than-normal surface area for regressions.

Hello,

Thank you for the additional context. We understand that rolling back is not a practical solution for a centrally managed deployment.

Our development team is actively working on a fix for this regression. I’ll update this thread as soon as a fixed build becomes available.

Best regards,

Awesome news. RDM 2026.3.12.0 looks to have resolved the SSH regression.

Thanks for all your efforts @Carl Marien.

Hello,

Thank you for confirming! I’m glad to hear that RDM 2026.3.12.0 has resolved the SSH issue on your end.

Thank you as well for all the detailed testing and feedback throughout the investigation. It was greatly appreciated!

Best regards,