It really involves how TCP/IP works. When you initiate a connection on a network, your computer uses the interface closest to the destination. So, when you use "remotehost" as the destination, the computer will send the traffic to the network interface that has "remotehost" as it's IP address. This is a "tiny" bit less efficient than using "localhost" as a general rule (some OS's optimize against that, but that's not always the case). When you use "localhost", if you look this up you will see that it has an IP address of 127.0.0.1, and this is treated special on most hosts that have a TCP/IP stack. 127.0.0.1 is considered an interface (called loopback) to an "internal" network local only to the host. So, when you send traffic to 127.0.0.1 you are really saying that you only want it to stay on the local machine. When you say 5900:localhost:5900, the middle item is the destination machine that you want the local port 5900 traffic to be forwarded to, which could be the same as the host your ssh'ing to, or it could be a different machine entirely... In the case of remotehost vs localhost (when they are the same machine) your intent is to tunnel your traffic over ssh to the machine you're ssh'ing to. A good reason to adopt the practice of using localhost, at least from the security paranoid side, is that it's possible for a machine to have multiple IP addresses in it's DNS/hosts entry, and sometimes they can even be different machines behind a single DNS entry (not so common now, but used to be web farms were made this way). So you could say "5900:remotehost:5900 remotehost" and get two different answers for "remotehost", especially since the "remotehost" in your 5900:remotehost:5900 is resolved on the remote host. If DNS or host files are broken, you traffic could end up going to a different machine than you intended. Using "localhost" or "127.0.0.1" makes it much less likely for that to happen (but since I'm a security paranoid type I have to add "but not impossible"). Steve On 5/8/08 4:16 PM, "arguellodw" <arguellodw@xxxxxxxxx> wrote: > > Hello all, > I'm having a difficult time understanding the difference between these two > local tunnels. Here is how I see them: > > =========================================================================== > 1) mymachine: $ ssh 5900:localhost:5900 remotehost > ==> I'm sitting in front of a computer called mymachine, and ssh opens port > 5900 for listening on mymachine and ties the other end of it to port 22 of a > computer called remotehost. The ssh server on remote host then forwards > anything it receives at this port from socket:(mymachine's IP, 5900) to > socket:(remotehost IP, 5900). A schematic might go like this -- > > (mymachine's IP, 5900) --> (mymachine's IP, ssh-chosen port) --network--> > (remotehost IP, 22) --> (remotehost IP, 5900) > > 2) mymachine: $ ssh 5900:remotehost:5900 remotehost > ==> I'm in front of a computer called mymachine, and ssh opens port 5900 for > listening on mymachine and ties it to port 5900 on a computer called > remotehost. A schematic might look like this: > > (mymachine's IP, 5900) --network--> (remotehost IP, 22) --> (remotehost IP, > 5900) > =========================================================================== > > I'm pretty sure I have the right idea in the first instance, but I don't > think I'm right on the second one. According to O'Reilly, the two command > lines accomplish the same thing as far as forwarding the port, but there is > a subtle difference in that the source sockets of the connection are > different from the POV of the receiving end (remotehost IP, 22). > > Can somebody put me on the right track to understanding exactly what these > commands accomplish? > Thanks, > Dan Arguello
