Hacker News

Thats awesome! Thanks for building it, it helped a ton :)

> Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.

That depends on the VPS technology stack being used. IIRC, at least Amazon uses hardware features like IOMMU that prevent any kind of access to the guest's memory from the host side.

In many countries, running an exit node is a very fast way to have cop knocking at your door and seizing all your stuff. To run a tor exit node, you either have to try your best to stay anonymous, preferably be based in a country who don't care at all about cyber crime, and run them on a dodgy hosting provider who dgaf. Or you have to create a legal entity, either a non-profit or a company, depending on the country register as a hosting provider (so that you are not consider legally responsible for what comes out of your server if you abide by some rules), and you will still have to respond pretty fast to any police inquiry.

If anything, it's a miracle that there is 3000 of them. Although you can safely assume that a good portion of them (if not the majority) are operated by state intelligence services, cybersecurity companies and bad actor, who will log everything that pass through their node (and might be able to decrypt them one day).

Because running one will get your machine blamed for any illegal activities that Tor users are up to. I ran one for whole 2 weeks, before my hosting provider just told me "pls stop".

Also depending on country you might be accused by aiding them, and it would be upon you to explain the court you have no control who uses the exit node nor their ID

Well yeah, because running an exit node in the US is "probably legal but there's precedent for still getting arrested and having your stuff seized." I can't imagine very many normal people are willing to paint a target on their backs like this.

It's insanely few, but also isn't that possibly an advantage? When lots of people's transfers are intermingled that means the possibility of separating out one person's traffic from the rest is harder.

So one person single-handedly knocked out 10% of the entire Tor exit network over an SSH port redirection?

I'm having trouble differentiating the different "attacks" here. Based on your thread it sounds like you're getting a DDoS attack against your nodes. The article appears to show some level of sophisticated OS backdooring (possibly from the ISP being compromised). Are you also seeing attempts to backdoor your nodes?

Thankyou for taking the time to detect and validate/verify those hosts. Is there a way you could make an outbound connection from them (maybe curl) to a site like ifconfig.me [1] and start logging which providers they are on then post a report of them on HN?

[1] - https://ifconfig.me/

What I don't get: Why would you want to access hosts via ssh over TOR?

thank you, you saved the whole world.

You could also do mutual authentication of SSH, with a local password-encrypted private keyfile, if you really like passwords. That gives you all the benefits of the "something you know" factor, without exposing the password to the server. And you can inspect how the decryption and use of the key happens (since it is on your computer), and therefore see it doesn't leave your computer.

Or use fido/gpg in a yubikey - the user gets to authenticate the use of the secret, but it never leaves the hardware token, let alone the client computer.

You don't need to go out and buy hardware keys today. You should be able to use any FIDO2 key these days for SSH, as long as your server runs a recent enough OpenSSH server, which supports ecdsa-sk or ed25519-sk public keys.

Reputable vendors of those hardware keys included Yubikey and Token2, among others. You are really just using them as FIDO2 tokens, so go for what's reputable there.

If you are just getting started, you can generate and use software-backed keys (using ssh-keygen) and copy the public keys to servers' authorized_keys file using ssh-copy-id (or manually adding it). You should probably start learning this way (with plenty of online guides, and fewer risks of an old server implementation not supporting FIDO2 credentials), and then move to hardware keys once you understand the mechanics of copying around public keys, etc. Your password manager might also support acting as an SSH agent for key based logins - I believe Bitwarden and some others now do this, for example.

If you have an iPhone, the ssh client app Terminus can use the Secure Enclave of the iPhone to store your private key, which prevents all apps on the phone, even Terminus itself, from being able to read the private key. The private key is stored in hardware. You use FaceID to approve the login operation that ssh is performing.

I switched over to using that in Terminus recently instead of having Terminus generate and manage the private ssh keys.

Likewise, many Mac and MacBook machines have Secure Enclave too that can store private keys in hardware and works with the ssh client that comes with macOS. But I have not personally started using that yet. Will soon though. You then use TouchID to approve each login operation that ssh is performing.

Yubikey is cool too. I’ve used it mainly for other things than ssh.

Whatever solution you go with, have a backup or another way to restore access when your hardware key eventually breaks and cannot be used.

For example, instead of buying one Yubikey buy three and give each of them access to the same places. Keep one on you, one at home, and one somewhere else. Rotate between using each of them every couple of weeks so you are sure they all still work and that all of them have the accesses to all the same places.

In the case of ssh, you probably either have physical access to the target machine or you have VNC management from the hosting provider, etc, that you can fall back to if you misplace or damage your hardware key. So if you only use the hardware key for ssh and you have other means like those to get back in then having just a single hardware key is mostly fine.

A Yubikey, though simply generating ssh keys instead of using passwords would stop this MITM attack. So would changing the rounds and port of ssh on your system and the remote box making yourself an invisible protocol nothing would recognize.

Yubikey benefits is it stores the keys in the hardware if your laptop is compromised somehow or stolen they at least don't get all the ssh keys too

Administering your hidden service?

privacy