Hello,
Thank you for reaching out on this matter.
I confirmed the root cause. RDM's built-in SSH Gateway feature (the SSH Gateway tab on the connection entry) uses standard SSH direct-tcpip channels for each hop. This is the exact SSH primitive that is disabled when AllowTcpForwarding no is configured. As a result, direct connections through external1 continue to work, but any multi-hop chain through that host fails.
The good news is that there is no need to modify your CIS baseline. RDM includes a native workaround using the Proxy tab on the same connection entry.
Configure the proxy as Proxy Type = Local . In this mode, RDM runs a local command on your Windows machine and pipes its standard input/output into the SSH library. This approach uses only SSH exec channels and a final outbound nc connection—no direct-tcpip channels are used.
I tested the following procedure end-to-end in a lab with the same three-hop topology:
Client → Externalsrv1→ CIS-hardened Middle Host → Target
1. Prepare the servers (one-time)
On the first hop, install sshpass:
sudo apt install -y sshpass
# or
sudo dnf install -y sshpass
Alternatively, copy an SSH key from the external1 server's ~/.ssh directory into ~/.ssh/authorized_keys on the CIS-hardened middle host. That is the preferred production approach, while sshpass is useful for quickly validating the solution.
On the CIS-hardened middle host, ensure that nc or ncat is installed. Ubuntu typically includes nc by default. On RHEL:
sudo dnf install -y nmap-ncat
2. Create a wrapper batch file on the Windows client
Because nested quotation marks in RDM's Proxy command field are not parsed reliably, create a small batch file instead.
Save the following as:
C:\Users\<yourUser>\rdm-proxy.bat
@echo off
plink -ssh -batch -pw <gwPass> <user>@<Externalsrv1> "sshpass -p <midPass> ssh -o StrictHostKeyChecking=no <user>@<middleHost> nc %1 %2" 2>>C:\Users\<yourUser>\rdm-proxy.log
The 2>>...rdm-proxy.log portion captures stderr from every hop, making troubleshooting much easier if anything goes wrong.
plink.exe is included with RDM (or PuTTY). If it is not available on the PATH used by RDM, specify its full path.
3. Configure the RDM connection
For the final target (external2 / external3):
General
Host: Set this to the final target's hostname or IP address. It must be reachable from the CIS-hardened middle host (since nc runs there), not necessarily from your Windows PC.
SSH Gateway
Gateway Mode: None
Remove any configured gateway entries.
Proxy
Proxy Mode: Custom
Proxy Type: Local
Command:
C:\Users\<yourUser>\rdm-proxy.bat %h %p
Use %h and %p (single-letter placeholders). These are substituted by the terminal library. %host and %port are not substituted and will be passed literally.
The credentials configured on the RDM entry continue to be used normally for the final SSH authentication to the target.
4. Test outside RDM (if needed)
From PowerShell, run:
plink -ssh -pw <gwPass> <user>@<Externalsrv1> "sshpass -p <midPass> ssh -o StrictHostKeyChecking=no <user>@<middleHost> nc <targetIP> 22"
For the first test, omit -batch so you can accept Externalsrv1's host key. After it has been cached in the Windows registry, you can re-enable -batch.
If everything is working, you should see something similar to:
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.13
This banner comes from the final target, confirming that the connection successfully traversed both intermediate hosts without using TCP forwarding.
Press Ctrl+C to exit.
In summary, this solution uses three independent SSH connections, two SSH exec channels, and one outbound TCP connection while keeping the CIS AllowTcpForwarding no control fully intact.
If you run into any issues, please send me the contents of rdm-proxy.log SANITIZED . That log should make it straightforward to identify where the connection is failing.
Best regards,