<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Rick Bilonick wrote:
<blockquote cite="mid:1214240795.14310.13.camel@localhost.localdomain"
 type="cite">
  <pre wrap="">On Sun, 2008-06-22 at 17:36 +0930, Tim wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Sat, 2008-06-21 at 19:34 -0400, Rick Bilonick wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">What on the work server could be preventing the reverse tunnel from
working? On the server I do use hosts.allow to only allow ssh from my
home computer. Could this possibly prevent the reverse tunnel from
working? Or is the problem on my home computer?
      </pre>
    </blockquote>
    <pre wrap="">Firewalling?  But we can only guess without detailed information about
the network configuration, on both sides.

I would still try completely avoiding referring to localhost, anywhere.
It's awfully confusing trying to follow your steps, and I can forsee you
getting tangled in a knot.

-- 
[tim@localhost ~]$ uname -r
2.6.25.6-55.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.



    </pre>
  </blockquote>
  <pre wrap=""><!---->
How do you explain that this works fine when going from my home computer
to an account on my ISP's computer? I followed an example posted on the
web (which DID have one mistake in using "localhost" which I corrected -
but the other use of "localhost" is AFAIK correct). In order to do a
reverse tunnel, don't you have to point to localhost in order to use the
forwarded port? 

I don't see this as confusing:

(on my.work.server which is behind a firewall that blocks incoming ssh
but not outgoing ssh)

  </pre>
  <blockquote type="cite">
    <pre wrap="">ssh -R 2022:my.work.server:22 <a class="moz-txt-link-abbreviated" href="mailto:me@home.computer">me@home.computer</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
where "my.work.server" is the IP address for my.work.server and
"home.computer" is the IP address for my home.computer. This sets up the
port forwarding for a reverse tunnel (that's the -R option). If on
home.computer I do:

  </pre>
  <blockquote type="cite">
    <pre wrap="">netstat -an | grep 2022
    </pre>
  </blockquote>
  <pre wrap=""><!---->
it shows that home.computer is listening to port 2022.

Then, to use the reverse tunnel (again on home.computer):

  </pre>
  <blockquote type="cite">
    <pre wrap="">ssh -p 2022 accnt@localhost
    </pre>
  </blockquote>
  <pre wrap=""><!---->
where "accnt" is the user account on my.work.server and I use the
password for accnt on my.work.server. This should allow me then to go
through the ssh tunnel in the reverse direction (getting through the
firewall that is blocking the use of incoming ssh from the home computer
to the my.work.server).

Even after removing everything in hosts.allow on my.work.server, I still
can't connect.

This SAME set up works fine if I set up the tunnel from my home computer
to my account on my ISP's server. And yes I'm using "localhost" similar
to what I show above. And I've tried it from my.work.server to my
account on my ISP but have the same problem so the problem is something
on my.work.server. 

Is it possible for the firewall to block a reverse tunnel (without
blocking outgoing ssh)?

Rick B.

  </pre>
</blockquote>
Rick,<br>
<br>
 What do you see if you add -v to the "ssh -p 2022 accnt@localhost"? 
Also, what if you, instead of using localhost, use the ip address of
your eth0 interface in the previous command?  If you do that and, in
another terminal, do a "tcpdump -i eth0 -vv -l port 2022" do you see
the connection attempt being made to the port?  Also try adding -v to 
the connection where you are creating the tunnel and then watch the
output of that connection as you try to make a connection back over the
tunnel.<br>
<br>
FWIW, I just did your exact setup with two machines that I have and it
worked perfectly (prompted me for passwords and then the logins
worked).   I added -v to both the tunnel creation and then the reverse
use of the tunnel and saw some fun stuff.<br>
<br>
Kevin<br>
<br>
<br>
</body>
</html>