Re: ssh X tunnelling question

pa_at_invalid.invalid
Date: 05/07/03 

Date: Tue, 6 May 2003 22:42:09 -0400

Brendan E. Conboy <conboy@raytheon.com> wrote:
> Pierre,

> After some further research I did find something that may make the
> answer to this question easier (I hope). I ran ssh in verbose mode and got
> this error:

> debug1: channel 1: new [x11]
> debug1: confirm x11
> debug1: X11 connection uses different authentication protocol.
> X11 connection rejected because of wrong authentication.
> debug1: X11 rejected 1 i0/o0

> Does this help?

Uh, it doesn't help me one bit, but it might help you :-)

Let's see. You did say that this is a legacy application and that
normal X clients like xclock have no trouble with the tunnel? It
seems that the legacy app doesn't speak MIT-MAGIC-COOKIE-1, so
the sshd at the far end refuses to forward X connections from it.

I just did some experimentation on my laptop. This might work:

    local> xhost +localhost
    local> ssh -R6020:localhost:6000 remotehost
    remote> export DISPLAY=localhost:20
    remote> the_legacy_app

You may need to tweak the numbers. Ports 6000 and 6020 are the X server,
displays 0 and 20. I assume you have a display 0 on your computer and
that you *don't* have a display 20 on the remote. You can check with
"netstat -tan" on both sides. The above ssh command forwards X at the
TCP level instead of through the usual ssh mechanism.

The legacy app tries to connect to display 20 on the machine where it
is running, so it opens TCP port 6020. The ssh tunnel sends that to
your port 6000 without manipulating X cookies because it treats it as a
structureless TCP connection rather than an X forwarding. Your X server
sees the connection and thinks the legacy app is running locally and
trying to connect to display 0. It would normally reject the connection
because of the missing cookie, but you've told it to accept anything
running locally with the "xhost +localhost" that you ran before the
ssh command, so the connection should go through.

Your application should now work. Your co-workers can also run xroach on
you if they have a shell account on your machine. I don't see a way out
of that, you have to lower your guard a bit because you want to run an
application that doesn't understand the default authentication mechanism.
You'll have to figure out the tradeoffs...

Good luck.

Relevant Pages

  • Re: X Windows App
    ... new things regarding VMS to read up on. ... a X11 display is a port/socket connected to ... In the case of SSH tunnel it is not directly ... CREATING a new display on VMS creates an unencrypted/unauthorized connection to ...
    (comp.os.vms)
  • Re: What is The SSH?
    ... Building and Using SSH Tunnels ... What is an SSH tunnel? ... how to use it to make a connection to a server. ... You will need a working SSH client and server installation to build and test ...
    (microsoft.public.windows.server.networking)
  • Re: Run X client with ssh tunnel after su
    ... using the same secure connection that the shell uses. ... the ssh session to the real display host. ... root, root doesn't have the right magic cookie in *its* .Xauthority ...
    (comp.os.linux.x)
  • Re: Problem connecting to SSH, OpenVMS7.3-2, HP TCP/IP v5.4 patched
    ... warning: Authentication failed. ... connection lost (Connection closed by remote host.). ... So, as you can see, I am trying to make an ssh connection with the ...
    (comp.os.vms)
  • Re: Keeping OpenSSH connections alive
    ... The TCP connection is timing out, not the SSH session. ... You can then, reconnect to the backgrounded screen session, upon relogin. ...
    (SSH)