Re: X11 Forwarding through an Intermediary

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

I'm posting this in case it helps someone else, and to get help with
the remaining problem.

I didn't get X forwarding through an intermediary to work until 2005. I
wrongly blamed NAT or firewall problems for it not working. It didn't
matter too much because I could always fire up another xterm on the
intermediary machine and from there go to the distant machine. (Or
start a local xterm and hop to the intermediary and thence to the
distant machine.) Neither was very much trouble with ssh-agent taking
care of the pass-phrases.

It turned out that the problem was caused by connecting to the
intermediary with:

ssh +X cmsps@intermediary

I used that because it seemed less restrictive; I planned to switch to
a stricter mode when I had solved the main problem.

Quoted text here. Click to load it

ssh +X cmsps@distant

I could then use the shell but couldn't start another xclient. When I
tried, I got:

distant$ xterm &
[1] 2546
distant$ X connection to distant:10.0 broken (explicit kill or
server shutdown).

on distant, and:

warning: X11 auth data does not match fake data.
warning: X11 auth data does not match fake data.

on intermediary.

Coming back to this problem recently, I found that if the original
invocation was:

ssh +x cmsps@intermediary           # lower case x

it was then possible to start new xclients on distant.

However, the lower case x prevents me copying text freely between
xclients -- even if I allow it in the X SecurityPolicy file on local
and distant. Whenever I copy text from one of distant's xterms into an
xterm from intermediary or local, the source xterm closes and this
message appears in the xterm used to connect to distant:

distant$ xterm:  warning, error event received:
X Error of failed request:  BadAtom (invalid Atom parameter)
Major opcode of failed request:  18 (X_ChangeProperty)
Atom id in failed request:  0x189
Serial number of failed request:  271
Current serial number in output stream:  273

I'd like to understand this completely. I'm using SSH Secure Shell
3.2.5 (non-commercial version) on local and distant. We're using SSH
Secure Shell 3.2.0 (non-commercial version) on intermediary -- I know
it's old but I'm not root.

Intermediary runs Solaris; local and distant run RH Linux. I am root on
local and distant; I plan to install the latest SSH Secure Shell but
expect the problem is really on intermediary.


Site Timeline