The following is generic information that applies for access from here on campus as well as remote access like from home or another work place. Clearly this is not the only way to use X-Windows remotely, but it works, and has the following benefits:

1. The session is encrypted, so there are no clear text passwords or data.
2. The data stream is compressed before transmission, which generally results on better overall performance.
3. If you have a software firewall like Zone Alarm installed on your PC, or you use a hardware firewall such as would be found in a cable/DSL router, this method works without having to establish extra firewall rule sets.

The reason for this is that since the X-session is tunneled within the ssh session, the X-requests going to the X-server on your PC appear to be coming from another application on your PC (the ssh client, which manages the tunneled session), NOT from the remote computer. Because of this, no other special accesses or permissions need to be identified to either the firewall or to the X-server. Often this is done within an xhost authentication facility and with this approach it is not needed since most firewalls and X-servers grant access by default to the local system on your PC).

There are basically two pieces to making this work successfully in our environment. The first piece comprises using a secure shell (SSH) client, which manages authentication over an encrypted session link and provides a compressed data tunnel for the X-windows traffic. Examples of secure shell clients include no-cost tools like Mindterm or Putty, or commercial tools like SecureCRT.

The second piece is the X-windows server such as Xming, which is used to display on your local system the information from the remote client.

The two-piece approach maintains security for your system but also allows you to work with remote applications that use a graphical interface. If you are working from a PC and have ZoneAlarm installed or are behind a hardware firewall, tunneling the X data stream within SSH is far easier than trying to configure for it.

Some choices for an SSH program can be found at: http://www.openssh.org/

Please note, as of May 1, 2009 the College of Engineering no longer offers a licence for Xwin32 but the free Xming package is highly recommended. Xming has has proved an effective alternative to Xwin32 in our instructional computing laboratories. You can get it here: http://www.straightrunning.com/XmingNotes/

If you use an SSH program to establish the connection, make sure that your SSH client has "Forward X-11 packets" enabled within its configuration. Most, if not all, have that disabled by default. Log in on your ECI or CS system and issue the following commands:

csh
printenv | grep DISPLAY

you should see a reference to display 10.0 or higher on the local system (but NOT zero). That's OK. On the UCSB or CS system side, that display number corresponds to the X redirect that the SSH server has set up. If you don't have DISPLAY showing properly, then the X-11 packet forwarding is not enabled within your SSH program and you need to configure it to be enabled on your end before proceeding any further.

To test the X-connection, make sure Xming is started (gray X appears in the System Tray), then issue a command like xclock in the ssh terminal window. If a graphical clock appears on your PC display, then all is working OK and you can close the clock and then start an xterm or go straight into your application program in the ssh window. If you get an error, either in the ssh window or a popup message on your PC screen, send an email to help@engineering detailing the command(s) you provided and the exact error(s) that you received. Also verify in you email that you have performed the test described above.