Cannot start xterm over ssh after several successes

Question

I am running some MATLAB scripts on the command-line of a remote computer using ssh. These scripts launch 5 xterms that are forwarded to me via ssh (using the -X option). At the moment I am debugging my code so I am restarting my scripts every now and then. Everything works fine for a couple of runs, but after the N'th time (where N is a random number) I get theses error messages:

xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0

After this I can continue to use ssh except for starting anything GUI-related, meaning that I can no longer start xterms remotely. My only workaround is to restart the ssh connection. Can I fix this somehow to never be bothered again by this?

System

• local system: privately owned laptop, running Chakra Linux, KDE
• remote system: university computer, running openSuSe, KDE

Solution

SSH blocks new X11 connections after 20 minutes in its default setup. To avoid this, run ssh -Y instead of ssh -X, or set the option ForwardX11Trusted yes in ~/.ssh/config.

If you run ssh -v, you'll see the message “Rejected X11 connection after ForwardX11Timeout expired” when a new application tries to connect to the display after the timeout. Without -v (which causes a lot of other debugging output), all the information you get is “Can't open display”.

---

To explain why, I need to give a little background. X11 forwarding allows the destination machine to contact the local X server. This has consequences in terms of security. An X11 server does not isolate applications from each other; this allows the window manager to move windows around and kills them as it wishes, it allows macro processing tools to do that as well and inject keystrokes and so on. Also any application can read and modify the clipboard. This gives a lot of power to remote applications over your local data. If the remote machine is untrusted, with a text mode connection, the worst that can happen is bad stuff on the remote machine. But with an unfettered X11 connection, bad stuff can happen on your local machine too.

X11 includes the “SECURITY extension”, which allows some applications to be declared as untrusted. Untrusted applications get fewer rights, for example they cannot monitor or inject keystrokes in other applications. SSH gives the option of declaring the connection to be trusted (ForwardX11Trusted yes or ssh -Y) or untrusted (ForwardX11Trusted no or ssh -X).

SSH has long defaulted to establishing untrusted connections. As an additional safety feature, untrusted connections can only be established for a few minutes at the beginning of the SSH session; originally 2 minutes (ssh.c 1.202), then 20 minutes (ssh.c 1.207). As a safety feature, I don't see the point: if you're running an untrusted application already, whether another application can be launched later is moot. Recent versions of SSH (ssh.c 1.340, clientloop.c 1.221) have made the timeout configurable with the ForwardX11Timeout.

Unfortunately, due to a bug in X.org (not public at this time), you cannot set an overly large value of ForwardX11Timeout, or else the X server will crash.

Trusted connections are not subject to this expiration mechanism. The trade-off is that malware or a malicious administrator on the remote machine can take control of your local machine. This is often acceptable, but it's up to you to decide.