Creating a transparent SSH tunnel through a bastion host using the ProxyCommand configuration parameter
Like most users out there (I think) my systems are usually configured to allow ssh connections from a small handfull of trusted hosts or a bastion host. This is decent security practice but is a total pain when you want to scp a file or grab the stdout of a command from a host outside the trusted area. Or perhaps you have a number of hosts on a private subnet and only one routable host to get in through. I was able to set up a method which allows for transparent access to a host while behind the scenes tunneling through a trusted bastion host involving some pretty minor adjustments to the .ssh/config file.
Here’s how it works:
A connection is established to the bastion host
+-------+ +--------------+ | you | ---ssh---> | bastion host | +-------+ +--------------+
Bastion host runs netcat to establish a connction to the target server
+--------------+ +--------+ | bastion host | ----netcat---> | server | +--------------+ +--------+
Your client then connects through the netcat tunnel and reaches the target server
+-----+ +--------------+ +--------+ | you | | bastion host | | server | | | ===ssh=over=netcat=tunnel======================> | | +-----+ +--------------+ +--------+
So there are 3 basic steps:
1. Ssh to bastion host.
2. Run netcat command on bastion host.
3. Connect to netcat tunnel.
Here’s how it works with ssh:
#~/.ssh/config Host superchunk.example.org ProxyCommand ssh email@example.com nc %h %p
Above we tell ssh that when it establishes a connection to superchunk.example.org to do so using the stdin/stdout of the ProxyCommand as a transport. The ProxyCommand then tells the system to first ssh to our bastion host and open a netcat connection to host %h (hostname supplied to ssh) on port %p (port supplied to ssh).
The result is a connection as if you were connecting from a trusted host:
$ ssh superchunk.example.org Password: [email protected]'s password: Last login: Wed Jun 25 12:05:47 2008 from 10.0.0.221 [user@superchunk ~]$
Now you may be wondering why it prompted me for two passwords. This is because we are effectively sshing into two systems one right after the other. This can be resolved through the use of pre-shared ssh keys or with more advanced methods such as kerberos ticket forwarding.