after switch to macos, SSH connections don't work

after switch to macos, SSH connections don't work

avatar

I am using RDM on MacOS, coming from Windows. Problem is, that SSH connections don't work. I get asked to confirm the fingerprint (twice for whatever reason) and get these messages, then the session closes immediately.

Screenshot 2026-02-09 at 18.22.17.png
Screenshot 2026-02-09 at 18.22.31.png

Screenshot 2026-02-09 at 18.22.31.png

Screenshot 2026-02-09 at 18.22.17.png

avatar

Recommended Answer

Hello perler,

This points to an SSH algorithm negotiation mismatch in RDM’s macOS SSH stack (client side). Your Ubuntu server offers only ssh-ed25519 for the host key; if RDM had that (or related modern algorithms) disabled, the handshake can fail even though macOS Terminal works. Enabling “Algorithm support” in RDM expands what the client offers, which is why it resolved the issue.

SSH algorithms are negotiated between client and server; you typically adjust the more restrictive side. If you want to stay strict, enable only the modern options needed (avoid legacy algorithms). A feature request to show which algorithm/category failed (kex/hostkey/cipher/mac) would be the right way to improve the error message.

Best regards,

Carl Marien

All Comments (11)

avatar

Hello,

Thank you for contacting Devolutions Support.

I suspect this issue may be related to an algorithm that is not supported in the macOS version of Remote Desktop Manager. Could you please let us know the model of the machine you are trying to connect to? Also, are you able to connect via SSH using another application?

Best regards,

Carl Marien

avatar

these are normal ubuntu machines, 22.04 and 24.04. I can connect from macos terminal. But I remember having similar problems with older SSH connections even under windows and as I am usually copying SSH connections these settings might be even 10 years old.. But I am having trouble finding the algorithm settings in macOS.

avatar

Hello,

You can find the algorithm support option by going to File > Settings > Type > Terminal, then scrolling all the way down.

Please let me know if enabling algorithm support resolves the issue.

Best regards,

Carl Marien

avatar

Thanks, I just enabled every option and it works now. As I remember, we had the same problem in a new install on Windows, so I think it would be helpful that when such an error occurs that you display the algorithm which is asked for in the error message.

I wonder, is this an algorithm which is asked for by the server or is it an algorithm defined in our SSH terminal sessions? So which side of the connection do we need to edit to make this current?

avatar

Hello,

I am not sure whether it is possible to list if a specific algorithm required for establishing an SSH session is missing. However, I would suggest submitting a feature request for this functionality.

Regarding your question: SSH algorithms are negotiated between the client and the server. The server provides the list of supported algorithms, the client proposes its own list, and a compatible match is selected. Therefore, you would need to adjust the configuration on the side that is more restrictive (often the client, especially if legacy algorithms are disabled).

You can list the supported algorithms on your system using the following commands:

ssh -Q cipher
ssh -Q mac
ssh -Q kex
ssh -Q key

Best regards,

Carl Marien

avatar
Therefore, you would need to adjust the configuration on the side that is more restrictive (often the client, especially if legacy algorithms are disabled).

Okay, but wouldn't this mean that the default algorithms selection in RDM is a bit too restrictive? We try to connect to a standard, almost virgin Ubuntu server. This should work out of the box I think..

avatar

Hello,

To be fully transparent, this is the only forum where I’ve heard that the default Ubuntu installation does not support the default algorithm from RDM.

Best regards,

Carl Marien

avatar

Absolutely, it could be our problem, that's what i try to find out. We setting up ubuntu servers since 8.04 ;) and it may be, that we copy over confugurations (although I am not really aware that we do this with sshd configs). here are the supported algorithms at one of these servers:

Server SSH Algorithms

Key Exchange (KEX) Algorithms

- curve25519-sha256
- curve25519-sha256@libssh.org
- ecdh-sha2-nistp521
- ecdh-sha2-nistp384
- ecdh-sha2-nistp256
- diffie-hellman-group16-sha512
- diffie-hellman-group18-sha512
- kex-strict-s-v00@openssh.com (Terrapin attack mitigation)

Host Key Algorithms

- ssh-ed25519 (only algorithm offered)

Ciphers (both directions)

- chacha20-poly1305@openssh.com
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com

MACs (both directions)

- umac-64-etm@openssh.com
- umac-128-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512-etm@openssh.com
- hmac-sha1-etm@openssh.com
- umac-64@openssh.com
- umac-128@openssh.com
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1

Compression

- none
- zlib@openssh.com

Authentication Methods

- publickey
- password

avatar

Hello perler,

This points to an SSH algorithm negotiation mismatch in RDM’s macOS SSH stack (client side). Your Ubuntu server offers only ssh-ed25519 for the host key; if RDM had that (or related modern algorithms) disabled, the handshake can fail even though macOS Terminal works. Enabling “Algorithm support” in RDM expands what the client offers, which is why it resolved the issue.

SSH algorithms are negotiated between client and server; you typically adjust the more restrictive side. If you want to stay strict, enable only the modern options needed (avoid legacy algorithms). A feature request to show which algorithm/category failed (kex/hostkey/cipher/mac) would be the right way to improve the error message.

Best regards,

Carl Marien

avatar

Yes, you are right, we harden our servers to offer only ED25519, so we need to keep this in mind, when we set up a new PC with RDM.. fingers crossed ;)

thanks!

avatar

Hello perler,

Thanks for confirming glad enabling the SSH algorithm support resolved the issue.

I’ll go ahead and close this forum thread for now. If you run into any further trouble or want to revisit the configuration (e.g., keeping it strict while ensuring ED25519 works out of the box), feel free to reopen the thread and we’ll continue from there.

Best regards,

Carl Marien