These two part I found to be more annoying to deal with, although this is true for most VPN solutions (thinking about tinc, wireguard).
I don't understand why you couldn't have a small utility to take a human memorable password that maps to a weak-ass private key, then ratchet up to a secure keypair on the server once the initial connection is made:
1. Run utility in "server" mode.
2. Enter password "I am not the target of a state level actor atm" into utility
3. Utility maps your weak-ass password to a weak-ass private key, generates the pubkey from that, and consequently creates the Tor hidden service behind which your openssh server can now be accessed.
4. On the client, run the utility in "client" mode and type in your weak-ass password
5. Utility maps the password to the server's weakass kepair and generates the corresponding onion address from it.
6. Utility creates a tunnel over Tor to connect to that onion address.
7. Server and client are now connected, with no memorization of human unreadable strings. Hurray!
8. Once connected, the server generates a secure keypair and sends the corresponding new onion addy to the client over the current connection.
9. Client receives the new onion addy, disconnects, then connects to the new addy.
10. Repeat for each client. Once all clients are connected, server destroys the original hidden service.
We use it to connect to touring production racks using a consistent IP regardless of what concert venue ISP they might be connected to on a given day.
Careful though: installing the version of Tor which is included in Ubuntu’s distribution is not recommended, is often very out of date.
Use the Tor project’s PPA instead.
Many times people have assumed that Tor is only for 'dark web' and other things that there is no legitimate business using.
But as you say, escaping NAT is a perfect use-case. It's particularly good for escaping CGNAT, as to be honest there aren't many other ways to escape CGNAT and still have a 'listening' server, rather than just an always-open tunnel.
Edit: The Tor Project website has a useful section on how IT professionals use Tor, which covers some more interesting ones: https://www.torproject.org/about/torusers.html.en#itprofessi...
# Remove the bogus tor service Ubuntu installs by default
If you read the discussion in the link, this actually does do that. It just replaces the 'empty' service with the actual tor service. So you do get automatic restarts.
# Append the hidden service configuration to the Torrc file
echo -e "HiddenServiceDir /var/lib/tor/onion-ssh/\nHiddenServicePort 22 127.0.0.1:22" > /etc/tor/torrc
Using ">" instead of ">>" means you don't end up with multiple copies of the same hidden service.
That said, I agree: it should append, but it should first check whether it has already added a hidden service to the file.
if [ $(grep "HiddenServicePort 22" /etc/tor/torrc | wc -l) -eq 0]
if grep -q "HiddenServiceDir /var/lib/tor/onion-ssh/" /etc/tor/torrc
Onion v2 (16 char addresses) uses old crypto (SHA1/DH/RSA1024) and has now been superseded by Onion v3 (56 char addresses, SHA3/ed25519/curve25519 and many other improvements).
Nice script BTW.
EDIT: I stand corrected, see @buildbuildbuild reply.
># Usage (as root): $ bash <(curl -s https://gitlab.com/grownetics/devops/raw/master/tor_ssh.sh)
Spoon feeding like this is why Windows has such a disgusting history of malware, and only encourages people to not think about what they are doing.
curl | sh is slightly problematic from untrusted servers that might change the script depending on whether or not it's piped to a shell, but from gitlab I just don't see a difference.
First, I had experience with substituted SSL certificates (by our government, at revolution), when errors were reported by Chrome only due to certificate pinning for Google services.
Second, site can be hacked and replaced directly at the site.
I played around with that idea in https://github.com/mkmik/runck but it obviously can used for installation instructions only if it's rather ubiquitous.
(I seem to recall there being a way for the server to reliably guess whether the file was being piped or saved to disc, as well, which would let you restrict the malicious version even more. Google is failing me at the moment, though.)
Here is one I wrote that shows your internet speed, but will also check to see if you have passwordless sudo. Even without sudo, I could spawn and persist a gateway port ssh proxy outbound to a VPS node, but with sudo, I could do much more.
curl -A Mozilla -s https://tinyvpn.org/misc/url_test.txt | bash
Conditioning people to use `curl | bash` trains them to not review anything and blindly run untrusted code. I have proven this across a very large group of people, including many that are supposed to be security minded. This technique works on nearly all organizations, as most companies and government agencies do not force outbound traffic through a mitm proxy. I have mixed feelings about those devices.
For what it's worth, where the code is running from doesn't really matter. The only advantage to pulling something from gitlab or github, is that I have to commit changes that anyone could see assuming I dont recreate the repo, which I can automate in their API. From any of my own VM's or servers, I can certainly make something look like a .txt that isn't and dynamically changes based on user-agent, remote addr, latency, ttl, etc.. I could even change the response if someone used curl with a fake user-agent, based on timing, but that is another blog post for another day.
Even gpg checks when done the way Ubuntu and Redhat do it, is also bad. I see people install the gpg keys from the mirror all the time. If I pop the mirror, I can simply put my own gpg keys in the mirror and a percentage of people will happily install it.
Modern package managers do at least store hashes so your NPM, Python, Rust, etc. packages can depend on other packages with hashes in addition to just a version, which at least forces them to attempt to make the exploit covert enough that it can be deployed to everyone but there are many ways to make something subtly vulnerable. Ultimately, I really think this is coming back to securing the environment so a successful attack gets less. Apple has led the way on protecting things like passwords and mail from other processes running as the same user but it’d be really interesting to see how far you could get running your entire toolchain using the OS’ sandboxing.
 - https://news.ycombinator.com/item?id=17636032
You'll eventually realize that the answer is that this advice has no value. What could potentially have value is reviewing the code before running it, which can be done either way.
- wget https://gitlab.com/grownetics/devops/raw/master/tor_ssh.sh
- less tor_ssh.sh
- sudo bash tor_ssh.sh
Tor is not reserved for nefarious purposes.
I get what you're trying to say but in that specific case I don't think it really applies.
Sure, I suppose the install directions should be more like, wget the file, cat it to be sure gitlab didn't serve you a malicious file instead(?), then run it.
Really not sure what this has to do with malware on Windows though.
When someone is sharing their work, being a jerk is exactly the wrong approach here. Please don't do it again.
Rather, if you know more, share some of what you know in a way that's going to help them learn, rather than humiliate. As a side bonus, you won't be acidifying this community either, which is fragile and needs all of us to protect it.
2. Go ahead, nothing will break.
3. True, I have added a note to the script.
4. Umm, is explaining all those slashes simpler than just running a one line command? No. Only 7 lines are even functional, the rest are comments explaining things.
5. If "This file is meant to get SSH access via Tor to an Ubuntu server in one command." doesn't cover for you what it does and why, then you are not the target audience.
Yes, it is a gist for one person. I made it for myself. I thought others would find it useful. I guess that makes me a script kiddie.
1) Tor exit node operators will do all kinds of nasty things: e.g. MITM-ing your sessions, refusing to handle certain kinds of traffic, and recording everything.
2) If you use your regular SSH key (which you will, because you needed to use this script to do this), your SSH key fingerprint and thus your identity is still recorded by the remote host. Doh!
3) Everyone at the remote host will think you got haxed. Because you're logging in through Tor. Or else they'll think you're super shady.
That said, Tor is super fun to play around with. Just don't assume anything gives you real protection unless you're careful and really know the ins and outs.
2.) Why is this a problem? You already own the remote host, so you already know your identity.
3.) It will appear to the remote host as a login from the loopback device. And if you set this up you presumably own the remote host anyway so you don't care what its owner thinks.