XClose

Advanced Research Computing

Home
Menu

Power to the People - James Legg

As a newcomer to HPC, James Legg demystifies the command line and shares his tips for setting up Windows so you can work with remote systems like UCL’s Kathleen and Myriad clusters

Bank of computer monitors showing lines of code with empty computer chair; photo by Kevin Horvat on Unsplash

4 November 2020

You have finally got your account to use a cluster, but where to start? How do you even connect? Do you have to ask your mum to buy you a Mac Book? The answer to that is fortunately no. High Performance Computing (HPC) facilities are becoming more and more available to students and researchers from all disciplines, so in these posts I shall be looking at how to get connected in HPC using an ordinary Windows computer; i.e., the tool that most people already have and are familiar with.

HPC facilities generally expect users to work with the same basic, user-unfriendly, text-based command line interface (CLI). So, any personal computer that can provide you with a “terminal” window for typing the commands and that supports the ssh (Secure shell) program for sending those commands to the cluster will be up to the task. You are not going to be able to avoid this CLI interface entirely, but you will be able to augment it with some tools that provide a more familiar graphical interface, as is the norm for software used today on personal computers.

Back in the 1960s computer operators (like my mum was then – I am a mature student) prepared punch cards for input of data and programs. By the 70s the user experience had moved on a bit: there were terminals comprising a keyboard and a visual display unit (VDU) such as the VT100

 

