after emerging openssh-3.8_p1 x11 packets no longer get forwarded. the $DISPLAY is set correctly but any request to open an X11 window causes the Bad X11 Atom error message. to fix the problem, downgrading to the latest 3.7 immediately works. Reproducible: Always Steps to Reproduce: 1. emerge -u openssh 2. ssh <remotehost> 3. launch remote x app & 4. watch error code Actual Results: error produced. Expected Results: no error produced.
It could be an update to the configuration files, make sure you run etc-update since http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Bad+X11+Atom%22+openssh&btnG=Google+Search returns no results, I'm guessing that isn't the exact error message, perhaps posting the exact error could help also, check if this works with openssh-3.8.1_p1 (its ~arch), cause if it does then its a problem thats already been fixed
I'm getting the same thing with ~x86's openssh-3.8.1_p1. I ssh over with x11 enabled, the display is set right, but when I start, say gvim: The program 'gvim' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAtom (invalid Atom parameter)'. (Details: serial 135 error_code 5 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
A google did come up with this: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Looks like the -X changed to -Y in 3.8. Tried it, works great.
Well, what I said was not entirely true. But adding the -Y did fix my problem. (Sorry, way to much coffee today) From the man page for ssh_config: ForwardX11Trusted If the this option is set to ``yes'' then remote X11 clients will have full access to the original X11 display. If this option is set to ``no'' then remote X11 clients will be considered untrusted and pre-vented from stealing or tampering with data belonging to trusted X11 clients. The default is ``no''. See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.
$ ssh <host> gkrellm2 Xlib: extension "RENDER" missing on display "localhost:12.0". The program 'gkrellm2' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 2556 error_code 3 request_code 38 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) net-misc/openssh-3.7.1_p2-r2 works fine
What's more: some "simple" X apps (e.g. xterm, xcalc etc) do start when ForwardX11Trusted is disabled, but after ~ 5 min since ssh login even these stop working due to an xauth error like AUDIT: Sun May 2 17:04:07 2004: 6814 X: client 18 rejected from local host Auth name: MIT-MAGIC-COOKIE-1 ID: -1 (this is from /var/log/Xorg.0.log). This timeout "feature" seems to me a clear bug.
WRT to the "RENDER" missing on localhost:10:0 this requires a new option as of openssh 3.8. The option is -Y, as in: ssh -X -Y -C -c blowfish -l mark marksmusic.myvnc.com This apparently allows 'Trusted X11 Forwarding' which is now required to get the RENDER attribute info back to the remote end.
*** Bug 61018 has been marked as a duplicate of this bug. ***
.
