>>>>> "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
* 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