How to forward X over SSH to run graphics applications remotely?

  • I have a machine running Ubuntu which I SSH to from my Fedora 14 machine. I want to forward X from the Ubuntu machine back to Fedora so I can run graphical programs remotely. Both machines are on a LAN.

    I know that the -X option enables X11 forwarding in SSH, but I feel like I am missing some of the steps.

    What are the required steps to forward X from a Ubuntu machine to Fedora over SSH?

    I know this is rather common, but I am having issues. A definitive answer for this question would be helpful for many. Lots of examples around seem omit important details.

    One thing to be aware of when reading about X11 is that the terminology is a little weird. Usually the machine that we are sitting at is the client, and the server is the machine that is remote to us.But in the X world, that is flipped around. The machine we are sitting at is creating windows and drawing shapes at the request of the remote machine. So the remote machine making the requests to draw is the "Client", and the local machine that is servicing those requests is the "Server".

  • X11 forwarding needs to be enabled on both the client side and the server side.

    On the client side, the -X (capital X) option to ssh enables X11 forwarding, and you can make this the default (for all connections or for a specific conection) with ForwardX11 yes in ~/.ssh/config.

    On the server side, X11Forwarding yes must specified in /etc/ssh/sshd_config. Note that the default is no forwarding (some distributions turn it on in their default /etc/ssh/sshd_config), and that the user cannot override this setting.

    The xauth program must be installed on the server side. If there are any X11 programs there, it's very likely that xauth will be there. In the unlikely case xauth was installed in a nonstandard location, it can be called through ~/.ssh/rc (on the server!).

    Note that you do not need to set any environment variables on the server. DISPLAY and XAUTHORITY will automatically be set to their proper values. If you run ssh and DISPLAY is not set, it means ssh is not forwarding the X11 connection.

    To confirm that ssh is forwarding X11, check for a line containing Requesting X11 forwarding in the ssh -v -X output. Note that the server won't reply either way, a security precaution of hiding details from potential attackers.

    Don't we need sometimes to set `sudo xhost +client`? When I connect from xubuntu1 to xubuntu2, xubuntu2 running sshd, I do ssh -X from 1, on 2 I type above xhost-command, and then I start a graphical program. Is it a workaround if no modificaton of /etc/*config is wanted?

    @user: No, you never need `xhost +`. `xhost` is from a gentler era when having a machine connected to the network meant you were trustworthy. `xhost +` means anyone who can spoof your IP can take control of your X server session. `ssh -X` will set up all the required authorizations. If X11 forwarding disabled in the server config, talk to your administrator; if that doesn't work, see Forwarding X11 over SSH if the server configuration doesn't allow it.

    Thanks, gilles. Since it was a 192.168.*-address, everybody in the net (eth-xlink-cable) was pretty trustworthy. :)

    Is this answer valid if the client is Mac OS X? It doesn't seem to be working, just sends display to `localhost:10`.

    @McKAMEY Yes, the client can be OSX. On the server (i.e. inside the SSH session), `$DISPLAY` is typically `localhost:10` (the number can vary, it's the first free number starting at 10). If `$DISPLAY` is set in the ssh session, everything should work. If it doesn't, you can ask here; be sure to describe exactly what you did (contents of `.ssh/config`, command line, etc.), and say precisely what is wrong (copy-paste any error message).

    Thanks for mentioning xauth! Lack of that on a barebones server was causing me trouble.

    +1 for making the distinction between `~/.ssh/config` and `/etc/ssh/sshd_config` in the same place. I could not tell if they were different' files or just a change in nomenclature.

    @Gilles Is it still possible to use this method when server is already running a GUI environment? My home server is running basic gnome-panel classic & but when I try `ssh -X [email protected]` it gives me error: `/usr/bin/xauth: /home/$user/.Xauthority not writable.` Any idea why?

    @KhurshidAlam It doesn't matter whether the server is also running a GUI environment. Check the permissions on the `.Xauthority` file. If using Red Hat or other system with SELinux, check the SELinux context, see http://unix.stackexchange.com/questions/36540/why-am-i-still-getting-a-password-prompt-with-ssh-with-public-key-authentication/36687#36687

    @Gilles Ok I deleted `.Xauthority` (as root) on server, now its working fine from one machine (`machine-A`).I have several computers (Desktops,Netbooks, Tablets). I share same private ssh-key across all machines (just copied the `~/.ssh`). But now its showing same error when I try to connect to server from `machine-B`.I think permission set by a machine (on `.Xauthority`) during `ssh -X` doesn't really work for other machine with same ssh-key. I wonder, if there is a nice way to share same ssh-key pair across multiple computers.

    @KhurshidAlam Your setup sounds fine, you can share the same keypair (it's purely a matter of security vs convenience). The permissions on `.Xauthority` have nothing to do with SSH. There's something unusual in your setup, post a new question and be sure to mention the permissions on `.Xauthority` (output of `ls -l ~/.Xauthority`), your distribution, and anything else that seems relevant.

    For googlers: A Kubuntu 13.10 server and Kubuntu 13.10 client failed with "Cannot connect to X server". After investigating all other options, found that DISPLAY environment was not set automatically. So, adding DISPLAY to AcceptEnv in sshd_config solved my case. [AcceptEnv DISPLAY LANG LC_*]

    @Malkocoglu That's odd: `DISPLAY` is not transmitted from the client to the server, it's set on the server side, so it should *not* be in `AcceptEnv`. What value of `DISPLAY` do you get on the remote side? I suspect that your X connection isn't going through the SSH. Also I can confirm that X forwarding works out of the box on Ubuntu 13.10, without adding `DISPLAY` to `AcceptEnv`.

    Both machines are behind distinctive firewalls on distance locations, so no other port or connection available. However, I tried removing DISPLAY from AcceptEnv, it works as intended. I must have forgotten reloading sshd_config at some point so I mixed the results of two consequtive trials. For notation, out of the box configuration did not throw any error in -v mode but was not setting DISPLAY properly.

    after `ssh -X` run `xterm &` to get a graphical terminal as the ultimate test to see if it's working.

    Pretty useful link. This exact issue prevented X11 Forwarding from working for me. I had `~/.ssh/rc` file. And it turned it it's responsible for running `xauth` as such.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM