folks, read ALL of the OP's post before suggesting a solution :)

he already has ForwardX11 set in his config file, so passing -X to ssh shouldn't make a difference.

Cristofer: the "ForwardX11 yes" in /etc/ssh/ssh_config needs to be set on the CLIENT machine, not the CentOS 4 server. if that client machine isn't running linux or some unix, you'll need to set this up a different way, and we'll need to know more about how you're establishing the ssh connection.

i assume "server" is the second machine, the CentOS 4 box that isn't running X. is the first machine (the one that does have an X server) also running linux or some other unix, or is it a Windows machine?

On Apr 5, 2005, at 10:27 PM, Cristofer N. Reyes A. wrote:

[root@server ~]# echo $DISPLAY

here's the troubleshooting you need to do:

1. start on the first server. if it's a unix machine, `echo $DISPLAY` should return ":0.0", or perhaps "localhost:0.0". if it returns nothing, there's your first problem - you need to set it to ":0.0" before you ssh.

2. ssh root@server

3. `echo $DISPLAY` should now return something like "localhost:10.0". the high number before the "." means that you are successfully tunnelling X through the ssh connection.

here's what the whole process looks like ("oh" is a MacOS X box with XFree86, "iberia" is a CentOS 4 machine, the ssh config files are set up similarly to the way yours are):

--- begin paste ---

oh:~ shuff$ echo $DISPLAY :0.0 oh:~ shuff$ ssh iberia Last login: Wed Apr 6 10:27:33 2005 from oh -bash-3.00$ echo $DISPLAY localhost:12.0 -bash-3.00$

--- end paste ---

[root@server ~]# mysql-administrator

(mysql-administrator-bin:24261): Gtk-WARNING **: cannot open display: [root@server ~]# echo $DISPLAY

[root@server ~]#

What must have?

-steve

--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v

donavan nelson said:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Cristofer N. Reyes A. wrote: | Hi all! | | I've a server with Centos 4.0 without X server, but I need use | mysql-administrator from other pc with X server. In the moment to export X from | the server this message show me: | [root@server]# mysql-administrator | | (mysql-administrator-bin:19124): Gtk-WARNING **: cannot open display: | | The /etc/ssh/sshd_config have X11Forwarding yes | and the /etc/ssh/ssh_config have | Host * | GSSAPIAuthentication yes | ForwardX11 yes> | | What's the problem?

Read up on the new secret (poorly documented) ForwardX11Trusted options.

I wouldn't call something in the FAQ poorly documented.

http://openssh.org/faq.html#3.13

| What's the problem?

...

...

Read up on the new secret (poorly documented) ForwardX11Trusted options.

I wouldn't call something in the FAQ poorly documented.

http://openssh.org/faq.html#3.13

I think he meant poorly documented by RH ... there are a zillion bugs posted concerning this ... here is the fc3 one where they say they will fix it:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137685

They seem to be going to fix this in a future RHBA for RHEL4 as well (probably in Update1):

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150262

Johnny Hughes

yes, by RH/Fedora.

Les Mikesell said:

On Wed, 2005-04-06 at 07:12, William Hooper wrote:

...

...

Read up on the new secret (poorly documented) ForwardX11Trusted options.

I wouldn't call something in the FAQ poorly documented.

http://openssh.org/faq.html#3.13

There are probably at least a dozen people somewhere that might understand that paragraph, but I'm not one of them. What's the difference between a trusted and untrusted cookie, and why do I need to care now? (I think this relates to when -X works from the client and when -Y is necessary, but maybe not...).

As "man ssh_config" states "See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients." This is really an option that SSH passes to xauth.

Basically, untrusted X11 clients can't interact with trusted X11 clients. This prevents your X session from being sniffed if the remote file permissions aren't correct (or you don't trust the sysadmin).

While it sounds good in theory, in the real word it breaks just about every X app. The luck apps refuse to start, the unlucky ones crash in the middle of execution.

Les Mikesell said:

On Wed, 2005-04-06 at 15:48, William Hooper wrote:

...

...

...

http://openssh.org/faq.html#3.13

There are probably at least a dozen people somewhere that might understand that paragraph, but I'm not one of them. What's the difference between a trusted and untrusted cookie, and why do I need to care now? (I think this relates to when -X works from the client and when -Y is necessary, but maybe not...).

As "man ssh_config" states "See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients." This is really an option that SSH passes to xauth.

Thanks, but you still lost me at 'untrusted'. What makes a client trusted or not?

As it pertains to SSH, 'untrusted' is anything you forward with "ForwardX11Trusted no".

If it's left up to me to decide, why would I run an untrusted one at all?

You don't trust the admin of the server you are SSHing into.

Agree... connect with : ssh -X user@machine The -X ensures X11Forwarding is in place.... this has recently changed in openssh.