Novell to acquire Suse

[Michael ODonnell]

> Well, I have had no problem with this when interacting with other
> flavors of Linux or even FreeBSD.  So I'm certain it is not my
> local system that's the problem.
>
> I'm using ssh to connect remotely like this:
>
> ssh -XCA -l mylogin remote.system.name


OK - so you're instructing the SSH clients (via their
command lines) to do X forwarding, compression and
to allow X authentication traffic to pass.  That's a
good start.  Your ~/.ssh/config files should also
have lines in them like this:

ForwardX11 true

What about on the desktop boxes?  Have you verified
that /etc/ssh/sshd_config and /etc/default on the
desktop boxes don't have any entries in them that
could be causing trouble?  You want entries like
these in your /etc/ssh/sshd_config:

X11Forwarding    yes
X11DisplayOffset 10

...and you want to be sure that those capabilities
aren't being overridden in the /etc/default/ssh files,
which are read by the SSH daemons on startup.


> It is only Debian (3.0) server systems that do not define a DISPLAY
> environment variable on the remote end (ssh normally does this
> automatically when you use the switches I've specified above) and
> so X applications will not display on my local system's X server.


Since a number of us have Debian boxes that allow
remote X connections just fine, I can say with a high
degree of confidence that it's much more likely that
the problem here is simply that your local config
needs tweaking.


> I tried Cole's suggestion of installing xbase-clients but that
> didn't do it.  I had been thinking that perhaps I needed to
> start with a remote environment that already had a valid DISPLAY
> defined because it was a workstation.  Can anyone verify or deny
> this theory?


BTW, the SSH clients and servers emit very useful
debug info when instructed to be verbose - have you
tried that?