2. Connecting and Data Transfer

On the ARCHER system interactive access can be achieved via SSH, either directly from a command line terminal or using an SSH client. In addition data can be transfered to and from the ARCHER system using scp from the command line or by using a file transfer client.

This section covers the basic connection and data transfer methods, along with presenting some performance considerations. The connection procedure is then expanded on as the use of SSH agent is described for ease of access.

2.1 Interactive access

To log into ARCHER you should use the "login.archer.ac.uk" address:

ssh [userID]@login.archer.ac.uk

Windows users will need an SSH client. We find the following tools useful:

This short screencast demonstrates connecting to ARCHER from Windows using PuTTY and displaying graphical output using Xming (you should ensure your YouTube settings specify HD video - see the "Settings" icon in the bottom right corner):

Note on using MobaXterm on ARCHER:

When you log in to a system using MobaXterm, it also tries to set up a SFTP session. On ARCHER this cannot happen automatically so you will receive a prompt for SFTP browser password.

Three possible solutions are:

  • Turn off the SFTP browser
  • Re-enter your password when prompted
  • Use SSH keys and tell MobaXterm about them

2.1.1 Initial passwords (changing LDAP password)

The SAFE web interface is used to provide your initial password for logging onto ARCHER (see the SAFE User Guide for more details on requesting accounts and picking up passwords).

This password is a "one-shot" password that is valid for your initial access to ARCHER. As soon as you log into the machine you will be asked to change this initial password to one of your choice, by first re-entering your initial password and then choosing a new one. The prompt will refer to an LDAP password, this is simply your login password for ARCHER (LDAP is the type of authentication database used by the ARCHER service to manage access).

Note: your password must conform to the ARCHER Password Policy to be accepted by the system. You can find the policy at:

Note: once you change your password on the ARCHER machine itself this change will not be reflected in the SAFE. If you forget your password, you should use the SAFE to request a new one-shot password.

2.1.2 Interactive access to Post Processing nodes

The ARCHER post processing (PP) nodes are provided for compute, memory, or data-intensive operations that do not require access to parallel, compute nodes. /home, /work and the RDF filesystems are all mounted on the PP nodes.

The PP nodes can be accessed in two ways:

  1. Via the serial queues: see the description in the Post Processing Jobs section of this User Guide.
  2. Via direct interactive access: this is described below.

To connect to the PP nodes you must first be logged in to the ARCHER login nodes as described above. Once on the ARCHER login nodes you connect to one of the two PP nodes using the ssh command and one of the following host names:

  • espp1
  • espp2

For example, to connect to the espp1 PP node you would first log in to ARCHER and then use the command:

ssh espp1

You will be prompted for a password - this is your ARCHER password. If you set up and export an SSH Agent as described below then you will not need to enter a password each time you log into the PP nodes.

Commands can be run on the PP nodes from within a compute node job script by setting up access using SSH keys and issuing the commands via "ssh" in the script itself.

If you wish to export the PP node display back to your local workstation (for example you are using an application with a GUI). Then you should first log into ARCHER using the "-X" (or "-Y") option to ssh and then add this option to your ssh command to access the PP nodes. For example:

ssh -X espp1

Note: compiling programs for the PP nodes is a slightly different procedure than compiling for the compute nodes. See the Compiling for Post Processing nodes section in this User Guide. You can use the PP nodes for performing long compilations for the compute nodes using the standard compiling commands outlined in this User Guide.

Note: you must be logged in to the ARCHER login (or MOM/job launcher nodes via a batch job) before you can log in to the PP nodes.

2.2 Transferring data to and from ARCHER

The ARCHER systems are connected to the outside world via the UK academic SuperJANET5 network.

The simplest way of transferring data to and from ARCHER is using the scp command. Here are some examples:

Example 1:

The following command on your local system, will transfer the file source.f to your home directory on the ARCHER system.

scp ./source.f [username]@login.archer.ac.uk:
Example 2:

The following command will copy the file input_data.tar.gz from your local system to the RUN5 sub-directory on your work directory.

scp ./input_data.tar.gz \
  [username]@login.archer.ac.uk:/work/[project]/[group]/[username]/RUN5
Example 3:

The following command will copy the sub-directory RESULTS from your work directory to the current directory on your local system (note the use of the -r option).

scp -r [username]@login.archer.ac.uk:/work/[project>]/[group]/[username]/RESULTS ./
Example 4:

If your local system supports ssh logins, you may also run the scp commands from the ARCHER system. For example, the same transfer of the RESULTS sub-directory on ARCHER to the home directory of your local system could also be accomplished by running the following command on the ARCHER system:

scp -r /work/[project]/[group]/[username]/RESULTS \
  local_username@machine_name.institution.ac.uk:~

2.2.1 Performance considerations

ARCHER is capable of generating data at a rate far greater than the rate at which this can be downloaded over SuperJANET5. In practice, it is expected that only a portion of data generated on ARCHER will be required to be transfered back to users' institutions - the rest will be, for example, intermediate or checkpoint files required for subsequent runs. However, it is still essential that all users try to transfer data to and from ARCHER as efficiently as possible. The most obvious ways to do this are:

  1. Only transfer those files that are required for subsequent analysis, visualisation and/or archiving. Do you really need to download those intermediate result or checkpointing files? Probably not.
  2. Combine lots of small files into a single tar file, to reduce the overheads associated in initiating data transfers.
  3. Compress data before sending it, e.g. using gzip or bzip2.
  4. Consider doing any pre- or post-processing calculations on ARCHER. Long running pre- or post- processing calculations should be run via the batch queue system, rather than on the login nodes. Such pre- or post-processing codes could be serial or OpenMP parallel applications running on a single node, though if the amount of data to be processed is large, a MPI application able to use multiple nodes may be preferable.

Note that the performance of data transfers between ARCHER and your local institution may differ depending upon whether the transfer command is run on ARCHER or on your local system.

2.3 Making access more convenient using a SSH Agent

Using a SSH Agent makes accessing the resources more convenient as you only have to enter your passphrase once per day to access any remote resource - this can include accessing resources via a chain of SSH sessions.

This approach combines the security of having a passphrase to access remote resources with the convenince of having password-less access. Having this sort of access set up makes it extremely convenient to use client applications to access remote resources, for example:

  • the Tramp Emacs plugin that allows you to access and edit files on a remote host as if they are local files;
  • the Parallel Tools Platform for the Eclipse IDE that allows you to edit your source code on a local Eclipse installation and compile and test on a remote host;
  • the Allinea DDT (debugger) and MAP (profiler) that allows you to run the client on your local machine while debugging and/or profiling codes running on a remote host.

We will demonstrate the process using the ARCHER facility but this should work on most remote Linux machines (unless the system administrator has explicitly set up the system to forbid access using an SSH Agent).

Note: this description applies if your local machine is Linux or Mac OSX. The procedure can also be used on Windows using the PuTTY SSH terminal with the PuTTYgen key pair generation tool and the Pageant SSH Agent. See the PuTTY documentation for more information on how to use these tools.

Note: not all remote hosts allow connections using a SSH key pair. If you find this method does not work it is worth checking with the remote site that such connections are allowed.

2.3.1 Setup a SSH key pair protected by a passphrase

The instructions below are demonstrated in this screencast:

Using a terminal (the command line), set up a key pair that contains your e-mail address and enter a passphrase you will use to unlock the key:

ssh-keygen -t rsa -C "your@email.ac.uk"
...
-bash-4.1$ ssh-keygen -t rsa -C "your@email.ac.uk"
Generating public/private rsa key pair.
Enter file in which to save the key (/Home/user/.ssh/id_rsa): [Enter]
Enter passphrase (empty for no passphrase): [Passphrase]
Enter same passphrase again: [Passphrase]
Your identification has been saved in /Home/user/.ssh/id_rsa.
Your public key has been saved in /Home/user/.ssh/id_rsa.pub.
The key fingerprint is:
03:d4:c4:6d:58:0a:e2:4a:f8:73:9a:e8:e3:07:16:c8 your@email.ac.uk
The key's randomart image is:
+--[ RSA 2048]----+
|    . ...+o++++. |
| . . . =o..      |
|+ . . .......o o |
|oE .   .         |
|o =     .   S    |
|.    +.+     .   |
|.  oo            |
|.  .             |
| ..              |
+-----------------+

