Forwarding X11 over SSH if the server configuration doesn't allow it

Question

Consider a situation where I'm logging in over SSH from machine A to machine B, I have an X session on machine A, and I want to run an X program on B.

ssh -X B makes this work transparently. But what if the server configuration lacks X11Forwarding yes, I don't have root permissions on the server, and the server administrator is indifferent?

It's obviously possible to forward the X11 connection, since I can transfer whatever I want over the SSH channel. In fact, if the local X server allows TCP connections, it's as easy as ssh -R 6010:localhost:6000 (to be adjusted for the display numbers). What about the common case where the local X server only allows socket connections? How do I do X forwarding conveniently and securely, with a minimum of installation requirements (especially on B)?

Solution 1

@Demi 's answer is good but I think filling it out would be great help.

• local -- the local machine serving an Xserver.
• remote -- the remote machine serving the application which drives the data going to the Xserver

Remote /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Remote ~/.Xauthority is empty or does not exist

On local:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

In the test, local was running Ubuntu 18.05, remote was running Debian Jesse.

Solution 2

Is the protocol X11 speaks when talking to a tcp port any different when talking to a socket?

Perhaps you could combine your own suggested use of ssh -R 6010:localhost:6000 to bring the X11 data in over port forwarding, then bridge the local gab between the tcp port and the X11 socket listener with nc like:

nc -l -p 6000 > /tmp/.X11-unix/X0

Solution 3

1. Spin up an additional X server using Xephyr. This is for security — it prevents the remote system from compromising yours.

2. Use SSH to forward a remote socket to the Xephyr socket. SSH supports forwarding Unix sockets, too.

3. Set the environment variables on the remote server correctly.

Comments

[Gilles 'SO- stop being evil']

Yes, that's the idea. But I was hoping for an answer saying “put this in your .ssh/config client-side and that in your .profile server-side, and then just run ssh B”.

[tcoolspy]

There is an easy "put this in your config" answer, the problem is you rule that out in your question qualifications because the option you need goes in the sshd_config side of things on B. You're trying to work around a block put in place to make it hard to inadvertently open up a security issue.

[Gilles 'SO- stop being evil']

I'm targeting the (in my experience very common) case where the admin doesn't care and just left the default settings in place. X11 forwarding isn't banned by policy, it's just inconvenience by sysadmin indifference. Anyway X11 forwarding allows the server to attack the client, so banning it server-side doesn't make much sense.

[tcoolspy]

@Gilles I agree the default doesn't really protect against anything useful. So should we lobby to get the default changed upstream?

[0e1val]

For me, /tmp/.X11-unix/X0 is a unix domain socket, not a FIFO, so any redirection attempt ends with ENXIO: No such device.