SSH tunnel proxy in Akonadi/Kontact/KMail

desade · 10-05-2011, 11:43 AM

I have a SOCKS5 proxy set up through ssh -D under KDE 4.7.1, and I'm running polipo as an HTTP proxy, routing through the SSH tunnel proxy. I have the polipo port set in KDE Proxy Settings.

Chromium, Kopete, and Choqok are all respecting those settings just fine, although Kopete needs to be started with tsocks.

KMail (really Akonadi) is ignoring the settings and connecting to my IMAP server directly anyway, and I can't find any reason why. Here's what I've tried so far:

* Forcing Akonadi not to start until the proxies are in place
* Running "tsocks akonadictl start"
* Running "tsocks kontact"
* Running "tsocks kdeinit4"

Nothing seems to have any effect. Any suggestions?

BTW, this Arch guest is running in a VirtualBox machine on a RHEL host. I run wireshark on the host to see if I see un-tunneled traffic. For each of the apps mentioned above, I saw untunneled traffic until getting them properly configured. In the case of IMAP communications, untunneled traffic continues to flow no matter what.

macemoneta · 10-05-2011, 12:10 PM

I found this note over at kde.org:

Quote:

Enabling SOCKS support in KMail and KNode

Unlike KDE 3, KDE 4 does not have built-in SOCKS support yet. However, it is still possible and relatively simple to make KMail and KNode use a SOCKS proxy, by using proxychains or other similar tools like tsocks or socksify. Assuming that proxychains is correctly installed and configured, all you need to do is to open a terminal (e.g. Konsole) and type:

proxychains kdeinit4

You don't even need to restart KMail/KNode! (You need to type the above command every time you start a new KDE session though).

desade · 10-05-2011, 05:06 PM

I saw that note, too, but proxychains is in the AUR while tsocks is in the "extra" repository. It kind of implies that tsocks, socksify, and proxychains are all equivalent. I don't have abs set up on this VM, and it has limited storage, so I was hoping to avoid the makepkg route. Proxychains also seems to be significantly more complex to set up, no?

Has anyone actually gotten this to work with proxychains? I'll go set it up and try it if it is known to work better than tsocks.

macemoneta · 10-05-2011, 05:56 PM

It might be easier. The tsocks FAQ has this:

Quote:

tsocks doesn't seem to be working for SSH, why?

tsocks can be used a number of ways, the most common being the LD_PRELOAD environment variable. When set (often through a script) this requests that the system dynamic loader load tsocks into each process before execution of the process begins. This allows tsocks to redirect calls to standard networking functions to force them to be socksified.

Unfortunately LD_PRELOAD simply doesn't work for setuid programs when the user running the program is not the same as the owner of the executable. This is because being able to load code into a privileged executable would be a major security flaw. To fix this problem you may wish to removed the setuid bit from SSH (this will force it not to use privileged TCP ports, disable some forms of RSA authentication to older servers and may have other effects). Alternatively you might wish to force tsocks to be loaded into all processes using the /etc/ld.so.preload file, for more information please see the tsocks man page.

I don't know if you want to make either of those changes to your system.

desade · 10-06-2011, 09:06 AM

Well, two steps forward one step back. I got the bright idea last night to set LD_PRELOAD to include the tsocks shared library prior to calling akonadictl, and sure enough all the akonadi processes (including akonadi_imap_resource, the culprit mentioned above) inherited that environment variable and started using the proxy as intended. So that's sorted... here's the script I use:

. tsocks on
akonadictl start

The sourcing (.) is important, as per the tsocks doc, so that LD_PRELOAD gets set in the current shell script process, instead of a sub-process.

Now the step back... Kopete for Yahoo Messenger has stopped working, and it looks to me like I was just lucky it worked before. When it creates the socket that connects to yahoo:5050 (the YMSG server), it sets O_NONBLOCK on it and then uses poll() to figure out when the fd is ready for connection, reading, writing, etc. When it uses the proxy, it obviously connects to localhost:xxxx (my ssh SOCKS tunnel port) instead, and does SOCKS5 negotiation to request connection to yahoo:5050 on its behalf. The problem is after it sends the connection request to the SOCKS server, it attempts to recv the response, and then refuses to wait (poll(), select(), whatever) when it gets an EAGAIN, instead closing the socket. (All of these assertions are based on output from strace)

This feels like more of a tsocks problem than a Kopete problem, and tsocks is a much simpler beast to build & debug than Kopete - I might just have a look at the source, and/or connect with the tsocks community.

Thanks for the advice so far, and I'll let you know how it goes.

EDIT: How it went was nowhere. There are a few interesting things in the interaction between Kopete and tsocks, but resolving those as best I could eventually led to Kopete receiving the YMSG Auth Ack and never going any farther... like it didn't know the data was there. I give up, and I'm going back to Pidgin, which has proxy support for Yahoo built in.

For the curious, Kopete uses poll() to monitor its connection attempt progress. tsocks catches calls to poll() and does its own SocksV5 negotiation before eventually "completing" the connection. tsocks assumes that each file descriptor is in the pollfd array only once, which Kopete violates by putting its connecting YMSG descriptors in there twice, both with POLLOUT for the events. Because of this assumption, tsocks does a bad job of communicating the crafted poll() results back in the pollfd array, and just generally gets confused because of the dupe fds. I overhauled tsocks' poll() function to solve this problem, which allowed kopete to get the TCP connection going through the proxy and start the YMSG authentication process. But why it is now stalling after receiving the Auth.Ack (the one with the big nasty algebra expression in it) is a complete mystery.

I want to drink of the KDE juice, I really do, but I also want to get things done.