(remember to replace "your@email.ac.uk" with your e-mail address).

2.3.2 Copy the public part of the key to the remote host

Using you normal login password, add the public part of your key pair to the "authorized_keys" file on the remote host you wish to connect to using the SSH Agent. This can be achieved by appending the contents of the public part of the key to the remote file:

-bash-4.1$ cat ~/.ssh/id_rsa.pub | ssh user@login.archer.ac.uk 'cat - >> ~/.ssh/authorized_keys'
Password: [Password]

(remember to replace "user" with your username).
Now you can test that your key pair is working correctly by attempting to connect to the remote host and run a command. You should be asked for your key pair passphase (which you entered when you creasted the key pair) rather than your remote machine password.

-bash-4.1$ ssh user@login.archer.ac.uk 'date'
Enter passphrase for key '/Home/user/.ssh/id_rsa': [Passphrase]
Wed May  8 10:36:47 BST 2013

(remember to replace "user" with your username).

2.3.3 Enabling the SSH Agent

So far we have just replaced the need to enter a password to access a remote host with the need to enter a key pair passphrase. The next step is to enable an SSH Agent on your local system so that you only have to enter the passphrase once per day and after that you will be able to access the remote system without entering the passphrase.

Most modern Linux distributions (and Mac OSX) should have ssh-agent running by default. If your system does not then you should find the instructions for enabling it in your distribution using Google.

To add the private part of your key pair to the SSH Agent, use the 'ssh-add' command (on your local machine), you will need to enter your passphrase one more time:

-bash-4.1$ ssh-add ~/.ssh/id_rsa
Enter passphrase for Home/user.ssh/id_rsa: [Passphrase]
Identity added: Home/user.ssh/id_rsa (Home/user.ssh/id_rsa)

Now you can test that you can access the remote host without needing to enter your passphrase:

-bash-4.1$ ssh user@login.archer.ac.uk 'date'
Warning: Permanently added the RSA host key for IP address '192.62.216.27' to the list of known hosts.
Wed May  8 10:42:55 BST 2013

(remember to replace "user" with your username).

2.3.4 Adding access to other remote machines

If you have more than one remote host that you access regularly, you can simply add the public part of your key pair to the 'authorized_keys' file on any hosts you wish to access by repeating step 2 above.

2.3.5 SSH Agent forwarding

Now that you have enabled an SSH Agent to access remote resources you can perform an additional configuration step that will allow you to access all hosts that have your public key part uploaded from any host you connect to with the SSH Agent without the need to install the private part of the key pair anywhere except your local machine.

This increases the security of the key pair as the private part is only stored in one place (your local machine) and makes access more convenient (as you only need to enter your passphrase once on your local machine to enable access between all machines that have the public part of the key pair).

Forwarding is controlled by a configuration file located on your local machine at ".ssh/config". Each remote site (or group of sites) can have an entry in this file which may look something like:

Host archer
  HostName login.archer.ac.uk
  User user
  ForwardAgent yes

(remember to replace "user" with your username).

The "Host archer" line defines a short name for the entry. In this case, instead of typing "ssh login.archer.ac.uk" to access the ARCHER login nodes, you could use "ssh archer" instead. The remaining lines define the options for the "archer" host.

  • Hostname login.archer.ac.uk - defines the full address of the host
  • User username - defines the username to use by default for this host (replace "username" with your own username on the remote host)
  • ForwardAgent yes - tells SSH to forward the local SSH Agent to the remote host, this is the option that allows you to store the private part of your key on your local machine only and export the access to remote sites

Now you can use SSH to access ARCHER without needing to enter my username or the full hostname every time:

-bash-4.1$ ssh archer 'hostname -a'
esl8 cdl8 eslogin008

You can set up as many of these entries as you need in your local configuration file. Other options are available. See the ssh_config man page (or "man ssh_config" on any machine with SSH installed) for a description of the SSH configuration file.

1. Introduction | Contents | 3. Resource Management