open failed: connect failed: Connection refused

open failed: connect failed: Connection refused

Post by i.am.tho » Mon, 16 Jan 2006 14:29:48


Hi all -

I am trying to connect to a computer behind a firewall by being tricky
with ssh. I want to start an ssh session from behind the firewall to a
computer on the outside, and then run an xterm on the firewalled
computer that is displayed on the outside computer, like I show below.
Then I can go to the outside computer and have shell access (and thus
everything else) to the firewalled computer.

{FC = Firewalled computer, OC = Outside computer}

[OC shell 1]$ xhost + # for now
[FC shell 1]$ ssh -Y -N -L 6007:localhost:6000 OC
[FC shell 2]$ export DISPLAY=localhost:7.0
[FC shell 2]$ xterm

Nothing happens on the OC. FC shell 2 errors with "X connection to
localhost:7.0 broken (explicit kill or server shutdown)." and exits.
FC shell 1 errors with "channel 3: open failed: connect failed:
Connection refused" but stays running.

I have tried the ssh command with both -X and -Y but it doesn't matter.
I have also put the line 'AllowTCPForwarding yes' in my
/etc/ssh/sshd_config file on OC. I am using "OpenSSH_4.2p1, OpenSSL
0.9.7f 22 Mar 2005" (Fedora Core 4) on both machines.

Any ideas?
Thanks,
Thor
 
 
 

open failed: connect failed: Connection refused

Post by Richard E. » Mon, 16 Jan 2006 16:24:53

>

But this is not what you show below.


This shows you connecting from the outside host inward, not the other way
around.

--
Richard Silverman
XXXX@XXXXX.COM

 
 
 

open failed: connect failed: Connection refused

Post by Thor » Mon, 16 Jan 2006 18:52:23

> This shows you connecting from the outside host inward, not the other way

I do not see why you say this. The ssh command establishes the tunnel
and forwards X traffic from virtual server 7 on the firewalled computer
to the main, real server on the outside computer. Am I doing something
backwards?
 
 
 

open failed: connect failed: Connection refused

Post by Richard E. » Mon, 16 Jan 2006 21:09:25

>>>>> "Thor" == Thor < XXXX@XXXXX.COM > writes:

>> This shows you connecting from the outside host inward, not the
>> other way around.

Thor> I do not see why you say this. The ssh command establishes the
Thor> tunnel and forwards X traffic from virtual server 7 on the
Thor> firewalled computer to the main, real server on the outside
Thor> computer. Am I doing something backwards?

You said:


That means running an ssh command on the inside host, and connecting to
an SSH server on the outside host. You show the opposite in your series
of commands.

--
Richard Silverman
XXXX@XXXXX.COM
 
 
 

open failed: connect failed: Connection refused

Post by Thor » Tue, 17 Jan 2006 05:46:02

> That means running an ssh command on the inside host, and connecting to

The ssh command IS run on the inside host (Firewalled computer = FC)
and connects to a server on the outside host:
[FC shell 1]$ ssh -Y -N -L 6007:localhost:6000 OC
-- boils down to --
[FC]$ ssh ... OC
 
 
 

open failed: connect failed: Connection refused

Post by Richard E. » Tue, 17 Jan 2006 06:27:39

>

Sorry; I'm not being clear. X forwarding works like this: if you ssh from
A to B with X forwarding on, it allows you to run X clients on B and have
them display on an X server running on A. That is what the -Y in your
command does. You, however, want to do the oppsite, and are forwarding a
local port to the X server on the remote side. The -Y in your command is
irrelevant and will have no effect on what you're trying to do.

What you're trying can work. However, the SSH error suggests that there's
nothing listening on port 6000 on the outside host. Try the host's
non-loopback IP address instead of localhost, on the chance that it's not
listening on the loopback. It's also possible that the X server is not
listening via TCP at all; if it's configured for local clients only, it
may be using a Unix socket only.

--
Richard Silverman
XXXX@XXXXX.COM
 
 
 

open failed: connect failed: Connection refused

Post by Job Eisse » Tue, 17 Jan 2006 08:18:15


