A transparent jump host setup for RDP / SSH on Linux and Windows - admin hacks

Tags: #<Tag:0x00007f76fba51490> #<Tag:0x00007f76fba512b0> #<Tag:0x00007f76fba50b58>


The setup is pretty simple. You connect via an SSH jump host to the hosting platform, but there is no direct route from your workstation into that network.

Using jump hosts is a pretty straight forward way to isolate the management of the hosting platform from the user/admin network. A Malware on a local admin machine does not get direct access to the DB servers, or to other relevant systems. In theory. Practically that might not be the case if the jump host isn’t configured well enough. Let’s take a look.

Quick ProxyCommand for the OpenSSH client

With OpenSSH this is as easy as it gets.

➜  ~ more .ssh/config 
Host */*
    ProxyCommand ssh $(dirname %h) nc -w600 $(basename %h) %p

Host webbox
   ProxyCommand ssh -q [email protected] nc -q0 %h 22
   User lol
   # StrictHostKeyChecking no
   # UserKnownHostsFile=/dev/null

That works fine, but of course it’s kind of hacky.

The HostKeyChecking override especially with the deactivated KnownHostsFile might even be problematic, due to Men-In-The-Middle attacks. But it’s sometimes necessary, due to NATing.

I think it’s sometimes better to use SSH’s Socks5 service. It’s transparent.

Transparent jump host proxy with OpenSSH

Start the Socks5 via SSH: ssh -D 5000 jumphost.lala

Check the config:

➜  ~ more .ssh/config 
Host */*
    ProxyCommand nc -X 5 -x localhost:5000 %h %p

Host webbox
   ProxyCommand nc -X 5 -x localhost:5000 %h %p
   User lol

What does it mean: “It’s transparent”?

The SSH client connection doesn’t get terminated by the jump host. The Socks5 tunnel gets established to the jump host, and it’s input is bound to

➜  ~ netstat -tulpn | grep 5000
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0*               LISTEN      14056/ssh       
tcp6       0      0 ::1:5000                :::*                    LISTEN      14056/ssh      
  • So you locally feed into the client connection entry point and the Socks5 endpoint is the jump host.
  • The SSH connection endpoint is the target system webbox.
  • The Socks5 wrapping of the SSH connection ends at the jump host
  • The jump host forwards TCP connections
  • The client IP appears directly at the SSH target system webbox. Useful for the logs, eh?

And on Windows (10) - can you do this?

This also works for RDP - of course. Your favorite RDP clients can all be Socks-wrapped. On Windows I use the Bitvise SSH client, because it works perfectly well. And it has got Socks support.
Check the services tab:

Now this looks familiar already, Port 5000, But how do I get RDP or some other SSH client to use the Socks5?

SocksCap 64

On Windows the Socks wrapper I use is SocksCap. Some AV tools don’t like it very much, but that is an AV vendor problem imho.

Now start your management tool from the SocksCap UI. And treat your connects as if they were direct. Because - they are - kind of.

It’s practically the same thing.

If you are suspicious about SocksCap, check for an OpenSource Windows Socks wrapper which is free and works well. I’d be interested.


  • You can obviously use proxychains and xfreerdp / OpenSSH on Linux and archive the same with OpenSource tools.
  • I think I once compiled proxychains in cygwin. Does that sound better? Windows OpenSource? Eh…

But but...

Another interesting use-case for this is a jump-jump-host scenario, when you need to pivot into the remote network via multiple hops. As long as you can channel into a Socks5 input which terminates after the last hop you are transparent.

Okay, yes. It's bad.

The overall point is that a jump host does not need to terminate the client connections. Whether this is a good or a bad thing is a discussion with a risk matrix.

You can obviously restrict the jump host to disallow this with AllowTcpForwarding no. But this is rarely done, and therefore many jump host setups aren’t worth a lot with password-less SSH keys everywhere. No one wants SSH agent-forwarding. But of course, jump hosts. Checkbox. Done.