For SSH you can do something like the following:
ssh -o ProxyCommand='nc -x localhost:$orport %h %p' example.com
Options can also be configured in your ~/.ssh/config (or /etc/ssh/ssh_config, or the equivalent on your OS) file:
ProxyCommand /usr/bin/nc -x localhost:$orport %h %p
Rsync can then use ssh as its ...
If you are using PuTTY (for example on Windows) you can configure it to use the Tor client as a SOCKS proxy directly. In Configuration > Connection > Proxy select SOCKS 5, enter localhost and the port Tor client is listening on. The Tor Browser Bundle listens on port 9150 by default.
For PuTTY 0.67, here's what this looks like.
Note that one of the really ...
Read this article if you are interested:
Pietro Abate homepage: hidden ssh service via tor / 16 October 2010
You can use proxifier called torsocks:
# torsocks ssh user@host
Torsocks allows you to use most SOCKS-friendly applications in a safe way with Tor.
It ensures that DNS requests are handled safely and explicitly rejects UDP traffic from the ...
My config for all connections looks like:
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p
And for some domains it can looks like:
ProxyCommand connect -4 -S ...
Looks like ssh can't find your key file. Is the file name tor-cloud-server.pem or tor-cloud-servers.pem?
And are you running this command from your home directory? If not, try an absolute path:
ssh -i ~/tor-cloud-server.pem email@example.com
The NAT punching properties described in the video, are those of onion services. These are a default property of onion services.
Normally if you've providing a service that you want to be accessible behind some NAT, you have to setup some kind of exception on the NAT device (e.g. a home router) to allow incoming connections to a certain port be forwarded to ...
I am not aware of any method to map .onion addresses to local IP addresses like you described, so I am going to propose an alternative approach.
When connecting to an onion SSH service, use the following command syntax:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host
That will make ssh bypass the KnownHosts files and not ask for ...
So if I understand you correctly you want to run a hidden SSH service on your GNU/Linux machine and want to use Windows to access it.
First you have to configure a hidden service. Below I assume that your SSH daemon is already configured and running. Furthermore Tor should be installed. So open your torrc and add:
The article you're referencing is 5 years old. While the Tor network is still fairly slow, I believe it's come a long way since then.
How do we define "slow"?
Either by quantifying the speed, or by reference to something most people are more familiar with. Jobiwan's answer does the latter, using a comparison to an HTTPS connection. Qualifiers like "very" ...
I tend to use socat instead of connect, using the following ProxyCommand:
ProxyCommand socat STDIO SOCKS4A:localhost:%h:%p,socksport=9050
No need to use tor-resolve, as, quoting the man page,
In the command string, any occurrence of '%h' will be substituted by the
host name to connect, '%p' by the port, and '%r' by the remote user name.
And I've ...
Yes, all three cases :
Can a HS(Hidden Service) itself connect to clearnet - Yes, in your case it can. Tor is just a transport layer, so after it has forwarded your query to the HS port - like STunnel - Tor's job is done. And if there's a clearnet exit and no firewall rules prohibition - the server implementing the HS service itself can connect to clearnet ...
A hidden service does not route all the other traffic on the computer through tor. To do that you need transparent proxying on the server.
So - if you set up a server with tor, create a regular hidden service on port 80, then ssh into it through public IP then do any web requests and such on the server then it will be routed through the regular Internet ...
You're not fully understanding how Tor works with traffic, let me explain : it has it's SOCKS listener through which one he can give you an access to the hidden service by default. That's it. It is definitely not an out-of-the-box transparent proxy. You need either to put SSH through SOCKS proxy loke this :
ssh -o ProxyCommand='nc -x <your-...
The issue is that Tails' ssh config will try to use Tor to connect to any internet routable address, with exceptions set for private IP ranges.
Since you're referencing the public address, ssh is trying to use Tor to connect but since the destination only accepts connections from other devices on the same network, it cannot establish a Tor connection.
If you are using a v2 address. It is theoretically possible for it to be found on accident. Security via obscurity isn't very good.
Let's say you up your game. Instead, you use a v3 address. This one is 56 characters long and very unlikely to ever be stumbled upon. Furthermore it has some build in protections that keep it more safe.
You can add one more ...
To define the whole network as subnet, logically, first you would need to know all tor nodes/servers. there are several thousands of nodes and some of them are not public. but if you can collect all that information, maybe it would be possible. but as I know, many tor nodes are at amazon hosting, I think if they just restart server they can change IP address....
If for whatever reason it's not secure to let port 22 open on Internet, why'd it be so inside Tor? What kind of thing would change security risks?
You could be behind some corporate firewall that blocks SSH, while Tor is slightly harder to block.
You may not want to expose your home IP address to the Internet.
Tor has a hidden service authorization feature ...
I'm saddened by the solution. It was on the hidden service side. I made a vanity name/key and copied it into my blog hidden service folder, overwriting the originals. I'm guessing I never ssh'ed in after.
Took 100 minutes over the phone, texting screen pics, etc. Basically attempted to reset permissions to -rw------- from -rw-rw-r--. I'm not sure what ...
First of all, you should be aware that using ssh offers very little, if any, privacy protection. I strongly recommend against it. See this question for why.
Tried to reproduce the issue, appears to work fine here. I set it up like this:
disabled addon Torbutton
disabled addon TorLauncher
set proxy port via environment TOR_SOCKS_PORT=1234 (assuming ssh -D ...
No, you cannot directly have an incoming clearnet IP. I.e. you cannot use the public clearnet IP of a Tor exit relay to anonymously host a server.
Explanation on incoming connections / opening ports:
Indirectly works by using VPN with Remote Port Forwarding or pagekite. See:
The problem was the server was hosted on a non-standard ssh port (2022).
Use the LongLivedPorts to add your port in your torrc and make more stable connections for certain ports
If the ssh server is a hidden service, 22 127.0.0.1:2022 in your torrc will redirect this to a port in LongLivedPorts
Your second computer must have two separate ISP's with different IP addresses, and it should be no problem at all : you will use two virtual machines, one for "using net securely", you will connect to it's VNC through Tor for a first time via first Internet connection, and this VM will go outside through a second VM, that will be a Tor router, WAN-bridged to ...
open up two terminal tabs. in the first tab:
run the following to view the system log. this is a good rule of thumb when trying to troubleshoot.
sudo tail -f /var/log/syslog
in the second tab:
try to connect to your ssh server using your command and configure your browser to use a SOCKS5 proxy at 127.0.0.1:9999. you should see from the syslog that the ...
RDP in version 8 and higher uses UDP for communication. So if the server solely relies on UDP, you can't use it (see Can I use Tor through UDP Protocol?). Windows allows you to use TCP and UDP connections. Please check that the server allows TCP connections. This TechNet article describes where to find the settings.
Now you can connect to the server. Use ...
Below just my though, PollyPocket.
You could define firewall rules to drop all incoming packets to your sshd port except those originating from defined tor exit nodes. Then you could use these exit nodes only to connect to your sshd.
The issue here is a lack of vhost support by sshd so you cannot be sure whether an incoming connection originates from tor ...