Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a new and vexing problem with ssh forwarding my X11 connection when logging in from a Mac (10.7.2) to Linux (Ubuntu 8.04). I have no trouble using ssh -X to log in to the remote machine and starting an X11-based application from that shell.

What has recently started happening is that additional invocations of X11 applications from that same shell, after a while (on the order of hours), are unable to start because the forwarded display is being blocked (I presume). When attempting to start xterm, for example, I get the usual message about a bad DISPLAY setting, such as:

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

But the X11 application I started right when I logged in is still running along just fine, using that exact same display (localhost:10.0), just that it was started earlier.

I turned on verbose logging in sshd_config and I see this in the /var/log/auth.log file in response to the failed xterm startup attempt:

sshd[22104]: channel 8: open failed: administratively prohibited: open failed

If I ssh -X to the server again, starting a new shell and getting assigned a new display (localhost:11.0), the same process repeats: the X11 applications started early on run just fine for as long as I keep them open (days), but after a few hours I cannot start any new ones from that shell.

Particulars: OpenSSH sshd server running on Ubuntu 8.04, display forwarded to a Mac running Lion (10.7.2) with the default Apple X server. The systems are connected on an Ethernet LAN with a single switch between them. Neither machine is running a firewall. Until recently (a few days ago) this setup worked perfectly so I am mystified as to where to look next. I am by no means an X11 or SSH expert but have good UNIX/Linux experience. Nothing obvious has changed in either client or server configuration although I have tried changing a few options to try to debug this, like setting sshd_config's TCPKeepAlive to no, and setting "host +localhost" (you can tell I've been Googling).

When logging in from a Linux 11.10 laptop to the same remote host over the same network and switch, this problem does not occur -- an xterm can be invoked successfully hours later from the same ssh login shell while the same experiment from the Mac fails (tested this morning to be sure), so it would appear to be a Mac-specific issue.

With "LogLevel DEBUG3" set on the remote machine (sshd server), and no change made in the client connections by me, /var/log/auth.log shows one slight change in connection status reports overnight, which is the port number used by the one successful ssh session from the Linux machine (I think), connection #7 below:

sshd[20173]: debug3: channel 7: status: The following connections are open:\r\n #0 server-session (t4 r0 i0/0 o0/0 fd 14/13 cfd -1)\r\n #3 X11 connection from port 57564 (t4 r1 i0/0 o0/0 fd 16/16 cfd -1)\r\n #4 X11 connection from port 57565 (t4 r2 i0/0 o0/0 fd 17/17 cfd -1)\r\n #5 X11 connection from port 57566 (t4 r3 i0/0 o0/0 fd 18/18 cfd -1)\r\n #6 X11 connection from port 57567 (t4 r4 i0/0 o0/0 fd 19/19 cfd -1)\r\n #7 X11 connection from port 59007

In this report, everything is the same between status reports except the port number used by connection #7 which I believe is the Linux client -- the only one still maintaining a display connection. It continues to increment over time, judging by a sequence of these reports overnight.

Thanks for any help,


share|improve this question
I'm experiencing the same problem. – churnd Jan 6 '12 at 14:40
I turned on -vvv on the ssh command to get debug info from the Mac's client side ssh session. I got this: codeRejected X11 connection after ForwardX11Timeout expired ForwardX11Timeout is an option in the Mac's ssh client that limits forwarding from an untrusted connection. Potentially using -Y instead of -X would work. ForwardX11Timeout is not documented in Lion's ssh man page. Its default appears to be 20 minutes. Setting it higher in ssh_config is possible but Lion's X server crashes if set to > 596 hours... which, in milliseconds, overflows 31 bits. Arrgh. Hope this fixes it. – mklein9 Jan 6 '12 at 16:30
up vote 12 down vote accepted

The ssh sessions started after I changed the Mac client's /etc/ssh_config to include the line:

ForwardX11Timeout 596h

are all working fine and have been all day. By now they all would have been refusing to start new xterms. So I believe this is the answer, and luckily a simple solution, but the timeout will still happen 3-1/2 weeks from now.

share|improve this answer

man ssh_config


If this option is set to "yes" remote X11 clients will have full access to the original X11 display. If this option is set to "no" remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time. The default is "no" See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.

share|improve this answer
It might be helpful if you expanded on why you think this configuration option would solve the original problem. – pjmorse Oct 12 '12 at 1:05
This does explain why the problem happens, but some reasoning would be helpful. – Stefan Lasiewski Mar 26 '15 at 23:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.