X11 Display Forwarding Fails After Some Time

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:

  1. 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.
  2. 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.
  3. 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.)
  4. 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.

Leave a comment

34 Comments

  1. sephamorr

     /  Feb 14, 2016

    In 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

    Reply
  2. Enci

     /  Dec 17, 2015

    Thanks very much. Very helpful

    Reply
  3. Bill W.

     /  Aug 26, 2015

    Very helpful, thx!

    Reply
  4. Genius!!! thanks a lot!!! That was a very annoying bug

    Reply
  5. Jeff

     /  Nov 28, 2014

    Thanks, this has been annoying me for years!

    Reply
  6. I experienced the same problem with XQuartz and Mavericks and this seems to have solved it. Great detective work!

    Reply
  7. Anthony

     /  Oct 30, 2014

    Had same issue with Cygwin. Thanks very much

    Reply
  8. Liz

     /  Sep 26, 2014

    Thanks so much!

    Reply
  9. Lowell

     /  Aug 7, 2014

    Saved my day!

    Reply
  10. Rodney

     /  Jul 6, 2014

    Thanks for the work-around. This has been bugging me for months, couldn’t find a solution.

    Reply
  11. Wei

     /  Jul 2, 2014

    I was troubled by the same problem. Thank you very much !

    Reply
  12. Eric

     /  Apr 30, 2014

    Thanks! That timeout was really annoying.

    Reply
  13. Antonio

     /  Mar 7, 2014

    Great fix ! Thanks a lot sir, you have earned my gratitude and you have avoided me a big headache.

    Reply
  14. Rob

     /  Feb 24, 2014

    Great 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.

    Reply
  15. kat

     /  Jan 29, 2014

    thankyou soooooo much!! sanity saver

    Reply
  16. jerry

     /  Jan 9, 2014

    Thanks I had same issue with cygwin, trying the same

    Reply
  17. Thank you. I was not looking forward to resolving this, you likely saved me hours of frustration.

    Reply
  18. xdeimos

     /  Apr 25, 2013

    Hi, 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

    Reply
    • 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.”

      Reply
  19. Wow, this was so frustrating. Glad I finally found your tip.

    Reply
  20. Roland

     /  Jan 30, 2013

    Thanks 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!

    Reply
  21. John

     /  Jan 23, 2013

    It’s not a bug, it’s how OpenSSH works. and you don’t have to set ForwardX11Timeout to something stupid long, just set ForwardX11Trusted yes in your ~/.ssh/config or /etc/ssh_config files

    Reply
  22. man ssh_config details ForwardX11Timeout:

    ForwardX11Timeout
    Specify a timeout for untrusted X11 forwarding using the format described in the TIME FORMATS section of sshd_config(5). X11 connections received by ssh(1) after this time will be refused. The default is to disable untrusted X11 forwarding after twenty minutes
    has elapsed.

    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.

    Reply
  23. Jyri Virkki

     /  Jan 11, 2013

    Thanks!

    Reply
  24. Greg

     /  Nov 7, 2012

    Thank 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.

    Reply
  25. Thanks!

    Reply
  26. Gabri

     /  Jul 5, 2012

    Many thanks for your solution!

    Reply
  27. Bob

     /  May 10, 2012

    Thanks so much for that fix!

    Reply
  28. Mike

     /  Mar 7, 2012

    Matthew, thanks for the info. I’ve entered the bug at FreeDesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=47053.

    Reply
  29. Matthew

     /  Mar 6, 2012

    Surprisingly, 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.

    Reply
  30. Matthew

     /  Mar 1, 2012

    Have 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.

    Reply
  1. Remote X11 on OS X | A potted account of Ross' life
  2. A Better Mobile Display for the Raspberry Pi « Jeff's Skinner Box
  3. A Better Mobile Display for the Raspberry Pi (and my journey to a better understanding of X) « Jeff's Skinner Box

Leave a Reply

Your email address will not be published. Required fields are marked *