| Summary: | openssh-3.8_p1 does not forward x11 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tim Burrell <tim> |
| Component: | [OLD] Core system | Assignee: | Daniel Ahlberg (RETIRED) <aliz> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aoyu93, axel.privat |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Tim Burrell
2004-04-27 07:25:16 UTC
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. *** . |
