There is no advantage to using TBB as root, but there are significant risks.
It is a generally accepted practice that userland applications (ie: application that are not system services) should not be run using a privileged account. This is to help ensure integrity and isolation of potentially harmful applications from core ...
Actually, we're very happy with our Debian packager. He works hard to make sure the version of Tor shipped in various Debians is safe and stable.
But Ubuntu has indeed been a source of frustration over the years. Read the Ubuntu bug ticket for some of the sordid details -- especially the parts where I start repeating the phrase "remote root vulnerability" ...
Normally the Tor service should be started/stopped with either sudo systemctl start/stop tor.service or sudo service tor start/stop.
Personally I've always used the service command because it is simpler. I'm guessing things get a little more complicated when you run multiple Tor instances, but I have no experience with that.
Running Tor in a terminal runs ...
Tor checks the ownership of several files and directories at startup. One of those directories is the HiddenServiceDir. This should belong to the user who started the Tor process. Otherwise you will get the warning:
Oct 06 12:34:56.000 [warn] /foo/bar is not owned by this user (johndoe, 1011)
but by root (0). Perhaps you are running Tor as the wrong ...
As far as I see it, the package file brings its own version of the Tor Browser Bundle. So if you want to make sure that someone didn't change anything you'd have to check the integrity for yourself. If you don't do this the maintainer can inject arbitrary code into his TBB version.
A better way would be to download the TBB archive directly from torproject....
Tor should control the hidden service private key, it has nothing at all to do with the httpd so you shouldn't be putting the private key or setting the hidden service directory anywhere related to the httpd, e.g. inside /var/www
Instead use a folder like /var/lib/tor/hidden_service. This is inside a folder that tor already controls and can set the ...
From the obfs4proxy README:
The autogenerated obfs4 bridge parameters are placed in
DataDir/pt_state/obfs4_state.json. To ease deployment, the client side
bridge line is written to DataDir/pt_state/obfs4_bridgeline.txt.
How to configure Tor and Obfsproxy:
According with this bug report:
... the obfsproxy permission error is triggered by the tor init script ( at least on debian/ubuntu ) because of tor apparmor wrong script (/etc/apparmor.d/...
Use the text editor and open the start-tor-browser script file. Search for the word root, you will see these lines:
if [ "`id -u`" -eq 0 ]; then
complain "The Tor Browser Bundle should not be run as root. Exiting."
Remove or comment out the exit 1 command.
If you only used signed repositories for your software, then you should be fine. Both Debian and Ubuntu sign their archives by default, and apt complains as soon as you add an insecure source to its list. Thus, it should not matter how you download the packages - their integrity gets verified by the system before installing and everything should be secure.
Building Tor statically is problematic, at best, and not really (well) supported.
I got configure to run with this minor patch:
@@ -542,7 +542,7 @@ AC_ARG_WITH(ssl-dir,
-TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto $TOR_LIB_GDI],
+TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto -lz -...
At the moment the meek packages are landing in debian so we can expect them to arrive in ubuntu too.
Previous info are not working fine anymore, it looks there is now a repository for debian unstable ... so I changed my previous answer with this one:
1 Add Repository
Repository (info on the repository page).
2. Install meek-client package
From the Arch Linux Wiki:
chromium --proxy-server="socks5://127.0.0.1:9050" --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE myproxy"
However as the wiki explicitly warns: this will be used for fetching http and https only, a great deal of work was put into ensuring "Proxy Obedience" in Tor Browser.
Forcing Chromium to fetch content outside of the Tor proxy ...
If you follow these steps below and done everything correctly,
then this will work like a charm!
This might also work on other versions of Ubuntu & TBB.
Download the latest (Tor Browser Bundle) from https://www.torproject.org/ and save it into the Home (Downloads) directory.
Create a new folder somewhere in the Home directory. Example: Documents and ...
I just solved what I believe may be your problem as well.
Try leaving the 'HiddenServiceDir' alone or back to it's normal value which I believe is
Restart Yor with these
sudo service tor stop
sudo service tor start
You won't have access to /var/lib/tor so to access the .onion address from /var/lib/tor/...
You can run any command as a different user using sudo:
sudo -u my_user tor-browser-en
If you need to use multiple commands you can do this:
sudo -u my_user sh -c "first && second"
If you want to background the application, you should not do this (it will only work as expected if you're already authenticated with sudo):
sudo -u my_user tor-...
From the README:
The getxbook program downloads books anonymously. Using it will still
result in your IP address being logged (use
torify to stop this)...
torify is tool that attempts to wrap your terminal command in a Tor session. There's a good tutorial on what you need to do, here. Then it's just a case of running:
You should prefer torsocks over proxychains, since torsocks is intended to block potential leaks.
Especially in cases with tools like youtube-dl which might try to pass over execution to programs that can make network connections of their own in unexpected or attacker controlled ways.
Specifically with proxychains, if anything wrapped in proxychains tries ...
The default systemd/upstart script should handle a shutdown properly.
The only thing that special about a relay shutdown is that there is a grace period of 30 secs to avoid tearing down short-lived connections.
From tor's the manpage:
When we get a SIGINT and we’re a server, we begin shutting down: we close listeners and ...
Your version of Tor has bug which causes this messages (see #21056). Version 0.3.0.6 has a partial fix. If you install this version there are high chances that the messages will go away. Currently the developers are working on a full fix (see #17242).
So I would recommend to install a newer version. Please follow the advise at the instruction page for ...
In general you do the following steps:
Check the source code from Tor's git repository or from the download page.
Apply your changes
Compile the code (./configure && make)
You can install the binary (make install) or run it directly from the directory (src/or/tor)
As long as you do the changes you mentioned there is no need to exclude you from the ...
This bug has been confirmed. Some workarounds have been communicated, but no final solution / bugfix.
See launchpad: Bug #680192 “Vidalia was unable to start Tor. Check your setting...” and try to disable the usr.bin.vidalia AppArmor profile.
Hope this helps!
You can 'torify' your ubuntu machine, and route all traffic through tor,
see the wiki here for guides for that:
Or you can set up a 'Whonix' gateway, and put your windows virtual machine behind that.
There is a guide for that here:
Your Tor is probably under the impression that it has already created one. (Maybe it did and you deleted it?)
Try the following:
Edit your torrc to set CookieAuthentication to 0
reset your Tor (kill -HUP or hit x twice in Arm)
Edit your torrc again to set CookieAuthentication back to 1
reset your Tor again.
You should now have a new control cookie.
You can put it in any directory and extract it there. You can even extract it in the Downloads directory. After extracting, you just need to execute the start-tor-browser script by running it in terminal.
Your server listens to port 6666 ..
HiddenServicePort 6666 127.0.0.1:7777
.. but your Tor tries to connect to 7777
You should change your HiddenServicePort directive to
HiddenServicePort 6666 127.0.0.1:6666
HiddenServicePort 80 127.0.0.1:6666 (in this case, you don't have to put a port ...
Are you sure it's clicking on subdirectories causing the problem? nginx should just provide any existing file/directory that exists, and should not be aware what port it is serving the content on.
If, on the other hand, the problem is that going to *.onion/subdir (no slash at the end) redirects to *.onion:8081/subdir/, then you might be looking for the ...