X11 Display Forwarding Fails After Some Time
Are you finding that an ssh session works fine to log in to a remote system and forward the display back to your local machine, but after a while stops being able to start new X11 applications? Specifically, the X11 display forwarding fails after some time, resulting in no usable display for the X11 application.
That’s what happened to me recently and through some debugging I found the solution, which I’ll get to in a minute. In keeping with the purpose of this blog, I’m writing this up because it took a bit of effort to solve, and I found virtually no useful information about it on web searches. Maybe this post will help someone else with a similar problem.
Symptoms of the Problem
My local system is a Mac running the latest Mac OS X (Lion, 10.7.2). I upgraded from 10.6 (Snow Leopard) a month ago, which may have been one source of the problem, but I can’t be certain there is a perfect correlation to that. The remote system is Ubuntu 8.04. The network is hardwired gigabit ethernet. Neither system runs a firewall. Other client systems, such as Ubuntu 11.10, don’t have this problem. It appears to be Mac-specific.
The symptoms are as follows:
- Log in from the Mac to the Ubuntu server using “ssh -X <remote system>”. This works fine and you get a new shell session on the remote system. Due to X11 forwarding, the Mac starts up its X11 server in response.
- From the ssh login shell, start a new X11 application, such as “xterm”. The application puts a window on the Mac’s screen, and it all works fine.
- Now wait a while… I had thought a couple of hours, but it may be less than that. (It may be 20 minutes, see below.)
- Try to open another xterm from the same ssh login shell. It fails with the message “xterm Xt error: Can’t open display: localhost:10.0”
Debugging Clues
After spending a few hours on this, the debug step that led me to the solution was to invoke ssh from the Mac with the highest level of debug logging: “ssh -vvv -X <remote system>”. Follow the same steps and at the time it fails to start a new xterm it will report:
Rejected X11 connection after ForwardX11Timeout expired
It’s an X11 Forwarding Timeout
So there is apparently a timeout for forwarding X11 display over SSH. Web searches for “ForwardX11Timeout” don’t help much; there is very little information about it. Even the Mac OS X’s ssh_config or ssh man page do not even list ForwardX11Timeout as a parameter. A few postings about this parameter are in the context of the Cygwin X server, but the symptoms reported are the same as what I saw. In that context, the default value of the timeout parameter is 20 minutes. It comes into play only for untrusted connections, apparently, but I don’t have a full trust authority system set up since I only do this locally.
Override the Timeout Default (and avoid a Mac OS X bug)
Even though the Mac’s man pages don’t list ForwardX11Timeout as a parameter, adding it to /etc/ssh_config does not cause an unrecognized option error, so it’s a legal option. Of course I would like the longest possible timeout setting, so I started with very long times, like 10000 weeks. This caused the X11 server on the Mac to open, and then immediately crash, sending a report to Apple. I tried a few other settings, for example 0 resulted in timeouts occurring immediately (as opposed to never, which I would have expected), and 10s caused new xterm invocations to fail after about 10 seconds. So this did appear to be the right parameter to fix this.
Finally through a binary search I found that a setting of 596 hours worked: it didn’t crash the Mac’s X11 server, and it doesn’t time out as described above. Why 596 hours? If you convert 596 hours to milliseconds, it’s just under 2^31, and 597 hours is just over 2^31, so there is some kind of signed 32-bit integer overflow problem somewhere along the line.
Solution Recap
The only change that needs to be made is to add the following line to the Mac client’s /etc/ssh_config:
ForwardX11Timeout 596h
It’s possible that using “ssh -Y <remote system>” may work as well, as it may not trigger the untrusted auth timeout. I haven’t tested this.
Ramachandran Ammapet Vijayan
/ Sep 24, 2020Thank you very much!
Raph C
/ Oct 21, 2019This is amazing! Thank you so much!!
PGV
/ Sep 27, 2018Thanks a lot for the fix!! It works perfectly now on my mac.
zz
/ Feb 3, 2018Thanks. that really help!
gio
/ Nov 2, 2017Thanks !!!!!!!!!!!
Cisco
/ Sep 7, 2017Thanks
Petri
/ Aug 14, 2017Thanks for the solution! This has bothered me for the past week 🙂
sephamorr
/ Feb 14, 2016In El Capitan (at least on my system), this fix doesn’t work, as the ssh config location has moved. Simply add the fix to /etc/ssh/ssh_config instead of /etc/ssh_config
Enci
/ Dec 17, 2015Thanks very much. Very helpful
Bill W.
/ Aug 26, 2015Very helpful, thx!
sebastian
/ Jun 25, 2015Genius!!! thanks a lot!!! That was a very annoying bug
Jeff
/ Nov 28, 2014Thanks, this has been annoying me for years!
Dave
/ Nov 14, 2014I experienced the same problem with XQuartz and Mavericks and this seems to have solved it. Great detective work!
Anthony
/ Oct 30, 2014Had same issue with Cygwin. Thanks very much
Liz
/ Sep 26, 2014Thanks so much!
Lowell
/ Aug 7, 2014Saved my day!
Rodney
/ Jul 6, 2014Thanks for the work-around. This has been bugging me for months, couldn’t find a solution.
Wei
/ Jul 2, 2014I was troubled by the same problem. Thank you very much !
Eric
/ Apr 30, 2014Thanks! That timeout was really annoying.
Antonio
/ Mar 7, 2014Great fix ! Thanks a lot sir, you have earned my gratitude and you have avoided me a big headache.
Rob
/ Feb 24, 2014Great detective work! The 20 mins that Matthew refers to is because there is a commented out line in the ssh_config file for the ForwardX11Timeout 1200 which must be in seconds dan default figure. I just uncommented that line and changed the figure to 596h. Thanks as this was really bugging me trying to test a python app.
kat
/ Jan 29, 2014thankyou soooooo much!! sanity saver
jerry
/ Jan 9, 2014Thanks I had same issue with cygwin, trying the same
Nik
/ Dec 17, 2013Thank you. I was not looking forward to resolving this, you likely saved me hours of frustration.
xdeimos
/ Apr 25, 2013Hi, Im little bit confuse with ur post
1. do u have to access /etc/ssh_config through ur mac?
I do not have that path though
2. what do u mean u can also try ssh -Y
please email me with this issues
thank you
Mike
/ Jun 22, 2013/etc/ssh_config is available and has been at least since Lion, I believe (and maybe before that), but of course you must have administrator permissions to edit the file.
You can type “ssh -Y” to get around this whole problem, but there may be some security issues with that. I would read up on the tradeoffs. Excerpt from the ssh man page for the -Y option says: “Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.”
Alan
/ Apr 8, 2013Wow, this was so frustrating. Glad I finally found your tip.
Roland
/ Jan 30, 2013Thanks for the post. I just ran into this installing a remote Oracle database and it kept failing half way through because it could send out the display. Nice job!
John
/ Jan 23, 2013It’s not a bug, it’s how OpenSSH works. and you don’t have to set
ForwardX11Timeoutto something stupid long, just setForwardX11Trusted yesin your~/.ssh/configor/etc/ssh_configfilesCraig Macdonald
/ Jan 16, 2013man ssh_config details ForwardX11Timeout:
Interestingly, I couldn’t put the option in my (NFS shared) ~/.ssh/config, as some linux ssh (e.g. OpenSSH_4.3p2) didn’t recognise ForwardX11Timeout.
Jyri Virkki
/ Jan 11, 2013Thanks!
Greg
/ Nov 7, 2012Thank you very much for this post. I have been fighting this exact issue since I was forced into a 10.7 upgrade in September. I had the parameter name correct, but kept trying to make it work with 30d.
Karl
/ Jul 5, 2012Thanks!
Gabri
/ Jul 5, 2012Many thanks for your solution!
Bob
/ May 10, 2012Thanks so much for that fix!
Mike
/ Mar 7, 2012Matthew, thanks for the info. I’ve entered the bug at FreeDesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=47053.
Matthew
/ Mar 6, 2012Surprisingly, I still see the crash if I use XQuartz 2.7.1. http://xquartz.macosforge.org/trac/ticket/553 was opened, but closed with a message it should be filed at freedesktop.org. a search there for “ForwardX11Timeout” returns no results, so I’d guess it’s not bee reported to them. I was going to file it myself, but I don’t care enough to create an account.
Matthew
/ Mar 1, 2012Have you filed a bug with Apple? if so, could you share the rdar?
I’ve confirmed that it is a 20 minute timeout, and that ‘ssh -Y’ does appear to avoid the problem.