-   Linux - Networking (
-   -   What host does an SSH revers tunnel connect as? (

fhsm 05-02-2012 02:11 PM

What host does an SSH revers tunnel connect as?
If I run the following on my home desktop:

ssh -R 11111:localhost:22 server_user@server_domain
Then from my work desktop run:

ssh home_user@server_domain -p 11111
When I establish this connection to my home desktop from my work desktop using the tunnel through my server as a NAT traversal rendezvous point where will my home desktop see the connection as originating?

I'm trying to trouble shoot a problem with my hosts.{allow,deny} files on my home desktop. I have sshd: ALL set in deny and then sshd: set in allow to limit traffic to my LAN. When I allow ALL the connection works from work. If I allow localhost,, server's IP and my work desktop's IP it does not work. I'm out of ideas, where is this connection coming from?

(sshd at server_domain has GatewayPorts enabled)

Skaperen 05-02-2012 05:41 PM

The TCP connection that was originated on the server end by connecting to port 11111 going to localhost port 22 will appear to come from localhost with some other port number. It will be that ssh process (or one of its cohorts) making the connection, and the source IP address will be appropriate for the destination context. If you were making that connection to another host on your home LAN, it would appear to that other host as if the connection is coming from a LAN interface of the host running the ssh client.

There are two separate TCP connections involved, one at the server connecting TO the port ssh is listening on, and another FROM the ssh client. It's one stream within an ssh managed sub-channel within the TCP connection (a 3rd TCP connection).

fhsm 05-02-2012 06:55 PM

Localhost was my assumption as well; however, that doesn't seem to be the case given that neither /etc/hosts.allow, sshd: localhost sshd: works, but sshd: ALL does work.

Skaperen 05-02-2012 07:10 PM

You could use tcpdump to snoop on the network and see. Use "-i any" to specify the interface so you can sniff on all of them. Use "-n" to skip doing DNS lookups to see the IP addresses. Then run the connections and see what shows up.

fhsm 05-02-2012 09:28 PM

Problem solved, bewilderment in its place.
Thanks for the suggestions.

tcpdump shows the traffic as a back and forth between <server_ip>:22 and <home_desktop_lan_ip>:<high_number_port>. This wasn't unexpected but did give me an idea to try explicitly adding my LAN address to the hosts.allow file, such that it now reads:

sshd: #<home_desktop_lan_ip> at present

Unsurprisingly this did not fix the problem. I ran tcpdump again but without -n and was surprised to see my <home_desktop_lan_ip> was actually resolving to <home_desktop_hostname>. When I changed hosts.allow to:

sshd: <home_desktop_hostname>

I'm able to make the connection without any problem.

It's nice to have the problem fixed without having to use allow ALL, but I'm totally confused by this solution. Why does <home_desktop_hostname> work but none of <home_desktop_lan_ip>, localhost, do?

Skaperen 05-03-2012 12:53 PM

It might be clear to you, since you put it together. But things like this are going to make me ask future questioners to better illustrate their network topology. Reversing a description of a problem back into a network topology is not really very easy.

Maybe I should pick something in my network and break it, and give a description of the symptom, and see how many people can figure it out ... not the problem, but the topology.

Topology gets hard when we add twists like tunnels ... and which kind (stream forwarding tunnels vs. packet link tunnels vs. some other things that some people call tunnels but are not really tunnels).

FYI, I am currently running 72 tunnels on my network. I hope to reduce that number some day.

fhsm 05-04-2012 07:00 AM

  • black are the links
  • green is the tunnel
  • red is the tunneled connection

Any idea why host_name works and none of LAN IP, localhost, do?

Skaperen 05-04-2012 10:40 PM

Ah, there's part of my confusion. I thought the work PC and server were in the same location. So it looks like both PCs need to ssh over the internet to the server. I would use cross forwarding, such as:

Work PC:

ssh -L 11111: -R 11111: -N serveruser@server
Home PC:

ssh -L 22222: -R 22222: -N serveruser@server
and just not start anything on the server at all. To connect:

Work PC to home PC:

ssh -p 11111 homeuser@localhost
This will connect to forwarded port 11111 on the work PC and go through the ssh to the server, which will connect over to port 22222 on the server being listened to by the first ssh from home PC and go to port 22 at the home PC.

Home PC to work PC:

ssh -p 22222 workuser@localhost
This will connect to forwarded port 22222 on the home PC and go through the ssh to the server, which will cronnect over to port 11111 on the server being listened to by the first ssh from work PC and go to port 22 at the work PC.

Home LAN to work PC:

ssh -p 22222 workuser@homepc
This is the same as above, but allows you to do this from other machines on the home LAN.

All times are GMT -5. The time now is 05:56 PM.