Some graphics don't get drawn when forwarding X11 over ssh (secure shell)

The ssh (secure shell) program establishes an encrypted connection between hosts, and establishes an interactive shell session much like the classic
rsh or rlogin programs. In addition, it can forward other TCP/IP traffic
between the connected hosts. In particular, it can easily forward X11
protocal requests, making it appear that the local display actually belongs
to the remote machine. For example, a session might look something like:

A> ssh B
Welcome to host B...
B> echo $DISPLAY
B:10.0
B> xterm
(xterm pops up on A:0.0 -- B:10.0 is forwarded to A:0.0)

Suppose boths hosts may live behind firewalls that only allow ssh traffic.
Setting DISPLAY on B to A:0.0 would not work since X11 would attempt to
establish a direct connection to A, which would be blocked by the firewall.
Thus, in many security-concious environments, all X11 traffic is transported
over ssh connections.

When a JFC application is run, the main window appears but large portions
of its contents are not drawn at all. Dragging other windows on top of the
window to attempt to force a refresh does not work. Running the same
program using a normal DISPLAY setting works fine. The SwingSet2 demo
from JDK1.3 is a good test case as very little ends up being drawn.

One possibility is that Java2D is arriving at the incorrect conclusion
that the display B:10.0 is local to host B, and attempting to draw without
issuing X commands. If this is the case, some additional tests must be done
to determine if the display is truly local.

Once this problem is resolved, an ssh test case should be incorporated into
the AWT/Java2D test suites.

The problem was pointed out by Scott Schwartz at Penn State, who has been
unable to work around the problem.

--------------------------
daniel.rice@Eng 2000-09-27

An additional note from Scott:

Here's some more information, which might be useful.

In one xterm:
A% ssh B

In another:
A% ssh C
C% setenv DISPLAY B:9
C% java ...

In other words, get machine C to display via plain tcp to B, and from
there via the ssh tunnel to A. The idea is to make sure that C doesn't
think the X server is local, while still going through an ssh tunnel.
And it works. This suggests that ssh itself isn't buggy with respect
to X11 tunneling, but that java is buggy as it wrongly thinks that
the display is local.