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  - 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...
 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 - email@example.com
To unsubscribe or change other settings go to