3

I'm trying to tunnel through a public IP to a private server's port 80. I know for a fact that apache is running on port 80 because if I ssh into the public IP I can access the private server via lynx just fine. The command I am using is as follows:

ssh <remote_public_id> -N -L 9080:<private_ip_of_other_server>:80

Then accessing http://localhost:9080 says unable to connect. I'm doing this from OSX. Running ssh -version I get the following in case it matters:

OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009

As requested by Ernest, here is some debug. This is after I enter my password. Removed IP address for security purposes.

debug3: packet_send2: adding 48 (len 63 padlen 17 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: Local connections to LOCALHOST:9080 forwarded to remote address <private_ip>:80 debug3: channel_setup_fwd_listener: type 2 wildcard 0 addr NULL debug1: Local forwarding listening on ::1 port 9080. debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 9080. debug2: fd 5 setting O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 1: new [port listener] debug1: Requesting [email protected] debug1: Entering interactive session.

And then this debug when I make a request:

debug1: channel 3: free: direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64917, nchannels 5 debug3: channel 3: status: The following connections are open: #2 direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64912 (t4 r0 i0/0 o0/0 fd 6/6 cfd -1) #3 direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64917 (t4 r1 i3/0 o3/0 fd 7/7 cfd -1) #4 direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64918 (t3 r-1 i0/0 o0/0 fd 8/8 cfd -1) debug3: channel 3: close_fds r 7 w 7 e -1 c -1 debug2: channel 4: open confirm rwindow 2097152 rmax 32768 debug2: channel 4: rcvd eof debug2: channel 4: output open -> drain debug2: channel 4: obuf empty debug2: channel 4: close_write debug2: channel 4: output drain -> closed debug2: channel 4: read<=0 rfd 8 len 0 debug2: channel 4: read failed debug2: channel 4: close_read debug2: channel 4: input open -> drain debug2: channel 4: ibuf empty debug2: channel 4: send eof debug2: channel 4: input drain -> closed debug2: channel 4: send close debug3: channel 4: will not send data after close debug2: channel 4: rcvd close debug3: channel 4: will not send data after close debug2: channel 4: is dead debug2: channel 4: garbage collecting debug1: channel 4: free: direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64918, nchannels 4 debug3: channel 4: status: The following connections are open: #2 direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64912 (t4 r0 i0/0 o0/0 fd 6/6 cfd -1) #4 direct-tcpip: listening port 9080 for zmanda port 80, connect from ::1 port 64918 (t4 r1 i3/0 o3/0 fd 8/8 cfd -1) debug3: channel 4: close_fds r 8 w 8 e -1 c -1
Improve this question
4
  • Well, fancy meeting you here :) I would try running with ssh -v -v -v to get some extra debug info, and then report back. That command certainly looks right to me. Commented Jun 16, 2011 at 0:59
  • Is connecting to other_server via IP and not hostname causing it to have problems serving the page because it's doing virtual hosts and needs a hostname header to know what to serve? Commented Jun 16, 2011 at 1:22
  • Ernest, do I know you? ;) I've added some debug. Commented Jun 16, 2011 at 2:37
  • blahdiblah - I tried with the hostname and I get the same results. Commented Jun 16, 2011 at 2:40

1 Answer 1

Reset to default
3

So the issue was a few things.

  1. The web application is running over SSL so I had to do port 443 instead of 80
  2. For whatever reason, you can't forward 443 to a different local port. So I had to forward to 443.

The final command looked like this:

sudo ssh gdboling@<public_ip> -N -L 443:<private_host>:443
Improve this answer
3
  • You can't do a port redirect for 443? Is that specific to the OSX port of SSH? Commented Jun 16, 2011 at 21:36
  • 1
    The guy that I got the answer from was using Winblows. I don't think that you can't. It's just that it doesn't work well with this particular web application. It could be the app, I really don't know for sure. Commented Jun 16, 2011 at 23:40
  • This is not specific to the port, but (my guess is) to SSL. I had exactly the same issue with some enterprise software running a web interface on port 8443. When i made a tunnel from 8000, it did not work. When i nicely tunneled 8443 to 8443, everything was just fine. (OSX Mavericks) Commented Mar 5, 2014 at 16:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.