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