Synopsis

SSH mandatory at SURF

The only way to access SURF's HPC systems is by using ssh, scp or sftp, which use an encrypted and secured connection.

The reason for this is that an unencrypted telnet or ftp connection to a remote system is very unsafe. In many cases it is possible to use a computer to intercept all tcp packets that are sent on the local network. All data that is sent via the local network to a remote (or local) computer system can be read by anyone who has access to a computer that is linked to the local network. This is especially very undesirable in the case of passwords that are sent to other systems.

The SSH standard circumvents this problem, by encrypting all data that is sent over the network, including the passwords needed for authentication.

Installation on your work station

Installation of the software involved is, as far as we experienced, rather simple. The central site for the open SSH is http://www.openssh.com. There one finds implementations for Unix-es, Windows, Macintosh.In the following we will elaborate somewhat on the different platforms:

Usage

Logging in on one of SURF's HPC systems

ssh -X <myname>@<hpc-system>.surf.nl
  or
ssh -X <myname>@<hpc-system>.surfsara.nl

Where <myname>  is the login name on the HPC system, and hpc-system.surfsara.nl is the internet address of the HPC system. The -X flag is for the automatic arranging of your X environment. It depends on the configuration of ssh on your local workstation if this flag is necessary.

Copying files from your workstation to an HPC system

On your workstation type:
scp infile <myname>@<hpc-system>.surf.nl:dir/tofile

Where infile is the file you want to copy (you can specify more than one file and use wild charts if you like) and directory is the destination directory on the HPC system. When you omit directory, the file(s) will be copied to your home directory. tofile is the name the file gets on the HPC system. When omitted, the name will be the same as infile.

Copying files from an HPC system to your workstation:

On your workstation, type:

scp <myname>@<hpc-system>.surf.nl:dir/infile outfile

infile is the name of the file on the HPC system, outfile is the name of the file on your workstation.

Copying directories

You can copy a directory by specifying the -r  flag after scp, which will recursively copy anything in and below the given directory:

scp -r <myname>@<hpc-system>.surf.nl:dir/indir outdir

Bonus 1: automatic defining X11 environment in a safe way

There is a famous security problem connected with using X11 applications if your workstation is running some kind of Unix. Many people used the xhost command to produce X11 output on their screens. Not everybody is aware of the fact, however, that using the xhost command one creates very likely a situation where somebody, also logged in on the remote system can get access to the X-server running on the workstation and is able, for example, to read out every keystroke.

So we cannot stress enough: DON'T USE XHOST.

An alternative and more approved approach is the use of 'cookies' with the 'xauth' command.

Using ssh, neither of xhost or xauth is necessary, as ssh takes care of the X-window traffic, and setting the DISPLAY environment variable. Once you have a ssh connection from your Unix workstation with a SURF system, X-applications will automatically put their windows on your workstation, and all traffic is encrypted. Depending on the configuration of your system, you have to add the -X flag to the ssh command. When using PuTTY under Windows, choose 'Tunnels' from the 'Category' list and check the option 'Enable X11 forwarding'. Please note that you need a separate X-server, e.g. http://www.straightrunning.com/XmingNotes/.

Bonus 2: public-key authentication

Another bonus when using SSH is the possibility to login without using a password, using public-key authentication.

With this method a public-private key pair is generated once on your local workstation and the public key part (only) of that pair is then registered with SURF. Whenever you log into Snellius or Lisa the public key at SURF is then used together with the private key on your local workstation to authenticate, instead of having to enter your password.

The public-private key pair is automatically generated and much longer than a user-chosen password, and so provides much more safety against brute-force password guessing.

2FA

Note that public-key authentication is currently not compatible with two-factor authentication (2FA). This means that when 2FA is active on your login you will still get asked for your regular user account password, even when you have set up public-key authentication.

To set up publick-key authentication you need to do the following:

Create a public-private key pair

Create a key pair on your local workstation, by issuing the command

ssh-keygen -t ed25519

Then, enter a sentence you can easily remember for the passphrase question, this secures the private key.

Guard your private key with a passphrase

If you do not set a passphrase on the private key pair anyone that can steal your private key can authenticate anywhere you have registered the public key.

Upload the public key to SURF

For making the public key available to SURF there's two options:

  1. Through the SURF User portal (preferred)
    Upload your key on the userportal under "Public ssh keys". When adding the key you will be asked for the password of the user portal, to make sure no malicious actor can add their own SSH key.
  2. Manually
    Change to the directory $HOME/.ssh  on your local workstation and verify that a file called id_ed25519.pub is located there (this is the public key part of the key-pair generated above). Copy-paste the contents of this file into the file $HOME/.ssh/authorized_keys on the HPC system. If the directory $HOME/.ssh does not exist on the HPC system, you can create that directory securely with:

    mkdir -m 0700 $HOME/.ssh

After doing either of the above 2 steps you should then be able to log in from your workstation to the HPC system using the passphrase set on the key pair.

Caching the key-pair passphrase

If you've read the above description of how to set up a public-private key pair you might be wondering about the passphrase set on the key pair. Isn't that just another password that needs to be entered when authenticating to Snellius/Lisa? You are indeed right, but there are ways to cache that password on your local system using something known as an SSH agent. It depends on the particular operating system that you're using locally how the agent is to be set up.

For example, for Linux desktop-based system you can arrange that you have to type in the pass-phrase only once per login-session on your workstation:

  • When you are using the GNOME or KDE desktop environment, enter the command 'ssh-add' after which you will be prompted for your pass-phrase. The system remembers your passphrase and it is supplied automatically with subsequent ssh  and scp  commands.
  • When you are not using KDE or GNOME, it depends on your environment how to proceed. The general principle is, that you must be working in an environment started with ssh-agent, the KDE and GNOME environments take care of that. If you are not running KDE or GNOME, try something like:
ssh-agent bash

and give the 'ssh-add' command.

Host key fingerprints

 When you make an SSH connection to a remote system for the first time, SSH recognizes this and asks if you want to proceed.If you enter yes, the hostkey of the remote system gets stored in $HOME/.ssh/known_hosts on your local system. When you later make an SSH connection again to the same system SSH compares the remote hostkey with the locally stored hostkey. If there is a difference, you will get a warning and some functionality is not available. This is to protect you from possible attacks: you think you are connected to a particular host, but in reality you could be connected to another host (the so called "Man in the middle attack").

Most of the time, however, there is no problem because the hostkey of the host system has been changed for some reason, perhaps by an upgrade of the system. If you are sure that you are really connecting to the system you want, simply remove the line with the name of the remote host in the file $HOME/.ssh/known_hosts and connect again. You could also try a more drastic approach: remove the file $HOME/.ssh/known_hosts altogether. The above is for Unix systems. In general, the SSH implementations for Windows and Macintosh issue a warning and let you choose to change the stored hostkey.

Hostkey fingerprints for our systems are listed here, for verification:

systemhost(s)hostkey fingerprint reference
Snelliussnellius.surf.nlSee Snellius Hostkey Fingerprints
Cartesiuscartesius.surfsara.nlSee Cartesius Hostkey Fingerprints
Lisalisa.surfsara.nlSee Lisa Hostkey Fingerprints
Gridui.grid.sara.nl(RSA) e9:88:fa:9a:a7:99:85:5a:b8:62:5e:04:da:7c:96:13
LSGall LSG sites(RSA) 9c:ed:a5:89:f8:91:fc:08:51:cb:6f:a7:c9:89:ee:47

Feedback

SURF considers easy and secure access to the HPC systems important, so in case of difficulties, please contact our Service Desk.