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.

You will need to use public key authentication in combination with MFA (2FA) on accounts that have this option enabled.

SSH key authentication has the advantage that it will save you from having to type a password, or in combinations with a 2FA token, you will only have to use the token, thus avoiding the dreaded "Connection refused" and 24 hour-lock outs that happen after mistyping a password more than three times.

In the links below you will find the way of setting up such keys and how to use them on two different families of platforms:  Linux, Mac or other POSIX terminals and MobaXterm on Windows.

Linux / Mac

See Creating and using an SSH key pair on the Terminal

Windows

See Creating and using SSH key pair with MobaXterm

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:

system

host(s)

hostkey fingerprint reference

Snellius

snellius.surf.nl

See Snellius Hostkey Fingerprints

Grid

ui.grid.sara.nl

(RSA) e9:88:fa:9a:a7:99:85:5a:b8:62:5e:04:da:7c:96:13

LSG

all 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.