Devolutions Gateway SSH port forwarding for non-RDM connections

Devolutions Gateway SSH port forwarding for non-RDM connections

avatar

I am trying to setup Devolutions Gateway for ssh port forwarding from an external vendor to internal servers. I have it working for users of RDM, but the vendor will be using scripting. I found references to this situation in the documentation under DG Tunnel connection type, however that seems to be setting up a connection inside RDM. I'm not sure how to make the setup an automatic connection similar to Linux SSH gateways. I also want to protect it with a domain credential instead of a Devolutions credential. Is that possible or do I need to look elsewhere?

All Comments (3)

avatar

Hello,

Thank you for reaching out to us regarding this,

I see, I suspect the Gateway Tunnel entry type would be what you are looking for, we have the following knowledge base article regarding this:
https://docs.devolutions.net/dgw/kb/knowledge-base/gateway-tunnel/

Let me know if this helps,

Best regards,

Samuel Dery

avatar

Unfortunately, that doesn't help. I mentioned that I followed that part of the documentation, however it's a connection in the vault. Once the connection is setup, is it running at all times or does it require user intervention? The documentation is not clear about that.

Also, how do I assign a domain credential instead of a Devolutions credential?

avatar

Hello Shanemartinez,

When you're using Devolutions Gateway outside of Remote Desktop Manager (RDM) such as when a vendor is using scripts or direct SSH commands DG by itself does not act like a typical SSH jump host
What the statement means:
For non-RDM/scripted access, you can’t simply “tunnel through” DG as if it were a standard SSH gateway. DG doesn’t expose an open SSH port for general forwarding like a Linux server would.
Instead, what you need is an intermediate component (sometimes called a listener or proxy server) that:

  1. Receives the incoming SSH request from the vendor.
  2. Initiates a tunnel or connection through Devolutions Gateway to the internal resource.
  3. Authenticates the vendor, possibly using domain credentials
  4. Forwards the connection through DG securely to the internal SSH server.

In practice, this intermediate component is often either:

  • A machine running RDM or RDM Agent, configured to create a DG tunnel on demand.


Best regards,

Michel Audi