Tunneling ssh – option 2
See the previous post for an explanation of what we’re trying to accomplish.
This is a diagram of what the setup looks like. The numbers shown are the TCP ports used by the various components.
In the Apache config file:
<VirtualHost *:80> ServerName home.com ProxyRequests on AllowCONNECT 70 ProxyVia on <Proxy *> Order deny,allow Allow from all </Proxy> </VirtualHost>Enable the proxy connect module in Apache. On Ubuntu you just have to have the following symbolic links in
proxy.conf -> ../mods-available/proxy.conf proxy_connect.load -> ../mods-available/proxy_connect.load proxy_http.load -> ../mods-available/proxy_http.load proxy.load -> ../mods-available/proxy.loadConfigure Stunnel on the server the same way as for option 1. On the client PC, this is the proxytunnel command line you'll need to use:
C:\>proxytunnel.exe -p proxy.work.com:1080 -d home.com:70 -r home.com:80 -a 71Configure the work.com stunnel:
sslVersion = SSLv3 ; Use it for client mode client = yes [apache-ssh] accept = 32 connect = 71
Restart apache and stunnel on the server side.
On the client side:
- Start proxytunnel using the command shown above.
- Start stunnel. If the stunnel.conf file is in the default location, no command line arguments are needed. If not, pass the config line as a command line argument to stunnel.
- Start the ssh clinet and connect to 127.0.0.1:32
Here’s what’s going on:
- The ssh client connects to port 32 on the localhost
- Stunnel is listening on port 32 on the localhost, so it receives that connection and sends it on to port 71 also on the localhost
- ProxyTunnel is listening on port 71, so it takes that connection from Stunnel and sends it to home.com:80 through proxy.work.com:8080
- The Apache server running at home.com:80 receives a CONNECT request for home.com:70, so it forwards the connection to that destination.
- Stunnel is listening on port 70 at home.com and when it receives the connection from Apache, it sends it to port 22 on home.com
- Finally, sshd is listening on home.com:22 so it receives the connection from Stunnel, allowing the user to log in
This is even less efficient than the first option, but has the advantage of not requiring another service to be exposed directly to the internet through the firewall.