Skip to content

Login information

Logging in

Once you have an account, you can log into the cluster from any network, using a two-factor authentication (2FA) and secure shell (SSH). Detailed information for SSH login can be found at link. Detailed instruction for two-factor authentication is sent by email to active users.

You can choose one of the following login nodes:

  • - logging in on one of the eight login nodes.
  • - logging in on one of the four login CPU nodes.
  • - logging in on one of the four login GPU nodes.
ssh <username>
ssh <username>
ssh <username>

Connect from Linux/Mac terminal

Users instructions is available on link

Connect by using PuTTY on Windows

Users instructions is available on link


SSH connection timed out

To enable the keep alive the session edit ~/.ssh/config file (create the file if it doesn’t exist).

Insert the following:

   Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2

These settings will make the SSH client send a null packet to the other side every 300 seconds (5 minutes), and give up if it doesn’t receive any response after 2 tries, at which point the connection is likely to have been discarded anyway.

Setting right permissions for SSH keys

This article will create your server's .ssh directory file with the correct permissions. However, if you've created them yourself and need to fix permissions, you can run the following commands on your server while having established ssh connection to the system and logged in as your user.

$  chmod 700 ~/.ssh
$  chmod 400 ~/.ssh/id_rsa
$  chmod 644 ~/.ssh/

It also has to be taken care of the ownership and group ownership settings of the key pair files. In both case user has to be set as an owner.

$  chown <username>:<username> ~/.ssh/id_rsa
$  chown <username>:<username> ~/.ssh/

Retrieve Your Public Key from Your Private Key

The following command will retrieve the public key from a private key:

$   ssh-keygen -y -f <private_key> (ie. /usr/home/.ssh/id_rsa)

This can be useful, for example, if your server provider generated your SSH key for you and you were only able to download the private key portion of the key pair. Note that you cannot retrieve the private key if you only have the public key.

Unable to connect to the host due to host identification change

Sometimes during the establishing of SSH connection, the following message can appear.

 $  ssh <IP>
 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 It is also possible that a host key has just been changed.
 The fingerprint for the ECDSA key sent by the remote host is
 Please contact your system administrator.
 Add correct host key in /Users/<user>/.ssh/known_hosts to get rid of this message.
 Offending ECDSA key in /Users/khess/.ssh/known_hosts:4
 ECDSA host key for <IP> has changed and you have requested strict checking.
 Host key verification failed.

What has happened here is that you've attempted to connect to a system that no longer has the same IP address. A different system has that IP address and SSH is complaining that you might be getting hacked. The reality is often much less exciting. Your known_hosts file may not sync with actual host reality.

The easy solution to this problem is to remove the known_hosts file in the .ssh directory completely and therefore allow new keys to be generated for each host you connect to.

But if you have not only this one host in the known_hosts file, but many others. It might not be a good idea to delete whole file, because you would loose record of all the other hosts as well. In this case it is a better solution just to edit the known_hosts file. You can change IP of the host or delete the host part completely.