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
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 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 (
clientloop.c 1.221) have made the timeout configurable with the
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.