I run x2x between two machines ("omnia" and "nihil"), controlling omnia's X display with nihil's keyboard and mouse. The "standard" way to do this is by using "xhost" to allow nihil access to omnia's X display, and then to run: omnia:~$ x2x -from nihil:0 -east I don't like this, as it's a little insecure (i.e. "xhost sucks"). I prefer to use X forwarding: omnia:~$ ssh -X nihil "x2x -from :0 -east" This has worked wonderfully up until now. I recently upgraded openssh on both machines from version 3.7.1_p2-r2 to version 3.8_p1. I updated my config files, and, in due course, restarted my ssh daemons. The next time I tried to start my x2x, I got the error: omnia:~$ ssh -X nihil "x2x -from :0 -east" x2x - error: display localhost:12.0 does not support the test extension This is, frankly, a load of tripe: $ grep TEST /var/log/XFree86.0.log (II) Initializing built-in extension XTEST I did not immediately track the problem down to my ssh daemon. I asked Google some stuff, but all I could come up with was: http://www.bsddiary.net/d/200211.html. If any of you know what he is on about, I'd love to know. The long and the short of it was that I downgraded my openssh, back to 3.7.1_p2-r2, and x2x works perfectly again. Even with 3.8_p1, all other X forwarding seems fine. I can run an xterm on one machine, using the other machine's display, and so on. It's just this one weird error. I'm not sure if I should report this bug upstream or not, so I thought I'd try here first.
Something else that I've just realised it broke: When I leave my machine, I use 'xtrlock' to lock it. I have set up my shortcut keys to run "xtrlock" when I press Super-L. It behaves oddly, though, I have to press Super-L about seventeen times before it actually runs xtrlock. But I digress. I changed the shortcut to run "ssh -X localhost xtrlock" (i.e. run xtrlock with X forwarding, should be identical), and this works perfectly, strangely enough. But when I upgraded openssh, it stopped working again, presumably for the same reason x2x broke. xtrlock fiddles with your keyboard (locking it, yeah?), so is fairly similar in certain respects to x2x. And they were the only things that seemed to break. Ja.
The releasenotes has this entry, could you try the ForwardX11Trusted thingie? * ssh(1) now uses untrusted cookies for X11-Forwarding. Some X11 applications might need full access to the X11 server, see ForwardX11Trusted in ssh(1) and xauth(1) for more information.
Status?
adding '-Y' to the ssh command fixes this
Sorry for the delay - work got the better of me. You were dead right, I needed trusted forwarding. It might be nice to have the option in ssh_config, but I see that we use openssh's default configs, so maybe a dosed, or else forget it?
Daniel Ahlberg is right that this is because of the X11ForwardTrusted not being defaulted to yes. I had the same problem and just found out what the problem was and X11Forwardtrusted fixed it. Debian enables this by default, so Gentoo should consider doing the same IMHO.
