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.