Assuming we are logged in via "ssh" from WOMBATNET to chinookfe, what are some of the possible problems we can encounter with X11 forwarding ? The first clue, in the following example, is the DISPLAY environment variable.
[chinookfe:/home/chinook/wombat]
$ xterm
xterm Xt error: Can't open display: :0
Trying to execute a simple "xterm" on chinookfe through "ssh" yields the above error message, which shows that the DISPLAY environment variable is not set correctly. We can confirm this as follows:
[chinookfe:/home/chinook/wombat]
$ echo $DISPLAY
:0
The immediate inclination is to manually set the DISPLAY variable on chinookfe using either "export" or "setenv", depending on your shell. This is not correct, in that the proper operation of "ssh" with X forwarding allows us to avoid setting or trying to set the DISPLAY variable manually, and it even bypasses the need to run the "xhost" command for the chinookfe session on your workstation. A correct DISPLAY setting, assuming a simple X forwarding operation between chinookfe and our hypothetical workstation WOMBATNET, would yield a value such as:
[chinookfe:/home/chinook/wombat]
$ echo $DISPLAY
chinookfe:11.0
This varies from what you may have seen in the past, in that often users will place command lines into their login scripts on remote systems that set the DISPLAY variable upon login. Lines like:
setenv DISPLAY myworkstation:0.0
or
export DISPLAY=myworkstation:0.0
should be removed from your dot files (.cshrc, .kshrc, .login, etc.) on NCAR computer systems, as "ssh" will automatically handle forwarding X11 connections for us. This includes setting the DISPLAY environment variable on the remote host, in this case chinookfe.
Assuming we have removed the line(s) setting our DISPLAY variable from our dot files on chinookfe, how do we get "ssh" to do the work for us? Our recommended approach is to use the "-X" option of "ssh" to establish the connection from our hypothetical example workstation WOMBATNET to chinookfe, as follows:
[WOMBATNET:/home/wombat]
$ ssh -X chinookfe.ucar.edu
wombat@chinookfe's password:
After entering our password, we receive the MOTD and are logged into the system.
Last login: Wed Jul 17 10:34:08 2002 from WOMBATNET.net
=======================================================================
chinookfe: IRIX64 6.5.16, SGI Origin2000 (8 cpus, 8 GB's memory)
=======================================================================
THIS SYSTEM IS FOR THE USE OF AUTHORIZED USERS ONLY. INDIVIDUALS USING
THIS COMPUTER SYSTEM WITHOUT AUTHORITY, OR IN EXCESS OF THEIR AUTHORITY,
ARE SUBJECT TO HAVING ALL THEIR ACTIVITIES ON THIS SYSTEM MONITORED AND
RECORDED BY SYSTEM PERSONNEL. IN THE COURSE OF MONITORING INDIVIDUALS
IMPROPERLY USING THIS SYSTEM, OR IN THE COURSE OF SYSTEM MAINTENANCE,
THE ACTIVITIES OF AUTHORIZED USERS MAY ALSO BE MONITORED.
=========================================================================
[chinookfe:/home/chinook/wombat]
$
We should now have the correct DISPLAY variable set:
[chinookfe:/home/chinook/wombat]
$ echo $DISPLAY
chinookfe:10.0
Note that the form of the DISPLAY variable will always be "HOSTNAME:x.y" where "HOSTNAME" is the host we just logged in to, in this case "chinookfe", "x" is a small integer, in this case "10", and "y" is usually "0". What this does, in general terms, is enable X11 forwarding across the established ssh tunnel. The upside is this means we don't have to set DISPLAY through either files or after login, and back on the workstation we don't have to issue a command like "xhost +chinookfe.ucar.edu". In addition, all of the X11 traffic is now encrypted. This effect provides better security than the more traditional techniques, and if your facility has a firewall, this may be the only way, because of the tunneling, to get X11 applications to display back to your workstation from the system at NCAR.
You should now be able to execute a simple X11 application like "xterm" and get the window back at your workstation:
[chinookfe:/home/chinook/wombat]
$ xterm &
If this fails to display the "xterm" window, then we need to employ remedial "ssh" diagnostics to try to determine where the X11 authorization problem may exist. With the OpenSSH client software, we can use the same verbose stream debugging we did in our previous example.
If you have questions about this document, please contact SCD Customer Support. You can also reach us by telephone 24 hours a day, seven days a week at 303-497-1278. Additional contact methods: consult1@ucar.edu and during business hours in NCAR Mesa Lab Suite 39.