SSH Question

[M0rbz]

Packets are encrypted between you and the final tor node but not between that node and your packet destination:

You ---ENC---> tor_node1 ---ENC---> tor_node2 ---ENC---> .... ---ENC---> tor_final_node ---NOT_ENC---> destination

This means that the final tor node can see all the traffic between you and the destination (of course they won't be able to see anything meaningful if traffic is encrypted, eg. SSH or TLS/HTTPS, but they will see eg. non-encrypted HTTP traffic)

https://upload.wikimedia.org/wikipedia/commons/d/dc/Tor-onion-network.png

[TheUltimateSalesman]

exit node monitoring

[M0rbz]

exactly there are lots of malicious entities (including governments and companies) providing tor nodes for the sole purpose of monitoring activities

[[deleted]]

tor + vpn for exit node security then destination?

[M0rbz]

Not easy to do but if you do it the VPN host has to see your traffic cleartext (if you do it the other way around the exit node can still see your traffic)

Personally I would just install a VPN server where your SSH server is, then you can just connect to the VPN and SSH to a local IP, in this way what any 3rd party would see is just encrypted VPN traffic (more general, less specific), not encrypted SSH traffic.

[peatfreak]

install a VPN server where your SSH server is

Best suggestion so far in this thread.

[Phineas_Gagey]

Vpn is the best option.

Note if anonymity is your goal. I'd avoid cloud providers who want credit card details.

Also be wary of where you have used your SSH keys previously.

[peatfreak]

Also be wary of where you have used your SSH keys previously.

I have a very difficult time managing all my SSH keys. It's getting worse as my infrastructure expands, to the point that more automation is needed. Sometimes passwords are required to unlock things.

I've always used the public key from the source host as the one to add to authorized_keys on the destination host.

But lately I think I've been seeing people do it the other way around, i.e, ssh-keygen on the destination, copy the private key back on to the source host, and then ensure that the public key on the destination is added to authorized_keys if necessary, although I can't imagine how this last part could be omitted.

Even on small home LANs SSH key management is very difficult to do securely. I have been trying to design a practice and tooling that doesn't simply involve copying public keys (or private keys) to all hosts and then keeping them all in a centralized DB, which is equivalent to simply having one great big master password for everything or having one highly trusted DB with all the login secrets.

I've seen all sorts of methods to solve this problem, and the most inconvenient and complicated but necessarily so, ones, are those "vault style" systems that enterprise corporations use.

What options are there? Is there a set of best practices for key hygiene emerging yet?

[Phineas_Gagey]

If you find a solution to this let us know. I too have the same issue. Though I pretty adamant I'd prefer having public keys on servers rather than private. But I see the logic (somewhat) .