解决xterm显示远程窗口出现“Can't open display: localhost:11.0”的问题
参考：http://unix.stackexchange.com/questions/117159/cannot-start-xterm-over-ssh-after-several-successes
问题描述：
远程调用gnuplot，
> plot 'out.txt' using 1:2。
出现，
>Error: Can't open display: localhost:11.0。
时好时坏——偶尔能显示，过会儿又不能显示。问题很难定位。
解决方法：
1 使用 ssh -Y 代替 ssh -X
或
2 在 ~/.ssh/config 中添加 ForwardX11Trusted yes
原文：
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.