X11 forwarding via SSH

[Mihails Nikitins]

Hi,

I'm trying to enable X11 forwaring with HP Secure Shell. My X server is Windows workstation with SecureCRT and X-Win32.

The only application sending graphics via encrypted channel is xlock. The others (I tried sam, xterm, xomni) fails with the following error message:

Xlib: connection to "localhost:10.0" refused by server
Xlib: SSH gateway: X11 authentication failed.
Error: Can't open display: localhost:10.0
Error: Couldn't find per display information

I tried many variants of X-Win32 parameters with no result. xlcock is working in all cases. I included 127.0.0.1 in X-host list on X server side.

Thanks in advance for any hints!

BR,
Mihail

[Tom Maloy]

Where is that :10.0 coming from?

It is usually :0.0

[Jordan Bean]

Tom,

Screen :10.0 is the typical offset for OpenSSH and the HP derivative.

Mihail,

Xauth strikes again. If you are accessing root via sudo or su, then you will need to ensure that HOME and/or XAUTHORITY do not change in the transition. If XAUTHORITY is not set, it will default to $HOME/.Xauthority... and the one you want is in your home directory.

[OneNeck UNIXSA]

Try setting DISPLAY=:0.0
and then run application.

[Wodisch_1]

Hi Mihails,

lets start with the simple things first:
did you modify the "ssh_config" on your system and the "sshd_config" on the remote system? One parameter locally, two on the remote side (Get the whole explanation there:
http://www.openssh.org/faq.html#2.7
this does work with HP's ssh, too).
Then you'll need to execute "xauth" to add the "MAGIC-COOKIE" to your session.
But "xclock" is the only of your examples, which does not need FONTS - maybe your problem is hidden there?
Try "xlsfonts" on the remote system's Xserver and then via "ssh" - is the output different?

Just my $0.02,
Wodisch

[Mihails Nikitins]

Hi,

Thanks to Jordan's reply I managed to start encrypted sam. After 'su' to root, $HOME is not defined, command like
export HOME="/home/user"
really helps!

Unfortunately, I do not close the case because xterm and xomni are still not working. I guess they do not know about environment variables.

# xomni
Starting GUI...
Please wait, this may take some time...
Xlib: connection to "localhost:10.0" refused by server
Xlib: SSH gateway: X11 authentication failed.
Wind/U X-toolkit Error: wuDisplay: Can't open display


# xterm
Xlib: connection to "localhost:10.0" refused by server
Xlib: SSH gateway: X11 authentication failed.
Error: Can't open display: localhost:10.0
Error: Couldn't find per display information

Please note that errors are not the same for the two processes. My goal is to force Omniback GUI to run via encrypted channel. The other processes are just tests.

To Wodisch.

Remote X server is X-Win32 under Windows 2000, so I cannot not use UNIX troubleshooting techniques you recommend.
sshd_config on X client side has parameter 'X11Forwarding yes' enabled.
The file .Xauthority is being changed every time I log in via ssh. So xauth mechanism itself seems to be working.

Thanks in advance for more ideas!

BR,
Mihail

[Wodisch_1]

Hi Mihails,

just the day before I tested that with HP's OpenSSH on the HP-UX side, and "CygWin" OpenSSH and Reflection/X on the PC side with a file "$HOME/.ssh/config" like this:
# ssh client config file
ForwardX11 yes
ForwardAgent yes
Protocol 2
# end

and it did work...
So I guess your problem is somewhere with SecureCRT...

Sorry,
Wodisch
PS: could you try cygwin? dll+exe attached...

[Rick Beldin · Accepted solution]

X11R5 clients will have problems with SSH because of the built-in way that X111R5's XOpenDisplay() tries to be 'smart' about the transport. Depending on the format of the DISPLAY variable, XOpenDisplay() will try different methods of creating the socket connections. The form of localhost:n will force it to use Unix sockets, which ssh is not listening to. There is a somewhat vague note in the ssh release notes about this. X11R6 clients do not have this limitation.

To correct this, modify the sshd_config on the HP-UX side to have the following entry:

X11UseLocalhost no

This will force the remote DISPLAY name to be of the form
ip-address:10. XOpenDisplay() from R5 thinks that this refers to a remote connection and xterm, xclock and other R5 clients will then start to work.

I've had the following connections successfully working:

HP-UX <-> HP-UX
Linux <-> HP-UX
HP-UX <-> Windows NT w/ Putty

[Mihails Nikitins]

YES!!! Thank you, Rick.

Now my DISPLAY variable looks like
A.B.C.D:10
where A.B.C.D is the system's real address.

sshd manual tells that setting
DISPLAY to localhost:10 is more secure (X11UseLocalhost yes), but I hope that 'fake display' is not very serious security issue. I guess it's extremely hard to receive A.B.C.D stream to another machine.

To Wodisch: Sorry, I did not test your software. BTW, you archive seems to be corrupted.

BR,
Mihails