X11 DISPLAY from remote Unix host does not launch.

Question

X11 is coming up with some very strange behaviour.
Launching X applications to display back on my Mac was working till just the last week or so. Now, for the most part, after setting up xhost on the Mac and settting the DISPLAY environment variable on the remote host.
Launching xterm (for example). Results in can't open display"ip addr:0" and "error couldn't find per display information".
But this does not happen in all cases. I have found one server where my display will route back.
I created a new account on my Mac and tried to see if it would work in a fresh account. X display works now in my fresh account for all the nodes that I can't access in my "regular" account.
I have removed my .Xauthority file and my .Xresoures file to see if anything in there was corrupting my ability to route the DISPLAY. This has had no affect.
What other Mac OS X files would affect the characteristics of how X11 is working?
Warren

Answer 1

Hi Zoarre,
> why doesn't -X work in tiger? isn't it more secure?
   Yes, the -Y option is very much less secure than the -X option. Unfortunately as you've noticed, this strict interpretation of "trusted" can be shall we say, inconvenient. You can read more about the X11 Security Extension Specification by downloading the PDF document from security.pdf.
   The use of the -Y option will cause all X11 apps that you forward to be treated as "trusted". In the X11 Security Extension Specification, this means that the application can be trusted to be harmless and thus that security may be lax. For instance, xclock only conveys the local time and this information can be compromised without serious risk. However, if you designate a forwarded word processor app as "trusted", you are saying that your keystrokes need not be closely guarded. If the app is specified as "untrusted" it is isolated, preventing the sharing of those keystrokes. Of course it's difficult for most apps to function in such isolation.
   Older versions of ssh were found to cause the client xauth vulnerability described in SSH client xauth Vulnerability. When they communicate the (usually MIT-MAGIC-COOKIE-1) cookie for your local XServer to the remote machine, it is placed in the remote machine's authorization cache for use by X11 apps to negotiate connections with your local XServer. Thus, if the remote machine's authorization cache is compromised, so is your XServer.
   To minimize the risk, when ssh connects with the -X option it sends an untrusted cookie to the remote machine so that X11 applications that obtain authorization with this cookie are marked as untrusted and restricted in what they can do. While this is safer, the X11 Security Extension Specification is in its infancy and many apps crash as a result of the limitations. Thus, as you've discovered, the -Y option is often necessary. However, it is less secure and should only be used when necessary!
Gary
~~~~
   I have seen the Great Pretender and he is not what he seems.