MFA caching for PSM SSH Proxy not working

Hello Daniil,

Thank you for the detailed description of both environments.

Based on what you described, the PSM SSH Proxy connection itself is working, but enabling “MFA caching” appears to switch the authentication flow to a session reuse/refresh path that fails (Env 1), and in the SAML scenario the flow completes the web login but then falls back to SSH keyboard-interactive authentication (Env 2), which is why you see an additional password-style prompt.

To proceed, could you share the following so we can confirm whether this is a product issue/compatibility issue or a configuration gap:

• Your Remote Desktop Manager version/build number.
• Environment 1:
  • The full text of both error dialogs (copy/paste if possible).
  • Logs from a failed attempt with MFA caching enabled, plus a successful attempt with MFA caching disabled (same entry), with approximate timestamps.
• Environment 2:
  • The full text of the interactive authentication prompt (it can be a key passphrase prompt presented as “Password”, or SSH keyboard-interactive depending on the proxy/server).
  • Logs from the same test.

For Environment 2 (SAML), it is also worth clearing the CyberArk SAML WebView2 cache and retrying, as stale tokens/cookies can cause the post-SAML handoff to misbehave. Steps are documented here:
https://docs.devolutions.net/rdm/kb/troubleshooting-articles/saml-configuration-troubleshooting-cyberark-dashboard/

If you need an immediate workaround to reduce repeated MFA prompts while we investigate MFA caching on the PSM SSH Proxy entry, using a CyberArk Dashboard entry with Auto Refresh enabled can maintain an active CyberArk session (so MFA is not required every time the session stays active), then launching PSM sessions from the dashboard:
https://docs.devolutions.net/rdm/kb/how-to-articles/cyberark-dashboard-configuration/

Additional references that may be relevant depending on the MFA method in use:

• CyberArk MFA delimiter option (RSA/SecurID “append code to password” behavior):
• https://docs.devolutions.net/rdm/kb/knowledge-base/mfa-delimiter-cyberark/
• CyberArk integration overview / related guides:
• https://docs.devolutions.net/rdm/concepts/advanced-concepts/external-pam-integrations/
• https://docs.devolutions.net/rdm/kb/knowledge-base/going-password-less-rdm-cyberark/
• 
  

Best regards,

Hello Patrick,

I'm currently using RDM version 2026.2.7.0 (64-bit). As for the requests:
Environment 1:

The first error message is just this window:



Then it disconnects me from the workspace and I have to log in again. Pressing Yes/No yields the same outcome:




I've attached RemoteDesktopManager.log, RemoteDesktopManager.log.db, RemoteDesktopManager.debug, and the error message. If needed, I can attach more logs or increase the debug level. Please provide instructions on obtaining them.

The connection was tested and the error reproduced on 5 June 2026, around 14:00+ CET. One thing I noticed is that the log complained about an untrusted web certificate, so as a test I added it to the trusted root store, but the result was the same.

Environment 2:

After updating to version 2026.2.7.0, I'm unable to replicate the original issue. It now behaves the same as Environment 1. I'll keep you posted if anything changes.

The suggested workaround wouldn't work for us, as that is a different type of connection. It's not possible to launch a PSM SSH Proxy connection from the Dashboard/PVWA.

Best regards,
Daniil

Hello Daniil,

Thank you for the logs.

They point to a clear explanation for why MFA caching specifically fails while the proxy works without it.

When MFA caching is disabled, Remote Desktop Manager sends your credentials directly to the PSM SSH Proxy over SSH, so the connection succeeds. When MFA caching is enabled, RDM must first authenticate to the CyberArk PVWA REST API to establish the cached session before opening the SSH proxy. That REST login is what is failing, and it surfaces as the "An error occurred while trying to connect to CyberArk" crash that disconnects you from the workspace.

The log shows two distinct failures on that REST call to the CyberArk endpoint (pvwa-cpm:443):

• A TLS certificate rejection: "The remote certificate was rejected by the provided RemoteCertificateValidationCallback."
• A TCP connection timeout: SocketException 10060 to pvwa-cpm:443 ("the connected party did not properly respond").

In other words, the SSH proxy itself is healthy. MFA caching cannot complete because RDM cannot reliably reach and trust the PVWA REST endpoint. This is why adding the certificate to the trusted root store alone did not resolve it.

To move forward, could you confirm the following:

• The exact CyberArk server address is configured in the PSM SSH Proxy entry. The log references a host named "pvwa-cpm" — please confirm this points to your PVWA component and not the CPM, as they are different roles.
• That this host is reachable on port 443 from the client machine. A quick test from PowerShell on that machine: Test-NetConnection pvwa-cpm -Port 443 (and, if possible, opening https://<pvwa-address>/PasswordVault in a browser on the same machine).
• The certificate presented by that endpoint: its full chain (is an intermediate missing?) and its Subject/SAN values, so we can confirm the certificate is actually issued for the hostname RDM connects to. A SAN mismatch or incomplete chain would explain a rejection even after trusting the root.

Once the PVWA REST endpoint is consistently reachable and its certificate validates cleanly against the configured hostname, MFA caching should proceed normally.

Best regards,

Hello Patrick,

The PVWA/CPM address is correct, as I set up this CyberArk instance specifically to test MFA caching with RDM. However, you might be right about the certificate chain or some misconfiguration on my side, so I moved to the second environment, where I'm confident the trust and connections are set up correctly. The downside is that I'm limited on how much I can change on the CyberArk side.

After some additional troubleshooting, I found a few things that were causing issues.

For a connection through PSMP, we normally use a string like:

ssh -i key.file primaryAccount@domain@targetAccount#domain@targetServer@proxyServer

To make this work, I had to configure the CyberArk PSM SSH Proxy entry as follows:

1. Set the username to primaryAccount@domain
2. Enable "Use MFA Caching" and fill out the configuration as documented

I had originally assumed that the username would not need to be provided, since it should be available from the SAML connection. That assumption was wrong.

Then in the SSH Shell entry:

1. Set the host to targetServer
2. Set the username to targetAccount#domain (if the target account is local, just use targetAccount)
3. Set VPN/Tunnel/Gateway to the configured CyberArk PSM SSH Proxy entry

With this setup, MFA caching works correctly. On the first connection, RDM prompts for SAML logon, and after that the SSH connection goes through seamlessly.

One additional issue I encountered:

Credential saved in the User Vault as "Primary Account login":

• Username: username
• Domain: domain
• Password: ****

Then in the PSM SSH Proxy entry:

• Credentials: Find by name (User Vault) > "Primary Account login"
• Advanced > Username format: {User}@{Domain}

What I would expect with this configuration is that the resulting string matches the format above. However, after examining the logs, the domain is not included. The resulting string looks like primaryAccount@targetAccount... instead of primaryAccount@domain@targetAccount....

Fortunately, this is not a dealbreaker, as it can be worked around by extending the username in the credential entry to username@domain. With that change, the string is constructed correctly. This is workable for now and doesn't crash the application.

I'll test this in one more environment that uses RADIUS authentication instead of SAML, to confirm the settings are correct. I don't have direct access to that environment and will need to coordinate with a colleague, so my next response may be slightly delayed.

Thanks,
Daniil