Login / Authentication

1.  Authentication Mechanism

Each cluster user is requested to generate his/her own SSH private and public keys. The public key is then sent to us (see later) and we will propagate it on all the clusters. Please note that this is the only procedure to reach the cluster (accounts are created using 40 digits passwords randomly generated).

The steps every user needs to do are:

1.1  Generate your keys

You need first to generate your private and public keys:

   PROMPT$ ssh-keygen -t dsa

You will be prompted to insert a passphrase. Do not leave this blank! Please be sure to choose a good passphrase: it should be longer and more difficult to guess than your password.

1.2  Send us your public key

   PROMPT$ mail -s "cluster key for $USER" helpdesk-hpc@sissa.it < ~/.ssh/id_dsa.pub 

If sendmail isn't active on your PC, this command fails without notice. In this case, send directly your key as attachment to helpdesk-hpc. Try "ps -C sendmail -o pid=" in order to check if the process is running. Please, if you have already sent the key without receiving our reply, check it.

(please: send us the public key (.pub), not the private one !)

The steps below will be available as soon as we propagate the keys on the clusters.

It's understood that, on the clusters on which you already have an account, you can propagate the public key by yourself (we do it for you only for new accounts). You just need to copy the content of ~/.ssh/id_dsa.pub on ~/.ssh/authorized_keys of the masternode. You can secure-copy the public key on the masternode and do it manually, or you can try this (example for briareo):

   cat ~/.ssh/id_dsa.pub | ssh briareo "cat >> ~/.ssh/authorized_keys" 

Note that quotation marks are not optional. Do not use a single '>' symbol or you might overwrite an already existent authorized_keys used for cluster connections.

Note also that, if you overwrite your authorized_keys ('cp', 'mv' or '>'), you will get into troubles since you'll loose any pre-existent keys and therefore the possibility to login to cluster's nodes and your jobs will miserably die. If for you the reason of these warnings is not clear, please give a look into "id_dsa.pub" and into "authorized_keys" by using a harmless tool like 'less' or 'more' so that you can get familiarity with their content and with the kind of job that the commands written above are doing.

1.3  Start the agent

(optional if the window manager already handles it)

The ssh agent will keep your private key(s) ready for use:

   PROMPT$ eval `ssh-agent` 

The above line will start the agent and load some variables into the current environment. If you run a csh-type shell (csh,tcsh) you will need to run the command:

   PROMPT$ eval `ssh-agent -c` 

Note that those above are backticks (`), you are executing a subshell and eval is loading the output of the command ssh-agent into the environment.

ssh-agent produces this kind of outputs:

   bash$ ssh-agent
   SSH_AUTH_SOCK=/tmp/ssh-VvvdT26891/agent.26891; export SSH_AUTH_SOCK;
   SSH_AGENT_PID=26892; export SSH_AGENT_PID;
   echo Agent pid 26892;
   tcsh$ ssh-agent -c
   setenv SSH_AUTH_SOCK /tmp/ssh-PhSZw26895/agent.26895;
   setenv SSH_AGENT_PID 26896;
   echo Agent pid 26896;

If you are able to see one of the two outputs above, it means that you are using apostrophes (') or you aren't using the eval. All that you should see is:

   Agent pid 26896 

Note also that the ssh-agent provides passwordless authentication only inside the current X or login session, it is unable to cover any other login performed through other machines. For instance, you cannot login from your PC to shannon and expect the shannon's ssh to be able to connect to the agent on your PC, you need to run another ssh-agent on shannon and (ssh-)add your key again (and enter the passphrase as well).

1.4  Notes

  1. This step is optional only if your Window Manager already starts an ssh-agent at startup. The command "ps waux | grep ssh-agent" will show any already running ssh-agent. If the WM doesn't handle it, you can add a line into your ~/.xinitrc or ~/.Xclient (or whatever is called on your system) to launch an agent as described above.
  2. If you run the ssh-agent from a terminal (xterm, kconsole, ...) the environment variables will be inherited only by subshells, any new terminal will ignore the existence of a running ssh-agent. This is the reason why the agent is usually intended to be invoked by the WM.

2.  Register your private key

Now there is an agent started but it does not know about your keys, so we need to add them with ssh-add.

   PROMPT$ ssh-add
   (at this point you will be prompted for your passphrase) 

Now you should be able to log in to all our clusters with the public key only, and without any other password!

For further information on the commands mentioned above, here you can find their online manpages:

   * ssh
   * ssh-add
   * ssh-agent
   * ssh-keygen
   * How to generate keys

3.  Important Notes

  1. The passphrase is just to protect your own private key and it has nothing to do with cluster's account and password.
  2. The word "passwordless" is somehow misleading, each time you need to use your private key you DO have to use the password BUT, fortunately for you, a nice tool exists (ssh-agent) and it remembers the key once it has been unlocked and added (through ssh-add and your long, secure and criptic passphrase like "pippo" or "fragola").
  3. Your private key should be securely stored on your computer, permissions should be just 600
  4. If you want to reach the clusters from other sissa machines (namely shannon & democritos) you can copy your private key over there in your own .ssh directory.

4.  Update Cluster Keys


  1. Create a backup copy of your old private and public keys
  2. Create the new keys with a name different from the existing one
  3. Access all the clusters on which you need to update the public-key and add the content of the new public-key in ~/.ssh/authorized_keys, then remove your old public key line
  4. Back on your local machine, copy the new public and private keys with the correct name and location.

Here you can find an example:

Create a backup of the old keys

   cp id_dsa id_dsa.OLD
   cp id_dsa.pub id_dsa.pub.OLD 

Create the new keys as usual, but specifying a different name

   ssh-keygen -t dsa -f ~/.ssh/NEWKEY 

Copy the new public key on the cluster...

   cat ~/.ssh/NEWKEY.pub | ssh cluster "cat >> ~/.ssh/authorized_keys" 

Substitute the keys

   mv NEWKEY id_dsa
   mv NEWKEY.pub id_dsa.pub 

Logon on the cluster and remove the old public key from ~/.ssh/authorized_keys

5.  Contacts

Please all questions/comments/threats to: helpdesk-hpc

(mail to private accounts will be silently ignored)

Have a nice computation...