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.
tsocks doesn't seem to be working for ftp, why?
tsocks can only socksify outgoing connection requests from applications, in ftp there are normally two channels, one is made from the client to the server (called the control channel) and another from the server back to the client (called the data channel). If a SOCKS server is between the client and the server the server will incorrectly try to connect back to the SOCKS server rather than the client. Thus the data channel connection will be fail (not that it would likely succeed even if it did try to connect back to the correct client, given the SOCKS server is probably firewalling the network off).
The simplest solution to this problem is to use passive mode ftp, in this form of ftp all connections are made from the client to server, even the data channel. Most ftp clients and servers support passive mode, check your documentation (as a tip the Linux command line ftp client uses passive mode when invoced with the -p option)
I keep getting an error like "SOCKS server is not on a local subnet!", what's going on?
By definition SOCKS servers in the tsocks configuration file must be on networks specified by a "local" subnet statement. Remember that a 'local' subnet doesn't describe a subnet that the machine is directly attached to but rather networks that the machine can reach without the aid of any SOCKS server (thus such networks are "local" networks).
When you think about it, if a SOCKS server were on a network that wasn't local then you would need a SOCKS server in order to be able to reach the SOCKS server (which can actually occur in some strange networks but tsocks doesn't yet support that sort of network).
To fix your problem just define the network your SOCKS server is on in a local subnet statement.
make install doesn't seem to honor the --prefix when installing libtsocks.so
This is a very common question even though it is repeatedly discussed in the README and INSTALL files. The installation step does not honor prefix when installing the tsocks library deliberately. The reason for this is that the default path (i.e /lib) is certain to be on the root partition. This is important when tsocks is added to the /etc/ld.so.preload file, if the library weren't in the root filesystem when the machine next rebooted processes that are part of the boot sequence before all of the filesystems are mounted would try to find the library, fail then crash, effecively killing the machine. So, for safeties sake the installation path for the library can only be modified using the --libpath option to configure.
Does tsocks support receiving connections via SOCKS? (i.e the SOCKS BIND operation)
The first version of SOCKS, version 4, only provided support for making connections out through a socks proxy, i.e the SOCKS CONNECT operation. Later an extension was made that allowed for connections to be received through a SOCKS proxy called the SOCKS BIND operation. tsocks only supports the CONNECT operation (when working with both version 4 and 5 servers). Extending it to provide BIND support wouldn't be extraordinarily difficult, but it wouldn't be trivial either. Given that I have no use for this functionality and that there appears to be no real demand for it, I don't intend to implement it. I would of course welcome a contributed patch which adds the support.