11

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)?

Improve this question
0

3 Answers 3

Reset to default
7

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
Improve this answer
5
  • 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”.
    – Gilles 'SO- stop being evil'
    Commented May 7, 2011 at 10:13
  • 1
    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.
    – Caleb
    Commented May 7, 2011 at 10:21
  • 3
    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.
    – Gilles 'SO- stop being evil'
    Commented May 7, 2011 at 10:56
  • @Gilles I agree the default doesn't really protect against anything useful. So should we lobby to get the default changed upstream?
    – Caleb
    Commented May 7, 2011 at 11:04
  • For me, /tmp/.X11-unix/X0 is a unix domain socket, not a FIFO, so any redirection attempt ends with ENXIO: No such device.
    – Samveen
    Commented Jun 5, 2015 at 5:17
2

@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.

Improve this answer
2

  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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .