Users really need to dissect and understand how each method of constraining application traffic to tor works before choosing one, then set it up and test extensively before use. And deploying an out of band managed catchall packet filter is essential to helping prevent eventual IP leaks.
Four common methods for ssh are... kernel agnostic - the above global packet filters kernel scoped to userland - aorta on linux, or roll your own on bsd library mangling - torsocks, not for static compiled apps application rtfm [1] - ssh_config Host and ProxyCommand They all should be capable of capturing whatever ssh emits, however each box, config, usage and user is different. Last... SSH often involves a live bidirectional terminal and X connection to a potentially adversarial remote machine... [1] An application's proxy configs are nice when they work as claimed "all traffic", but they often fail that spec till many oops tickets later, or break from version to version. Most simple unix tools like OpenSSH are not an issue. Skype / Vuze / similar bling on Windows... no comment. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk