Log in without Password #

These instructions explains how to set up your local computer such that you can log into the compute cluster, or copy files to and from the cluster, without having to enter your password each time.

Instruction #

In summary, the steps are:

  1. On your local computer: Generate private-public key pair
  2. On the cluster: Add public key
  3. On your local computer: Verify password-free access
  4. On your local computer: Edit ~/.ssh/config for setting default SSH options per remote host/server

Expected time: < 10 minutes.

Step 1: Generate private-public SSH key pair (on local machine) #

Here, we will generate a private-public SSH key pair (stored in two files) that is unique for accessing the cluster:

{local}$ mkdir ~/.ssh
{local}$ chmod u=rwx,go= ~/.ssh
{local}$ ssh-keygen -f ~/.ssh/laptop_to_wynton
Generating public/private rsa key pair.
Created directory '/home/alice/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alice/.ssh/laptop_to_wynton
Your public key has been saved in /home/alice/.ssh/laptop_to_wynton.pub.
he key fingerprint is:
SHA256:2MpJL+I6rQbfhvLZAyC6fa6Y40yZhwG+FYOiHCQ94Fw alice@my_laptop
The key\'s randomart image is:
+---[RSA 2048]----+
|o+ E             |
|= =              |
|o= +             |
|O . o  o         |
|+= .  o S        |
|o O  o +         |
| @ *. = .        |
|*oB+*. .         |
|+B*O+.           |

Step 2: Add the public SSH key (on cluster) #

Next, we will set up the cluster to recognize your public SSH key. Assuming your cluster user name is alice in the cluster, the goal is to append the content of the public key file to ~/.ssh/authorized_keys on the cluster. There are two ways this can be done.

Alternative 1: If you have the ssh-copy-id tool installed on your local computer, then use:

{local}$ ssh-copy-id -i ~/.ssh/laptop_to_wynton.pub alice@log1.wynton.ucsf.edu
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/wynton/home/boblab/alice/.ssh/laptop_to_wynton.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
alice@log1.wynton.ucsf.edu:s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'alice@log1.wynton.ucsf.edu'"
and check to make sure that only the key(s) you wanted were added.



Alternative 2: If you don’t have ssh-copy-id, you will have to copy the public key file over to the cluster, log in, append it to the target file, and validate file permissions. Assuming you already have a ~/.ssh folder on the cluster, first copy the public key file to ~/.ssh on the cluster:

{local}$ scp ~/.ssh/laptop_to_wynton.pub alice@log1.wynton.ucsf.edu:.ssh/
laptop_to_wynton.pub           100%  390     0.4KB/s   00:00

Then, log into the cluster (still using a password) and append the public key to ~/.ssh/authorized_keys:

{local}$ ssh -o PreferredAuthentications=keyboard-interactive,password alice@log1.wynton.ucsf.edu
alice1@\'s password: XXXXXXXXXXXXXXXXXXX
[alice@log1 ~]$ cd .ssh
[alice@log1 .ssh]$ cat laptop_to_wynton.pub >> authorized_keys

Finally, make sure that ~/.ssh/authorized_keys on Wynton is only accessible to you (otherwise that file will be completely ignored by SSH);

[alice@log1 .ssh]$ chmod u=rw,go= ~/.ssh/authorized_keys
[alice@log1 .ssh]$ stat --format=%A ~/.ssh/authorized_keys

Lastly, log out from the cluster:

[alice@log1 .ssh]$ exit


Step 3: Test #

You should now be able to log into the cluster from your local computer without having to enter the cluster password. Try the following:

{local}$ ssh -o PreferredAuthentications=publickey,keyboard-interactive -o IdentitiesOnly=yes -i ~/.ssh/laptop_to_wynton alice@log1.wynton.ucsf.edu
[alice@log1 ~]$ 

You will be asked to enter your passphrase, if you chose one above.

If you get

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive,password).

then make sure you use the correct user name and that the file permissions on ~/.ssh are correct on your local machine. See Appendix Section ‘Fix in-secure file permission on ~/.ssh/’ for instructions. If it still does not work, check the ~/.ssh permissions on the cluster too.

The reason why we use -o PreferredAuthentications=publickey,keyboard-interactive -o IdentitiesOnly=yes in the above test, is so that we can make sure no alternative login mechanisms than our SSH keypair are in play. After having validated the above, these options can be dropped and you can now use:

{local}$ ssh -i ~/.ssh/laptop_to_wynton alice@log1.wynton.ucsf.edu
[alice@log1 ~]$ 

Step 4: Avoid having to specify SSH option -i (on local machine) #

It is rather tedious having to specify what private key file to use (-i ~/.ssh/laptop_to_wynton) each time you use SSH. As a last step, we will set the default options for alice@log1.wynton.ucsf.edu. On your local machine, add the following entry to ~/.ssh/config (if you don’t have the file, create it):

Host log1.wynton.ucsf.edu
  User alice
  IdentityFile ~/.ssh/laptop_to_wynton

With all of the above, you should now be able to log in to the cluster using:

{local}$ ssh log1.wynton.ucsf.edu
[alice@log1 ~]$ 

Appendix #

Fix in-secure file permission on ~/.ssh/ #

On your local machine, open a terminal, and run

{local}$ stat --format=%A ~/.ssh

The stat output consists of four parts: d tells us it is a directory, rw- specifies the permission for the user (u), and the following --- and --- specifies the permissions for the group (g), and all others (o), respectively.

If the reported permission for group and others are anything but ---, then scp and ssh don’t trust the folder and will silently ignore your SSH key pair. To secure the folder, do:

{local}$ chmod u=rwx,go= ~/.ssh
{local}$ stat --format=%A ~/.ssh

Explanation: The above chmod settings specify that you as a user (u) have read (r) and write (w) permissions for this directory. In addition, you have executable (x) permission, which also means you can set it as your working directory. Continuing, the settings also specify that other users in your group (g) as well as all other (o) users on the system have no access at all (empty permission).