In principle there are three methods for authorizing a remote application to use your screen.

  • Using SSH
  • Using Magic Cookies; the .Xauthority file on the remote system
  • With the xhost command on your workstation (deprecated)

We recommend only the first method. The second method is somewhat complicated. The third method is not safe.

Using SSH

When you use ssh to connect to a host, all that is required to run X-applications is done automatically.
SSH takes care of the X-window traffic, and setting the DISPLAY environment variable, you only need to add the -X flag to the ssh command depending on the configuration of your system.
Find additional info about the usage of ssh here.

When using PuTTY under Windows, choose 'Tunnels' from the 'Category' list and check the option 'Enable X11 forwarding'. Please note that you need a separate X-server, e.g. http://www.straightrunning.com/XmingNotes/.

Magic Cookies

First we define a few terms by which your environment is defined:

''myscreen'' the name of your X-screen, e.g. lotus.faculty.university.nl:0.0 Note, that you enter the full name, including the domain. ''saralogin'' your login name on the SURF system, e.g. h231tine

Using magic cookies you can allow remote applications to make use of your display.

This is how it works: When you start a X-session on your workstation, a file .Xauthority is created. This file contains a random chosen key (''cookie''). When you do not use the xhost-command, only X-applications who know that cookie can get access to your display. X-applications look in the file .Xauthority for the specific cookie belonging to the display.

In order to transport the Magic Cookie in your .Xauthority file on your workstation to the .Xauthority file in your home directory on SURFs system, do the following:

  • Enter the following commands to export the magic cookie to the SURF system:
export DISPLAY=myscreen
xauth extract - $DISPLAY | ssh saralogin@SARASYSTEM xauth merge -

You have to do this every time you start a new session on your workstation.

xhost

We only list xhost for the sake of completeness: DON'T USE XHOST.

There is a famous security problem connected with using X11 applications if your workstation is running some kind of Unix.
Many people used the xhost command to produce X11 output on their screens.
Not everybody is aware of the fact, however, that using the xhost command one creates very likely a situation where somebody, also logged in on the remote system can get access to the X-server running on the workstation and is able, for example, to read out every keystroke.