Login / Authentication¶
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:
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.
Send us your public key¶
Send your PUBLIC key (e.g. ~/.ssh/id_dsa.pub) as attachment to elcid-support(AT)democritos.it
(please: be sure to send 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 (as on your workstation/laptop) into ~/.ssh/authorized_keys of the masternode. You can secure-copy the public key on the masternode and do it manually, or you can just use this (example for elcid):
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 the cluster nodes, which also means that your jobs will miserably die. Please take a look at “~/.ssh/id_dsa.pub” and “~/.ssh/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 do.
Start the agent¶
This step is optional, as most modern window managers already handle 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 (current shell/terminal only). 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 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), or use the ssh -A in order to enable the forwarding of the authentication agent connection.
# 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.
# 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 meant to be invoked by the WM.
Register your private key¶
Now there is an agent started but it does not know about your keys, so you 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!
Note that both ssh-agent and ssh-add provide a “-t LIFE” option which defines the lifetime/persistence of the key into the agent. For security reasons, might be better to avoid the default (forever) and set a lifetime of hours/days. Note that once the agent is killed (new window manager session), the keys are forgotten and a ssh-add is again needed.
For further information on the commands mentioned above, here you can find their online manpages:
# The passphrase is just to protect your own private key and it has nothing to do with cluster’s account and password.
# The word “passwordless” is somehow misleading, each time you need to use your private key you DO have to use the passphrase to unlock the key BUT, fortunately for you, a nice tool exists (ssh-agent) which remembers the key once it has been unlocked and added (through ssh-add and your long, secure and criptic passphrase like “pippo” or “fragola”).
# Your private key should be securely stored on your computer, permissions should be just 600 (like your ~/.ssh/ directory).
# 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.
Update Cluster Keys¶
BE AWARE THAT IF YOU REMOVE YOUR OLD KEY BEFORE UPDATING THE REMOTE SYSTEM, YOU WILL NEVER BE ABLE TO GET ACCESS TO THE CLUSTERS ANY MORE.
# Create a backup copy of your old private and public keys
# Create the new keys with a name different from the existing one
# 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
# 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...
ssh-copy-id -i ~/.ssh/NEWKEY 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