Arch Linux

cafetron

Member

From: Brazil

Registered: 2010-06-02

Posts: 7

[SOLVED] Peculiar SSH tunneling situation

I'm an assumed newbie and I have a helluva problem with which I must deal. I work at a laboratory whose network looks like this:

 ------------                        ,,,,,,,,,,, 
| Windows +  |       --------       {           }
|  CoLinux   |______| Squid  |______{ Internetz }
|  (Debian)  |       --------       {,,,,,,,,,,,}
 ------------
      |
      |
 ------------
| Arch Linux |
 ------------

The computer with CoLinux connects to a Squid proxy through Slirp and works correctly with the environment variable http_proxy -- that is, apt and wget are able to do their job. The task is to let Arch box download all needed packages and update the whole system. How can I accomplish that? I tried to establish a SSH tunnel and make pacman download everything with curl, but seems like the SSH daemon on the Debian box is not made to handle the variable http_proxy.

Thank you in advance

Last edited by cafetron (2010-06-09 21:06:55)

Sin.citadel

Member

Registered: 2008-01-22

Posts: 267

Re: [SOLVED] Peculiar SSH tunneling situation

if you only need to run pacman, simply edit /etc/pacman.conf and change the XferCommand for wget with its http-proxy parameter.

cafetron

Member

From: Brazil

Registered: 2010-06-02

Posts: 7

Re: [SOLVED] Peculiar SSH tunneling situation

if you only need to run pacman, simply edit /etc/pacman.conf and change the XferCommand for wget with its http-proxy parameter.

Thanks for answering it quickly

Nevertheless I can't do that, because the HTTP proxy is only reachable by the Windows/CoLinux PC. Hence, I still have no idea how to make curl get through the sockified SSH tunnel AND negotiate with the HTTP proxy beyond the Debian box. In other words, while most people wonder how to connect to SSH via HTTP proxy, I want to connect to a HTTP proxy via SSH.

Am I clear?

Last edited by cafetron (2010-06-08 01:17:59)

MoonSwan

Member

From: Great White North

Registered: 2008-01-23

Posts: 881

Re: [SOLVED] Peculiar SSH tunneling situation

Drop a hand grenade in the room, run like hell and claim it was the work some unkown terrorist group. Then hit up the university for more money to fix the issues.

cafetron

Member

From: Brazil

Registered: 2010-06-02

Posts: 7

Re: [SOLVED] Peculiar SSH tunneling situation

Drop a hand grenade in the room, run like hell and claim it was the work some unkown terrorist group. Then hit up the university for more money to fix the issues.

Mmmh, so tempting While I look for a grenade on eBay, does anyone know if there's a tool for Arch OPPOSITE to this one? --> http://docs.sun.com/app/docs/doc/816-51 … t-1?a=view
I can't believe I'm the only living person to face such scenario

Last edited by cafetron (2010-06-08 01:48:14)

Sin.citadel

Member

Registered: 2008-01-22

Posts: 267

Re: [SOLVED] Peculiar SSH tunneling situation

you can try using socat or tsocks, see if any of them works.

cafetron

Member

From: Brazil

Registered: 2010-06-02

Posts: 7

Re: [SOLVED] Peculiar SSH tunneling situation

Thank you guys for such helpfulness. The solution was actually much simpler than expected. I have not yet, apparently, developed the minimalist philosophy required to operate Arch. But since I come from the we-do-it-for-you Ubuntu, I must be instantly forgiven for the lack of sight There is no need for a tool that establishes a SSH bridge to reach the HTTP proxy served by Squid, because the OpenSSH client is the tool itself (surprising, huh?). Here's how I made it:

i) On the server with access to the Squid Proxy (in this case, my Debian box), just make sure the SSH daemon is running. If you installed it via aptitude or apt-get, the daemon is on by default.

ii) On the client computer (my Arch box), create a HTTP tunnel: # ssh SERVER_IP -L LOCAL_PORT:SQUIDPROXY_IP:SQUIDPROXY_PORT
It doesn't matter if it will only redirect you to this address. All in all, this is how a proxy works. You tell Squid whatever object you wish it to fetch and no outside contact is needed whatsoever.

iii) Now you must modify the variable XferCommand in /etc/pacman.conf and specify which client shall be used to download your stuff. I'm using curl in the following manner:

XferCommand = /usr/bin/curl --anyauth -C - --proxy-anyauth --proxy localhost:LOCAL_PORT %u > %o

Where,

--anyauth: Tells curl to figure out authentication method by itself, and use the most secure one the remote site claims to support. This is done by first doing a request and checking the response-headers, thus possibly inducing an extra network round-trip. This is used instead of setting a specific authentication method, which you can do with --basic, --digest, --ntlm, and --negotiate.

-C: Continue/Resume a previous file transfer at the given offset. Use "-C -" to tell curl to automatically find out where/how to resume the transfer. It then uses the given output/input files to figure that out.

--proxy-anyauth: Tells curl to pick a suitable authentication method when communicating with the given proxy. This might cause an extra request/response round-trip.

--proxy: Use the specified HTTP proxy.
Most likely, the command above may be fine-tuned, but I simply haven't had time to refine it yet. Suggestions are kindly appreciated!

Last edited by cafetron (2010-06-09 21:11:27)