I'm having this issue with ssh + x forwarding.

I'm connecting to a server with x forwarding enabled. In my ssh_config, the only lines I have are
ForwardX11 yes
ForwardX11Trusted yes

"xhost" says that access control is enabled and no host is listed
"xauth list" gives

zapotec/unix:0 MIT-MAGIC-COOKIE-1 some_magic_cookie
localhost:0 MIT-MAGIC-COOKIE-1 some_other_magic_cookie

yet, when I try to open an x program on the remote server, say, xclock or a gnuplot plot, I get this error

Xlib: connection to "localhost:13.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: localhost:13.0

If I do a xhost +localhost before connecting to the remote server, everything goes fine and xclock/gnuplot works.

I thought that ssh takes care of all this without the need for host base authentication since it is rather less secure. Is it a wrong MIT-MAGIC-COOKIE being used when trying to locally connect to the X server ? What am I doing wrong ?

How are you opening your connection?

To setup a tunnel you have to do ssh -X <remotehost> from your local host. Once that is done anything you do from the same terminal session will use the tunnel you established without need for xhost authentication.

Also make sure you don't have something in one of your startup files (/etc/profile, /etc/bashrc, $HOME/.profile, $HOME/.basrc etc...) that is explicitly setting DISPLAY variable. The tunnel sets a unique DISPLAY variable that must be used rather than the standard DISPLAY variable. If you are explicitly setting it after login via one of the startup files you're actually replacing the tunnel's variable with something else. The fact that it works when you do the xhost suggests to me you are in fact setting it somewhere (otherwise how would it know what to DISPLAY to use once you ran xhost+?).

thank you for your answer. Unfortunately, I run into the exact same problem since setting "ForwardX11 yes" is the same thing as using "ssh -X user@host", and similarly "ForwardX11Trusted yes" is equivalent to "ssh -Y user@host".

With ForwardX11 yes (or ssh -X), I did check that the remote shell has its environment variable DISPLAY correctly set to localhost:XX.0 (where XX is any available display number) but it doesn't change the previous error I reported.

Something I noticed is that if I delete the remote ~/.Xauthority, ssh is indeed doing its job and creating a new one. Also, errors of the type

AUDIT: Thu May 31 13:44:19 2007: 4483 X: client 10 rejected from local host
Auth name: MIT-MAGIC-COOKIE-1 ID: -1

are accumulating in my local /var/log/Xorg.0.log so I'm still at lost.

Try this.

1 - on your system remove all entries for the remote system from your known_hosts file in .ssh for the user you are connecting as. Search for the hostname and the ip and remove those lines.

2 - on the remote system, remove the .Xauthority file from your home directory. This will be re-created when you connect because of the ForwardX11Trusted.

thanks for the tip but it still doesn't work though. I'm about to inspect slackware's startx & friends scripts to see what is really happening. Normally it should only be a matter of ssh -X, -Y etc. but this time I feel like i'm really missing something here.

"X11Forwarding yes" should be in /etc/ssh/sshd_config on the server machine (and maybe the client?), and to avoid having to use the "-X -Y" flags, "ForwardX11 yes" and "ForwardX11Trusted yes" in /etc/ssh/ssh_config on the client machine. (Putting the last two in ~/.ssh/ssh_config didn't work for me.) Also, since I have xauth in /usr/bin on my client, I put "XAuthLocation /usr/bin/xauth" in both ssh_config and sshd_config on my client.

It's likely that nothing I've just said is relevant to your problem, since before I got things set up right, "echo $DISPLAY" after ssh'ing to the server machine gave emptiness, while now it gives "localhost:10.0", but your symptoms are different.

oook, this morning everything is working fine. I guess they discovered something on the server side (for which I have no access) and fixed it.

Thanks anyway for all your responses, LQ's community is fantastic !