Try:
[FC shell]$ ssh -R 2222:localhost:22 OC
[OC shell]$ ssh -p 2222 -X localhost
[OC->FC shell]$ xterm
 
 
 

open failed: connect failed: Connection refused

Post by Thor » Wed, 18 Jan 2006 06:23:32

Thanks Richard and Job for your comments.

Job, that is a beautiful bit of ssh magic! It worked perfectly!

I can see why it works - again very impressive - but I have to admit
I'm still not entirely sure why the way I first tried it didn't work.
Does it have to do with authentication issues?

Thanks,
Thor
 
 
 

open failed: connect failed: Connection refused

Post by Job Eisse » Wed, 18 Jan 2006 08:11:58

Thor wrote on mapping X back to remote:

I have worked with X for about 15 years now, and still do not know how
the authentication works, only that it usually involves
MIT-MAGIC-COOKIEs, and you can play about with xauth; ssh does more
magic with it, the -X and -Y switches are more than just tunneling port
6010.
 
 
 

open failed: connect failed: Connection refused

Post by Richard E. » Wed, 18 Jan 2006 13:08:05

>>>>> "JE" == Job Eisses < XXXX@XXXXX.COM > writes:

JE> Thor wrote on mapping X back to remote:
>> I'm still not entirely sure why the way I first tried it didn't
>> work. Does it have to do with authentication issues?

See what I wrote earlier; it doesn't look like it. You were not getting a
connection to the X server (see "connection refused"). Your SSH port
forwarding explicitly used TCP, whereas the SSH client initiating the X
forwarding can recognize and use a Unix socket instead; if your X server
is only using a Unix socket for X clients, that would explain it.

JE> I have worked with X for about 15 years now, and still do not know
JE> how the authentication works, only that it usually involves
JE> MIT-MAGIC-COOKIEs, and you can play about with xauth; ssh does
JE> more magic with it, the -X and -Y switches are more than just
JE> tunneling port 6010.

The initial X connection messages sends authentication info: a type, and
some type-specific data. MIT-MAGIC-COOKIE is just one type, albeit the
most common -- there are other methods defined as well, such as Kerberos
and DES (working with Sun's secured NIS+). Usually, when the X server is
started, it generates a cookie (random string) and gives it to its invoker
(e.g. xstart or xdm), which will place it in the user's ~/.Xauthority file
under the local display name. The Xlib linked into X clients will
automatically look up the authentication info for the display, and supply
it to the server.

The extra work that SSH X forwarding does beyond plain port forwarding is:

* xauth: it automatically arranges X authentication on the remote side.

* xauth spoofing: it generates a second xauth cookie for use on the remote
side (for access to the X proxy), so that the local cookie is not
revealed.

* local display connection: as mentioned above, it can connect on the
local side via Unix domain socket as well as TCP, if needed.

* automatic setting of the DISPLAY variable

--
Richard Silverman
XXXX@XXXXX.COM
 
 
 

open failed: connect failed: Connection refused

Post by Thor » Thu, 19 Jan 2006 09:59:11

Very interesting - thanks. I guess that's why I had to ssh back to the
FC using the local port - so ssh would set up the second xauth cookie,
etc.

Any ideas how to keep the original ssh tunnel from FC to OC open even
during long periods of inactivity? The session seems to timeout (i
think it's a timeout) during the long commute home in LA traffic.

Justin
 
 
 

open failed: connect failed: Connection refused

Post by Richard E. » Thu, 19 Jan 2006 14:29:43

>>>>> "Thor" == Thor < XXXX@XXXXX.COM > writes:

Thor> Very interesting - thanks. I guess that's why I had to ssh back
Thor> to the FC using the local port - so ssh would set up the second
Thor> xauth cookie, etc.

Thor> Any ideas how to keep the original ssh tunnel from FC to OC open
Thor> even during long periods of inactivity? The session seems to
Thor> timeout (i think it's a timeout) during the long commute home in
Thor> LA traffic.

http://www.yqcomputer.com/

--
Richard Silverman
XXXX@XXXXX.COM