DEC VT100 terminal at the Living Computer Museum (apparently connected to the museum's DEC PDP-11/70). Jason Scott, CC BY 2.0

Through the 80s and into the 90s the microcomputer revolution was taking place.  User interfaces changed to a graphical user interface (GUI) with multiple windows and buttons to click so you could do things without having to commit the CLI command syntax to memory. Next came the Internet and we could connect to large computers all around the world – what was the terminal had now become the web browser and the email client.

By the 2000s large computers had become clusters of relatively cheap microcomputers but these were not given the same graphical user interfaces as all those brilliant microcomputers. In fact, the terminal emulator program was invented so that we could use our personal computers just like a 1970s actual terminal and so now you get your VDU simulated in the  “terminal” window on your screen and your keyboard is, well, still your keyboard. Why did that happen and why do we still have it?

Modern clusters, like their predecessors, are batch systems – you ask the system to run your computation job by putting that request in a queue and the system runs the job when it determines it is efficient to do so taking into account all the other jobs it has to do; that way the expensive computer is kept busy. A batch job does not interact with its user at the screen – all the inputs and outputs are kept in files. So, a simple CLI for making the queuing requests and moving files about is all that is needed, it is said. Anything fancier would be a cost in hardware and in system administration, so better to spend the money on the compute and storage.

From the new user’s point of view, however, it does feel like a bit of a let-down, so 1970s. The 1970s were grim. I log in and stare at the bare command prompt: am I supposed to type: “go north” and “use amulet”? Mum might know. Just some indication of all that power and activity going on inside would lift it a bit. Even my lowly Raspberry Pi has a live CPU usage meter and temperature gauge. Of course, what we could really do with is a remote desktop so we can use our favourite GUI tools like a file manager, web browser, IDE and so on. It would help productivity for the general user. 

The SSH command in Windows

However, none of that is going to happen any time soon, so it’s time now for a terminal tip for Windows users. To connect to remote system from a Mac or a Linux laptop you can open a simple terminal window and type your ssh command. Windows users have mostly used fancier terminal programs like Putty and MobaXterm for the purpose, so what I am going to suggest may sound like a step backwards, but bear with me.

Windows 10 has, in fact, had the ssh command available as standard since 2018. So, you can open a simple terminal program, the Windows Command Prompt (or a PowerShell window), and type your ssh command. For example, the UCL research computing documentation site tells us the SSH command you’d use to log in to Kathleen:

ssh uccaxxx@kathleen.rc.ucl.ac.uk

This command can be simplified by making use of the ssh command’s config file. My config file is at C:\Users\username\.ssh\config and reads:

Host kathleen
    HostName kathleen.rc.ucl.ac.uk
    User uccaxxx

Now, I can type just “ssh kathleen” in the Windows Command Prompt and it will log me in to that system. If you have access to more than one system, just repeat the lines above in the config file with details for the other systems.

Programs like Putty or MobaXterm provide nice graphical forms to help you enter the connection settings. I have found them useful and I keep them installed on my laptop on standby. Going back to a simple terminal window was, however, not just to be cool (for which I would have just bought a Mac), but because one can build on the ssh command and settings file with tools that use those.

SSH Keys

Before looking at those, I will describe setting up SSH keys on Windows. However, you can skip on to the next section, until, of course, you begin to tire of typing passwords.

SSH keys allow you to log in to a remote system without a password and, paradoxically, more securely. The keys come in pairs: a public key and private key. They have the curious properties that, although they are different, a message encrypted with the public key can be decrypted with the private key and that it is very hard to find the private key from the public key. The public key can be handed out to people you want to communicate with, but it is essential, just as with your passwords, to keep the private key securely inaccessible. This is a fantastic technology that has revolutionised secure communications: the parties no longer have to have the same print edition of the Hitchhiker's Guide to the Galaxy with a key marked with a secret pin prick.

So, if you put your public key on a remote server the login process can send encrypted messages to a cooperating process on your computer to establish that you have the corresponding private key and hence trust that it should log you in (see Digital Ocean's Understanding the SSH encryption and connection process for a more detailed explanation). The command ssh-keygen is available on Windows for you to use to generate a key pair. The command ssh-copy-id, which provides a single simple command to copy your public key to a remote server appears not to be available, so you will have to copy it by some other means, for example the scp command or the graphical application WinSCP. One system I use has extra security surrounding uploading the public key: you have to upload it to your account in their account management website and then they put it in the right place for you.

You should, for security, create your key pair using the option to protect your private key with a password. We were trying to avoid passwords but, in fact, if you use the ssh agent you only have to enter it once. The ssh agent automatically decrypts your private key with your password as needed. Go into the Services window (press the Windows key and type “services”) and start the OpenSSH Authentication Agent service and set it to start automatically on start-up (this is the equivalent of ssh-agent command that is set to run in the background in Linux), then use the ssh-add command to add your key to the agent. It will ask for your password and then register the key with itself, and it will remember they key and password for your next Windows session. Nevertheless, you may want to keep your password for your private key in a password manager, for example F-Secure Key.

Most system administrators put up particular instructions on how to log in to their system (see for example the guides for Young and Archer). These usually assume that your computer is a Linux or Mac system. These instructions can be easily adapted for Windows because the ssh, ssh-keygen and ssh-add commands have the same syntax, but use the instructions above about starting the ssh agent and copying the public key. 

All this can be fiddly but is well worth it, and also the use of keys is becoming mandatory on some systems as security is tightened.

Once you have your keys set up you should note that in your ssh config file, e.g.:

Host kathleen
    HostName kathleen.rc.ucl.ac.uk
    User uccaxxx
    IdentityFile C:/Users/username/.ssh/id_rsa_kathleen

and the ssh command will use the key without you having to specify it each time.

Finally, don’t panic if you are happy with Putty or MobaXterm; both of these allow the use of keys.

Logging In From Home

One other complication on some systems is a restriction of where you can log in from, which is particularly relevant while most of us are working at home. This can be an absolute rule or require the IP address of where you log in from to be registered. Users of UCL’s clusters can use the VPN or using a jump server; both of these make it appear that you are logging in from UCL, thereby meeting that rule. I use the vpn solution regularly. The jump server approach is compatible with the ssh config file approach described above. I have used an arrangement where I had to register the address of a jump server at UCL because the HPC facility only allowed log ins from an organisation’s own premises. 

The New Windows Terminal

 

 

A successful one-click log in to UCL’s Kathleen system using Windows Terminal, using ssh keys and the custom menu item. Also shows the menu item for editing the settings file.

However, I am now going to suggest an alternative terminal program. Microsoft’s new Windows Terminal is still a work in progress but is nonetheless stable and usable, and available from the Windows Store and so is easily installed. Advantages of this terminal program over the basic Command Prompt is that you can have multiple sessions in tabs or panes and that those, if you wish, can be differently coloured depending on what they are connected to, which is great for keeping track of what you are doing.

With this terminal you can connect to your HPC system by typing the ssh commands described above just as you would expect (it uses the same ssh config file too), but you can also create menu items for those commands on this application’s drop-down menu, so you can connect and login with a single click. As it stands you have to edit the application’s settings file yourself to do that; here is an example of an entry in the settings for such a menu item:

{

    "guid": "{72fbaaa8-c15f-499a-b35b-a875994ab299}",

    "hidden": false,

    "name": "Kathleen",

    "commandline": "powershell.exe -Command ssh kathleen",

    "colorScheme": "Tango Dark",

    "background": "#430069"

},

 

I copied this set of settings from an existing one in the file and edited the lines in bold. “name” is the menu item name, the “guid” is a unique number needed perhaps by the menu library (I used www.guidgenerator.com to make a new one) and the “commandline” is the local terminal program to start in the terminal window (here powershell.exe but cmd.exe should be fine too – use “cmd.exe /C ssh kathleen”) together with the first command to run in it, which is one of our ssh commands. There are other settings for colours and fonts, for example to make the background colour different for different remote systems – here I have overridden the background colour from one of the preset colour schemes to approximate UCL purple. Being able to click once to connect and log in will save you lots of time. 

So, Windows on your laptop is fine for HPC users and you too can have a cool simple terminal window, even if it is a nightmarish simulation of the 1970s that you can’t escape. Or can you? Next time I will take a look at VSCode for use by coders and ordinary HPC application users alike, and have more of a think about why we are not being given a remote desktop.

I will leave you with a tip from my mum: if you drop your stack of punch cards you will see the wisdom of having numbered them consecutively.