X11 DISPLAY from remote Unix host does not launch.

How are you logging in?

If you use something like

<pre>
ssh -Y yourname@foo.bar.com
</pre>

it should just set up the DISPLAY variable and everything else for you without heroics.

Hi Warren,
The fact that there's a difference between users suggests that the difference in configuration resides in your home directory and thus is almost certainly in your ~/Library/Preferences/com.apple.x11.plist property list. The most obvious culprit would be the nolisten_tcp key. Setting that to true causes the old method to fail but won't affect secure shell window forwarding. Maybe the secure shell forwarding failed for a different reason. Another thread, eh? Anyway, check that property list and value.

Oddly, I believe that nolisten_tcp is set to true by default, which means that the telnet method should fail for a new user. Have you changed that in your skeleton?
--
Gary
~~~~
<Flav> Win 98 Psychic edition: We'll tell you where
you're going tomorrow

Hi Warren,
I didn't think that new users should get empty X11 preference files but since the the nolisten_tcp property is supposed to make the telnet method impossible, I feel confident that nolisten_tcp was the problem.

About the solution to the secure shell problem I'm less sure but my recommendation is to set the DISPLAY variable on the client before using "ssh -Y". I'm not sure why that matters but I think I recall that being a requirement.
--
Gary
~~~~
If loving linux is wrong, I dont wanna be right.
-- Topic for #LinuxGER

FYI, I was having similar issues, and I'm 99% certain it's related to the 10.4.8 update. I installed the update two days ago, and today's the first time I had trouble with my system displaying X11 apps from a remote host. I deleted the plist file you mentioned, relaunched X11, and everything worked properly.

Powerbook G4 15 1.25GHz Mac OS X (10.4.8)

That was exactly what I was looking for. Thanks for the info.

DISPLAY on the client matters because ssh uses its local DISPLAY variable to set up the tunnel to the local X11 server.
If you use the X11 "Applications" menu to start a "Terminal" (i.e., xterm), it will already have its DISPLAY variable set properly, so "ssh -Y" should just work. Unless the user overrides the value of DISPLAY in their remote shell session, which would be typical of someone using "xhost +"...

From what application are you running the "ssh -Y" command? If you are running that from Terminal, instead of the xterm that X11 created, then DISPLAY isn't set locally.

You have two options: 1) In Terminal (assuming "bash" shell), use the command
<pre> DISPLAY=:0 ssh -Y user@hostname</pre>
or 2) run the "ssh -Y" command in an xterm.

hi. i'm having a similar problem. i thought i'd add to this thread rather than create a new one.

i'm using "ssh -X hostname" to connect to the remote host. if i connect from Terminal, $DISPLAY resolves to :0 locally and is not set on the remote host. if i connect from xterm via the x11 menu, $DISPLAY resolves to :0.0 locally and is not set on the remote host.

any ideas?

macbook Mac OS X (10.4.8)

First, if you're on Tiger, you want to use ssh -Y, not ssh -X.

Second, you need to have X11 forwarding enabled on the remote host you're trying to connect to. In sshd_config, set:
X11Forwarding yes
and restart sshd.

First, if you're on Tiger, you want to use ssh -Y,
not ssh -X.

Second, you need to have X11 forwarding enabled on
the remote host you're trying to connect to. In
sshd_config, set:
X11Forwarding yes
and restart sshd.

thanks. that solved my problem.

why doesn't -X work in tiger? isn't it more secure?

Yes, it is more secure. However, not all apps work over ssh -X. The change from 10.3 to 10.4 was an updated openSSH library which included the more secure option. The reason -X worked in 10.3 was that the more secure option wasn't in the openSSH that was included in 10.3.

You can read more about Trusted X11 Forwarding in the openssh man pages:
http://www.openbsd.org/cgi-bin/man.cgi?query=ssh
http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos= 0&manpath=OpenBSD+Current

Of particular interest is how untrusted X11 clients are restricted, as that is why -X doesn't work for certain apps (because you're untrusted). When you use ssh -Y, you're a trusted X11 client, meaning you have more access and aren't restricted.

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.

very helpful. i greatly appreciate you taking the time to clarify that for me.

it seems that the reason -X doesn't work isn't strictly because of tiger but because of more restrictive security semantics being introduced into openssh. meaning, remote gvim would still behave in a broken manner if i had upgraded my openssh implementation on a linux box. is my understanding correct?

macbook Mac OS X (10.4.8)