Friday 28 May 2010

Ssh: command lines at at work

Much grid software is written by and for people who do not fear the command line.

The approach is... you log in, you type something, you wait for it to finish, you type something else.

It is a long way from the icons, shiny buttons and general point-and-click-iness that people expect from modern computing.

It can also be very productive. Which is why people who aren't 40-somethings with memories of the golden age of computing can use it too.

The NGS's Resource Broker is one such example of Old School computing.

For many users, it isn't typing the commands that causes grief, it is logging on to a remote machine.

The de-facto standard for remote logins is SSH or secure shell. There are many SSH clients available - including one from ssh.com which is free for non-commercial use and the popular and free puTTY.

Unfortunately none of these clients speak grid.  For this you need a client that understands where to find - and what to do with - a certificate so it can be made available to the other side of the connection.

Globus and gLite provide  gsissh - a certificate aware SSH client and server. Linux users can pick this up as a package from the Virtual Data Toolkit, or the Globus packages in EPEL or - if you are so inclined - build it from the source used within the Globus project.

Which is all very well, up to a point. The point being that the NGS is here to support all academic researchers - not just the minority running Linux. In a poll running on the NGS web site,  35% of our users said they used Windows - compared with 43% who used Linux, 19% Mac and 2% who used a mysterious `something else'. 

Some Windows users have adopted GSI-SSHTerm - a Java application distributed and maintained by the NGS.

GSI-SSHTerm is very flexible. It can collect certificates from local disk, or from a MyProxy service.  Its popularity is due, in part, to its ability to use the copy of the certificate kept within certain web browsers - such as Firefox 2.x. Unfortunately, this trick required direct access to the browser's internal data and changes to this format means that GSI-SSHTerm cannot extract the certificate from newer versions of Firefox.

But not everyone can persuade GSI-SSHTerm to work. Obviously you need a working copy of Java and even then it can fail if the 'Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy' files are missing. These are available from the Java download page but distributed separately for legal reasons.

Many users are familiar with other SSH clients and would prefer them to GSI-SSHTerm if only they had the added gridiness. These lucky users have a choice...

Oxford e-Research Centre have created a modified version of puTTY with certificate support for the CCP4: Software for Macromolecular X-Ray Crystallography project. It is currently under test.

STFC have an alternative approach. They created the MyProxy Enabled GSI-SSH service, or MEG. This is a PAM plugin that allows an unmodified SSH client to communicate with a standard Linux SSH server - of the kind that accepts usernames and passwords - that is installed along side a grid-enabled one.

The usernames and passwords that MEG accepts are not those of local accounts. They represent  accounts on a MyProxy server. A user can upload a certificate to a MyProxy server using something like the Certificate Wizard. This will be downloaded when he or she logs on via MEG.

MEG has been deployed on the NGS resource broker and the code can be downloaded from the NGS NeSCForge pages.

So give the mouse a rest. Turn on, log in, and program like it's 1989...

2 comments:

richard said...

Do you know which versions of firefox are not supposed to work with GSI-SSHTerm? I'm currently on version 3.6.3 on windows and Mac and it seems OK

Jason Lander said...

Sorry if I was unclear.

GSI-SSH term will run from any recent version of firefox with Java 1.5 or higher.

Users have found that the tool cannot read certificates from within the browers' own certificate store for Firefox 3.x and above. These have typically been Windows and Linux users rather than Mac users.

It will work perfectly well with certificates read from a local file or downloaded from a Myproxy server.