Total Pageviews

Thursday, 12 July 2012

Using ProxyCommand with OpenSSH and a Bastion server

at work we have to use a bastion host for all our connections to servers to be able to get called PCI compliant. This kind of stuff could be a pain to use when you have to use another host to do RSYNC/SCP or other stuff that need direct transfer to workstation.
Thankfully OpenSSH is very flexible and have multiple options to easy the pain. If you add this to your ~/.ssh/config :
Host bastion
Hostname IP_ADDRESS_OF_BASTION_SERVER
User YOUR_USERNAME
ProxyCommand none
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p
Host *
ProxyCommand ssh -qax bastion ‘nc -w 600 %h %p’
This will allow you to pass all SSH requests to the bastion server.
I have experimented with different options and this seems to be most efficient way. The ControlMaster ControlPath is to speed up the connections by not reopening a tcp socket all the time to the bastion server. This seems to cause problems with the OpenSSH version shipped with some distros (ie: Fedora) so you may want to remove it if you experience problems. For the ProxyCommand there is way to use cat like this :
ProxyCommand ssh bastion ‘exec 3<>/dev/tcp/%h/22;(cat <&3 & );cat >&3′
but the cat processes seems to hang in memory on the bastion server so netcat seems a better option.  I heard that tcpconnect from the tcputils package should make things smoother but I haven’t tried that.
I have other options in my SSH configuration to allow to be less verbose see ssh_config(5) manpage for detailed description of each of these options :
Host *
ForwardAgent yes
GSSAPIAuthentication no
VerifyHostKeyDNS no
StrictHostKeyChecking no
HashKnownHosts no
TCPKeepAlive yes
ServerAliveInterval 600
By the way forgot to mention you would need to have SSH key exchange configured with the bastion server with a SSH agent runing (these days all distros should do that by default) to don’t have to type the password of your username on bastion server.
I have heard there is way to do that on Windows with putty and plink but I haven’t tried that see this post here about it.
from http://blog.chmouel.com/2009/02/08/proxycommand-ssh-bastion-proxy/
--------------------------------------------------------------

SSH using a SOCKS or HTTP proxy


If you follow planet debian, you may already know about the ProxyCommand directive in $HOME/.ssh/config. It allows OpenSSH to connect to a remote host through a given command.
One setup that I use a lot is to have connections be established through a SOCKS proxy. Until today, I was using connect, a small tool written by Shun-ichi Gotô. The typical setup I used is:
Host *.mydomain.com
ProxyCommand connect -S socksserver:1080 %h %p
I also use jump hosts occasionally, with a setup like this:
Host somehost.mydomain.com
ProxyCommand ssh otherhost.mydomain.com nc -w1 %h %p
And today I discovered that netcat-openbsd does support connexions through a proxy, either SOCKS or HTTP. Why keep using two different tools when you can use one? ;) So I changed my setup to:
Host *.mydomain.com
ProxyCommand nc -xsocksserver:1080 -w1 %h %p
The default is to use SOCKS 5, add -X4 for SOCKS 4 and -Xconnect for HTTP CONNECT proxies. Note that it doesn’t support choosing which end does the name resolutions like connect does with the -R option.

from http://glandium.org/blog/?p=223
-----------------------------------------------

SSH through jump hosts


I often need to connect to a server with ssh from another server because I don’t have direct access. I even gave a small configuration example to use such jump hosts using ProxyCommands.
A while ago, I got fed up to have to add new entries for each host I wanted to join with a jump server, especially when I only need these entries sporadicly, and decided to write a generic configuration. I ended up with this setup:
Host *%*
ProxyCommand ssh $(echo %h | cut -d%% -f1) nc -w1 $(echo %h | cut -d%% -f2) %p
The trick here is that you can use subshell expansions in a ProxyCommand. So, when I ssh to “host1%host2″, the first subshell expansion returns “host1″ and the second “host2″, this setup ends up being the equivalent of :
Host host1%host2
ProxyCommand ssh host1 nc -w1 host2 %p
which is quite similar to the setup from my previous post.
Later on, I came up with an even more powerful implementation:
Host *%*
ProxyCommand ssh $(echo %h | awk -F%% '{OFS="%%"; NF--; print $0}') nc $(echo %h | awk -F%% '{print $NF}') %p
Here, the first awk splits at the % characters and returns all fields except the last one, and the second awk returns only the last field. As a consequence, sshing to “host1%host2%host3%host4″ will have the first subshell expansion return “host1%host2%host3″ and the second “host4″. The setup will then be equivalent to:
Host host1%host2%host3%host4
ProxyCommand ssh host1%host2%host3 nc -w1 host4 %p
The ssh in the ProxyCommand will, in turn, trigger the rule again so that the result is that host4 will be contacted from host3, which is contacted from host2 that we contacted from host1.
In the meanwhile, I decided % was not that nice a separator, and switched to using /, which also allows for a nicer setup with the same recursive effect:
Host */*
ProxyCommand ssh $(dirname %h) nc -w1 $(basename %h) %p
Finally, since some remote hosts don’t have nc installed, I usually copy it in my $HOME on these servers and changed my setup to:
Host */*
ProxyCommand ssh $(dirname %h) PATH=.:\$PATH nc -w1 $(basename %h) %p
The main drawback of this method is that the more jump hosts you use, the more your ssh traffic is encapsulated (recursively) in other ssh traffic. The advantage, though, is that you don’t need to forward an agent onto untrusted servers to use ssh key authentication on any of the jump or final servers, nor to forward X11 or tunnel multiple times.
from http://glandium.org/blog/?p=303