unable to $DISPLAY from HP-UX to RedHat4

[Jean-Yves Picard]

Hello,

short story:
how do I display any hp-ux X-window program on RH4 ?

long story:
I have almost only HP-UX server.

I have 3 clients :
PC running W2K and reflexion X,
PC running RedHat 3,
PC running Redhat 4.

I can launch any X-window base graphics (like xclock, xload, gpm or ignite) on the two former client.

unfortunatly I cannot run any when connected from rh4 client.

however I can run x-windows graphics from linux to rh4 client

how do I get x-windows setting on rh4 ?

I connect to HP-UX either with ssh or telnet
I connect to Linux using ssh of course
on linuxes DISPLAY is set to localhost:xx.0 (whith a proper xx value like 10, 11 ...)
on hp-ux DISPLAY is set to 11.22.33.44:0.0

when i run xclock on HP-UX there is no error message.

(I hope this this clear)

Jean-Yves

[Alpha977]

I'm searching the same solution!

I want to see the HP-UX desktop on my fedora.

Thanks!

[Steven E. Protter]

Shalom,

From Linux to hp-ux and back and forth.

Try ssh -X hostname programname

That will work and the data stream is encrypted.

SEP

[Matti_Kurkela]

In about all modern Linux distributions, the possibility to open unencrypted X Window System connections has been disabled by default.

This is a good thing, because it protects the newbies from accidental security breaches. It also "encourages" those familiar with the old methods to try out the new way of handling X11 connections - i.e. "ssh -X". It is much simpler than the old method: there is no need to manually set DISPLAY *and* no need to use xauth or xhost.

But if you really want to use the old insecure method, enabling it is fairly simple.

First, you must know which X display manager program you're using. The standard way of naming an X display manager is "*dm". "xdm" is the traditional one, but RedHat4 seems to use "gdm" by default.

Look into the configuration directory of your X display manager: according to the display manager you're using, it would be either /etc/X11/xdm or /etc/X11/gdm. There should be a file named "Xservers" in that directory.

The "Xservers" file defines how the X server process(es) is/are started. By default, there is an option that limits the X server from listening for TCP connections, effectively limiting the X server to local (and SSH-transferred remote) connections only.

To enable the old method of running X applications to work, you just need to remove this option and restart your X display manager process.

There is no GUI for this setting. This is intentional.

I must stress that I recommend you *don't* do this unless it's absolutely necessary and you've ensured your network is secure.

When using the old methods (especially "xhost +") it is trivially easy to remotely monitor all keystrokes and mouse actions. *NEVER* enable the old methods on a host that is connected to the Internet without a firewall!

[Jean-Yves Picard]

Hello,

thank for -X option, I was alread using it.

I'd rather use DISPLAY set to localhost:xx rather than DISPLAY set hostname:xx, unfortunatly layers upon layers of login shell ( /etc/profile and all ) , some comming from dark age before Y2K force me to set DISPLAY to hostname:xx rather than localhost:xx.

However I was able to turn them off on a test hosts.
here is the result:
(a part from sshd_config on hp-ux)
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
#PrintMotd yes

linux-rh4> ssh -l root -X hp-ux
hp-ux: root> echo $DISPLAY
localhost:11.0
hp-ux: root> xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:11.0 broken (explicit kill or server shutdown)

I hops this help ...

[Mike Stroyan]

The "wrong authentication" error indicates that the xauth mechanism is not working. When you ssh to the HP-UX system it should add an entry to your $HOME/.Xauthority file on the HP-UX side. You can see what entries are in there by running "xauth list". I would expect to see a line in that output for hpux/unix:11. That would correspond to DISPLAY localhost:11 and would be the authentication cookie provided to the X server when an X11 client connects.

It is common to loose access to ~/.Xauthority when using su to change user id. It might also be affected by some .login script that actually sets XAUTHORITY in the environment.

[George Liu_4]

If you are using ssh, you'd better follow the rule. NOT export DISPLAY parameter.