Machine: Sun Ultra SPARC III
O/S: Solaris 9

When SSH'ing into Solaris 9 I am able to run most gui apps.
However, some of the really important apps we need to run from client workstations require the DISPLAY var be set.

sshd_config is using the defaults.

I've tried:

Hostname:0.0
Hostname:1.0
localhost:1.0

and various other combinations of the hostname and localhost with various screen settings.

Any suggestions?

Thanks!

John

This is confusing. If you run GUI applications, you DISPLAY variable is already set.

At the very least, you'll need X11Forwarding set to yes in your sshd_config. Also, you need to either set ForwardX11 to yes in your ssh_config or use the corresponding switch when running ssh (typically -X).

That ought to set your DISPLAY automatically.

What they said. You shouldn't have to be messing around with setting the display. If you make the ssh connection with the option to tunnel X11 back, and you have the configuration on the Solaris side set to permit this, then, when you launch an app, it should just send the display back to you.

However, you have to have your client side set up appropriately as well. For example, if I am doing it from Mac OS X, I cannot do it from the terminal application. It doesn't support it. I have to launch X11, open an xterm window, and make the ssh connection from xterm.

Similarly, in Windows, you have to have an X11 environment from which to make the ssh connection. A commercial example is Hummingbird.

From Linux it ought to be more natural, but I haven't done it, so I can't tell you exactly.

Anyway, your ssh command has to be `ssh -X servername` to set up the tunneling.

On the Solaris 9 server, you have to find the line in /etc/ssh/sshd-config that has X11Forwarding and make sure it is uncommented and =yes. Remember to HUP sshd so that it picks up the change.

And, finally, there was a bug in sshd on Solaris 9 that caused it to core dump if you connected with a request to do X11Forwarding. If you are totally up on recommended patches, that won't happen. If it does, you won't be able to connect, and you will find the core dump error in the /var/adm/messages log. Then you will have to go get the appropriate patch. If that is the case, and you can't find it, post again and I will search my records for it.

hmm. Looking back at your post, you say that most gui apps work. This would imply you have everything set up right, but that you have some apps that are abnormal and don't really follow the rules.

You wouldn't be talking about the Oracle installation and admin gui would you? I'm recalling that that was a pain in the butt. One would think it should be 0.0, but did you try just plain 0? It's altogether possible that the way Oracle has done it messes up the forwarding.

further hmm. http://orafaq.com/wiki/Setting_up_X_forwarding_over_SSH

yeah, I know, you never said Oracle was the one that was causing you trouble. But it's a good example of weirdness and doing things differently.

Maybe this will help clear up some confusion.

When I issue: echo $DISPLAY
it returns nothing, indicating the DISPLAY var is not set.

All I can figure is that some apps are explicitly attempting to read the DISPLAY var and since it's not found, they issue a warning and abort. Other apps, just run and their GUI interface pops right up.

FYI, the app is not Oracle. The app is the latest Synopsys installer. The old installer never had this problem, but to install the latest Synopsys packages I have to run the latest installer. Further digging revealed that installer is actually a C shell script and that's where the DISPLAY var is being checked and that's where the DISPLAY warning message is hard-coded.

I took a look at that link you pasted above and that info is about a UNIX SSH client. In my scenario, Solaris 9 is the SSH Server and a Windows XP machine running PuTTY and Xming is the SSH client.

Speaking of weirdness, I have narrowed down the problem. Just for the heck of it I tried to run the installer as a regular user. Lo and behold, it ran and up came the GUI.

However, no matter what I do to the login config (.profile) of the superuser (su -), I can not get the GUI app to display for me as superuser. I added DISPLAY= and export DISPLAY to the .profile in the machine's root directory (/). Now I don't get the DISPLAY var is not set error message, but depending on the value I assign to DISPLAY, the installer either runs and hangs, or it aborts right away with no error/warning messages.

I've done everything short of modifying sshd_config to allow for root logins. I have a hunch that if I were to login in directly as root, the installer would run and the GUI would come up. Of course, I don't want to open up the ssh server to root logins.

Conclusion: The installer script works, because it's able to bring up the installer GUI correctly for the user that logged in via the SSH connection. ONLY users on a secondary login via the su command:

su - # regular superuser
su - root # explicitly logging in as root via su
.
.
.
etc.

are having the problem!

Suggestions?

JohnE

Just to clarify one thing. You are working on a Unix system. It is only the initial ssh command that is occurring on your Windows machine. So the items in the link I posted earlier were relevant from that perspective.

When you say that `echo $DISPLAY` returns nothing, is that as the user you logged in as? Or is that as the root user after you su? Ah, you later say it fails only after su.

For whatever it's worth, I just did `ssh -X marlin` on my network. Then I did `/usr/ucb/printenv` and among the environment variables printed out was "DISPLAY=marlin:10.0". Then, when I did `su -` followed by `/usr/ucb/printenv`, I did not get DISPLAY.

So, as root after the su, I did the following:

# DISPLAY=marlin:10.0
# export DISPLAY
# /usr/openwin/bin/xclock

What I got was an error:

X11 connection rejected because of wrong authentication.
X connection to marlin:10.0 broken (explicit kill or server shutdown).

So, given this situation, I think your next best bet might be to try sudo. If you can get the application to run with sudo, then *maybe* it will send back the display. Otherwise, you may just have to open up X11 between the two machines and forget about trying to do X11 forwarding through ssh. You might be able to find some other way of securing or restricting X11.

Wow. The power of the right idea and keyword in google.

I just googled "x11forwarding ssh after su", AND, the very top link was this:

http://www.debian-administration.org/articles/494

which explains about a "magic cookie" that carries the authentication information. Display that before `su -` so that you know what it is, then set it after `su -` and X11Forwarding "magically works." I didn't have to patience to try it, because xterm won't copy/paste for me, the delete key doesn't work when I make a typo, and the magic cookie is a huge long mess of random stuff. I almost never use xterm, so . . .

Anyway, there were other links as well that looked good. I did get as far as `/usr/openwin/bin/xauth list $DISPLAY` and it looked just like the link described.

Thanks, choogendyk! You pointed me in the right direction. xauth was not found when I tried to run it, so I read quite aways down that Debian thread till I came across a real simple, yet effective solution.



Here are the instructions I followed below. The only thing extra I did was to make a backup of /.Xauthority before modifying it.

##### COPIED FROM DEBIAN LIST #####

ssh ip -X -l snot
echo $DISPLAY
copy the output
su -
cat /home/snot/.Xauthority >.Xauthority
export DISPLAY="paste the output of echo $DISPLAY here... without quotes"

##### END OF INSTRUCTIONS #####

This worked for me!!

Addendum: DISPLAY var settings
------------------------------
By default, Solaris sshd_config sets the X11DisplayOffset to 10
echo $DISPLAY of main login returned HOSTNAME:11.0

You rock, choogendyk--thanks for your help!!

John