Forum / Remote Desktop Manager Mac - Support

How to use system-level SSH agent?

  • Create an Issue
  • Cancel

I saw from many years ago (version 0.95?) a support topic whereby ssh-agent forwarding was added to RDM, but I can't find any mention of this in version 4.5.

I don't need RDM to do anything special, as I already use ssh-agent at the OS layer and I already have forwarding enabled in my ssh configuration file for the few hosts trustworthy enough wink Is there a way to make use of the ssh-agent already in place on the Mac level?

Clock2 yrs

Hi Jo,

I'm not entirely sure to know what you're talking about. Could you provide your exact user case or what you'd want RDM Mac to do? Do you happen to remember said support topic? Maybe it would help me to understand if I could see it myself.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Very simply, I can ssh in to nodes without retyping the key password every time at the OS layer because I'm using ssh-agent. Is there some way for RDM to use the system SSH so that I don't need to duplicate the key information into RDM?


$ ssh-add -l
4096 SHA256:X/taXxxXXYYxxddDDt5DSOJ+H/RlBtQDjA+o .ssh/id_rsa (RSA)

Clock2 yrs

The use case is for SSH tunnels. I've found lots of documentation around re-using sessions but it seems to be locked down to the Enterprise version. So right now I have to type the SSH key password every time I connect to any host.

Clock2 yrs

Here's the original topic: https://forum.devolutions.net/topic11790-ssh-agent-forwarding.aspx

You recommended altering ssh_config, which I have done. The question I have is why ssh-agent doesn't work? Do we need to pass in the agent socket?

Clock2 yrs

Hi Jo,

I think I see what the confusion is here.

We have two ssh terminal sessions: SSH Shell and SSH Shell (native). The former is our own integration of the SSH Terminal which as been integrated about 2 years ago, so long after the topic you're linking here. The suggestion of that topic only applies to the latter which simply launch an SSH session inside of the MacOS Terminal.

Tell me if I'm wrong in my understanding of your issue.

That being said, I've spoken with the dev responsible for our SSH Terminal session and the ssh-agent should be coming soon.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Yes that seems accurate. And I think I've discovered part of the problem. Neither SSH connection allows us to specify the location of the agent authentication socket. If we can configure this (globally would be best--few people run multiple ssh-agents) then I think it should work seamlessly.

Is there some option I'm overlooking to set environment variables for the invocation of ssh? All we need to do is set SSH_AUTH_SOCK

Clock2 yrs

In general I think the documentation needs some help here: there are tons of SSH options and no breakdown on what purpose each one has. Questions that come to mind are...

1. When to use SSH Tunnel versus SSH Tunnel (native)

2. I've found docs saying to create SSH Tunnels inside the RDP entry, then later ones saying to use an external entry, and then later ones saying to make an SSH VPN and which one provides which benefits is really unclear (mostly because I can't get anything but the simplest case working). There really needs to be a clear graph of features -> configuration

3. It appears that creating a VPN of SSH type is only available for Enterprise?


In general, which options are locked for Enterprise customers only -- breakdown of capabilities either way. I think right now it's just frustrating and thus you lose possible enterprise customers who can't figure it out.

Clock2 yrs

Well, the SSH Shell (native) sessions is simply a ssh command written directly into a new Terminal.app window. If it's not something that can be changed with ssh command parameters than it is definitely not something that the mentioned session supports directly.

Wouldn't you have to set the environment variable to something different before any new ssh sessions? I don't see any way in the Free Edition to get around this.

I do agree that sometime the documentation can get quite confusing, but we're always working on improving it and your feedback is most appreciated.

To answer your other questions:

1. Everything (SSH Shell, SSH Tunnel) with (native) in it is getting deprecated. It's not really about which one is better, but simply about which one is actively supported by us. The (native) sessions are kept for legacy support only. I'm currently hiding them behind the deprecated flag to diminish confusion.

2. This really only depends on your needs and workflow. Some people like to create separate SSH Tunnel sessions and RDP sessions for re-usability. Other simpler circumstances warrant only setting the tunnel directly inside the session. This is purely organizational, nothing more.

As for the differences between the SSH VPN and the SSH Tunnel (and Port Forward session to some extent), there are pretty much none. The two are functionally the same and just their purpose in RDM is slightly different. While the VPN is from the start designed to be accompanying a session on launch, the SSH session was initially designed as a standalone session (launched on it's own). This become a very negligible difference since both can accompany a session on launch.

3. Did you have trouble creating one? This should be available in RDM Free.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Apologies,

In my first statement I was referring to the SSH Shell (native) session and not the SSH Tunnel (native) session. The SSH Tunnel (native) use Rebex and not the macOS terminal. The session is still deprecated though and unlikely to be modified.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

Xavier Fortin wrote:


2. This really only depends on your needs and workflow. Some people like to create separate SSH Tunnel sessions and RDP sessions for re-usability. Other simpler circumstances warrant only setting the tunnel directly inside the session. This is purely organizational, nothing more.

As for the differences between the SSH VPN and the SSH Tunnel (and Port Forward session to some extent), there are pretty much none. The two are functionally the same and just their purpose in RDM is slightly different. While the VPN is from the start designed to be accompanying a session on launch, the SSH session was initially designed as a standalone session (launched on it's own). This become a very negligible difference since both can accompany a session on launch.

3. Did you have trouble creating one? This should be available in RDM Free.


I haven't been able to get any variant of the shared session working. When I choose "existing" and session and go to configure, the bar is greyed out and it says Enterprise only.

I can use a configured SSH session with the exact same information in each remote, but it's wasteful of sessions and requires me typing the very long passphrase so often that any advantage of pre-configuring the tunnels is pretty much wasted.

Clock2 yrs

Hi Jo,

I stand corrected. Linking to an existing session appears to be only available to the Enterprise Edition. This seems quite weird to me though since we can create VPN entries which have little uses if to be linked by other sessions.

In the last years, we've been going through a wave of unlocking more enterprise edition features in RDM Free. It might be that this should be one such feature.

I'll have to speak to someone more in the know of those Free Edition restrictions to be sure. I'll come back to you with more info.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

That would be hugely beneficial, and then possible for me to promote RDM within our company as a solution worth investing in. (which won't happen overnight unfortunately)

Clock2 yrs

Any progress on this?

Clock2 yrs

Hi Jo,

I'm sorry for reporting this late, I've forgotten to get back to you on this.

There are no plans currently to make this feature available into the Free version of the product.

Best regards,

Xavier Fortin

signaturesignature

Clock2 yrs

That's acceptance and understandable, but there really needs to be more obvious in both the UI and the documentation which features are Enterprise only. You have different binaries, this isn't gonna be that hard to accomplish.

Clock2 yrs