jarredburrowes

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

Thanks for all your efforts @Carl Marien.

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.

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?

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.

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.