Sometimes we need transmit data through a socket between different machines, such as a Telnet connection, an FTP file download, an SQL query or any other type of transmission.
That data travels raw through the network, so unsafe, which means that they could be intercepted by any node that is on the path between the origin and the destination, that is, stolen.
We cannot prevent this data from being captured, but what we can prevent is that it is interpreted and understood by third parties, encrypting the communication.
SSH is the tool that allows us to do secure connections between machines. Its most common use is to connect remotely to a command interpreter.
However, it offers other possibilities, such as creating encrypted tunnels between different machines.
Suppose we want to telnet from host1 to host2:
host1$ telnet host2
This communication is totally open and can be intercepted. To protect it, we will redirect an arbitrarily chosen port (for example 5000) on host 1 to port 23 (telnet) of host2.
In this way we will get all the data sent to port 5000 of host1 to travel encrypted through the tunnel that ssh opens through port 22 of host2 and then be redirected to port 23 of host2, thus reaching its final destination.
To do this, we need to know the username and password of host2.
To open the tunnel we write:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
O well:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Both options are equivalent. To establish the telnet connection, we no longer refer to host2 but to the port chosen on host1:
host1$ telnet localhost 5000
With this we make any communication secure, be it telnet or otherwise. Investigating a little more we will see that thanks to the power of SSH These redirections can also be made to third machines, which would allow us that with a single entry point we could safely access from an entire LAN to a different LAN.
The theory looks extremely interesting, but it would be even more so if we saw a practical case.
But the truth is that, even though I was short, I loved the article.
maybe looking at the wiki you get inspired https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
and the same, but the autossh section https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Actually, anything you can send by ssh, be it streaming, connections to the host. etc. that for x reason you want to encrypt them.
and the securecrt rules
I sometimes use SSH at a very basic level. The default port is 22, right?
So, if I understand correctly, my pc is host 1 and the one I want to connect to host2, this tunnel would create a connection between port 5000 and its port 23, and then end up on port 22?
Why the reasons for switching ports? Can you create a tunnel with port 22?
Very interesting article. Like nano, I'm wanting more!
SSH does indeed use port 22 by default (although it can be changed). This port is the one that would be used by the actual communication between the two hosts. It is the one that you have to make sure that it is open and no firewall cuts it off. But for the user it is totally transparent. You can forget about him. In the example, the redirection is between ports 5000 and 23. Those two are the only ones you have to worry about. The user will see that everything he sends to port 5000 of his host appears at 23 of the destination host.
Obviously, each user can redirect the ports he considers appropriate.
Thanks for your comments. This is my first post and your opinions will help make the next one better.
Can that also be done with VPS?
Ok this is my case, PC1 has access to a server, but PC2 does not, both connect by ssh, I want to have access in PC2, but which port of PC1 do I redirect? if actually what I want is to reach the server port from PC2 and that the packets have PC1 as their source IP. do I understand?
You make yourself understood. In this case you need PC1 to redirect a port of PC2 to port 22 of the server:
PC2 $ ssh -L 5000: Server: 22 user PC1 @ PC1
and, keeping this connection open, from another terminal:
PC2 $ ssh userServer @ localhost -p 5000
and you're already inside.
Finally a functional solution !! Thank you Getafix, you have given me a world of possibilities !!
I'm glad!
Excellent article. welcome to DesdeLinux 😀
And what to do if we have 22 blocked? LOL..
Thanks elav.
If you have port 22 blocked, mmmm, we will have to look for an alternative to hack the XD firewall
And worst of all (hypothetical): that it is blocked by the VPS provider.
I just did an exam a few hours ago with questions about it 😛
I would not say that:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
it is equivalent to the other command line ... the one with the -L.
Since -R indicates that the port that is opened to new connections is on the remote side, that is, on the side of your ssh server; while -L opens a port on the Local side, on the client side to receive new connections.
The translation of the line:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
It would be something like this: Being on host1, connect to the ssh server (port 22) of host2 with my user userhost2 and forward the connections generated on remote port 5000 of host2 to port 23 on host1 (my localhost)
If not, correct me! 😉
—–
On the other hand ... if a server has blocked the entry of connections to port 22, that is, we cannot connect remotely to the ssh server; what can be done is; that from the server (a friend sysadmin behind the firewall of the remote host2 system) a command line is executed:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f goes to background
-N does not execute any command on the remote
nohup prevents the execution of the command from being interrupted when logout
host1 $ ssh userhost2 @ localhost -p 6000
In this way, from host1 we generate a connection to localhost (the same host1) on port 6000 that will forward the connection to port 22 of the remote system host2, in which we will log in with the user host2.
This would allow (I didn't test it, but it sounds like it works) to log into an ssh server blocked by firewal with a little help from within! 😀
The latter I read from an explanation made in The Geek Stuff magazine
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
I really like your publication; I read them often!
Greetings.
You are right. There is an error in the article. Redirects are not equivalent. The command host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 performs the reverse redirection, that is, it redirects the remote port 5000 to the 23 local, the opposite of what the command with -L does.
Thank you for the correction.