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 HostName 192.168.100.123 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.
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 HostName 192.168.100.123 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 127.0.0.1:5000 0.0.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
- 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
127.0.0.1. But how do I get RDP or some other SSH client to use the Socks5?
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
OpenSSHon Linux and archive the same with OpenSource tools.
- I think I once compiled
proxychainsin cygwin. Does that sound better? Windows OpenSource? Eh…
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.