Authenticating through secure shell (SSH) protocol

Secure shell protocol (SSHP / SSH) is a way for computers to talk to eachother in a secure / encrypted way. It relies on key pair authentication, where one key (the public key) can be shared with any server that wants to authorize a user, and another key (the private key) is kept secret by the user, and can be used to verify their identity and access.

Uses of SSH keys

The primary services that will use SSH keys in the lab are

1. Git hosts like Forgejo and github. You can tell the git client to authenticate with SSH, removing the need for usernames/passwords on the command line.
2. Signing into lab servers like dogen
3. Signing into the HPCC

Using SSH keys for authentication

In principal, you can use a single key pair for every server, but this is not a great idea. If your private key is compromised, you’d have to revoke it’s access on every service that it’s linked to.

Keep your private keys private!

Anyone with access to your private key can sign in as you with all of your privileges. Do not share with anyone, or upload the key to anywhere that others have access to.

Instead, you can create separate keypairs and configure your computer to know which to use in any given situation.

Creating a new key pair

Typically, we store them in the ~/.ssh/ directory - if you don’t already have this directory, create it with mkdir ~/.ssh.

To generate an SSH key pair, you’ll use ssh-keygen with a few arguments.

• -t ed25519 - there are different algorithms to create keypairs, this is a very secure one
• -b 4096 - bits of entropy - higher numbers are more secure. Anything more than 4096 is overkill.
• -f ~/.ssh/{SERVICE}-key - this is the path where the keys will be stored
• -N "" - this says not to include a password to unlock the key. Having a password is more secure, but less convenient. Note: this password has no relationship to other passwords - eg if you’re using it to login to the hpcc which uses your Tufts.edu password, this password does not need to be (and probably shouldn’t be) the same

So for example, if Kevin was creating a keypair for the hpcc, he would enter:

ssh-keygen -t ed25519 -b 4096 -f ~/.ssh/tuftshpc-key -N ""

You will get some output that looks like

Generating public/private ed25519 key pair.
Your identification has been saved in /home/kevin/.ssh/tuftshpc-key
Your public key has been saved in /home/kevin/.ssh/tuftshpc-key.pub
The key fingerprint is:
SHA256:a09gW78lAJLFhUv3PMnmyk456qmfotihYkXz/jbk5WY kevin@dhcp-130-64-46-214.boston.tufts.edu
The key's randomart image is:
+--[ED25519 256]--+
|       ..o.      |
|       o+ .      |
|      o..o + .   |
|   o   ...  B    |
|  . o   S oo .   |
|   . . o * +.    |
|  . o o *.=.o .  |
|.. + o.= Eo. +   |
|..o o.+*X.o .    |
+----[SHA256]-----+

Note that two files were created, ~/.ssh/{SERVICE}-key and ~/.ssh/{SERVICE}-key.pub. As you might expect, the *.pub file is the public key. You can see the contents using cat, eg

cat ~/.ssh/tuftshpc.key

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICySGWa+8wr4b9ufw7Lu87WN9LyxL1ZqHOrT4D26t8kg kevin@dhcp-130-64-46-214.boston.tufts.edu

Don't share your private key!

If your output starts with -----BEGIN OPENSSH PRIVATE KEY-----, this is a private key! Don’t share it!

Add your public key to the server/service

Now that you have your keypair, you need to copy your public key to the server that you want to use it to login to.

For example, if this is a keypair for Forgejo, go to https://code.bonhamlab.bio/user/settings/keys, under “Manage SSH keys”, click “add key”. Give it a name (eg “laptop login”), and paste the contents of you public key.

If this is a keypair for the HPCC, you can login normally and then paste the contents into ~/.ssh/authorized_keys, or use SSH to copy it directly:

ssh-copy-id {TTS_ID}@login.pax.tufts.edu

After entering your password again, this will append your public key to the file ~/.ssh/authorized_keys on the HPC server automatically.

Setting up ~/.ssh/config

To simplify things even further, you can set up a ~/.ssh/config file so that your computer will know which keys to use for which service.

You can have multiple entries in the config. The most important components are Host and IdentityFile, but you can set many other options, depending on the service

• Host (top level) - the identity of the server. This is sometimes a url, but can also be your own name for something (if you also specify HostName)
• IdentityFile - the path to the private key used for this server
• HostName - if you used a custom name, this is the actual url or IP address
• User - the username. For things like forgejo and github, the username should be git

So for example, if you normally login to the HPCC with

ssh user123@login-prod.pax.tufts.edu

You could add the following to ~/.ssh/config to avoid needing to enter a password:

Host login-prod.pax.tufts.edu
	IdentityFile ~/.ssh/tuftshpc-key

Alternatively, you could do

Host tufts
	HostName login-prod.pax.tufts.edu
	IdentityFile ~/.ssh/tuftshpc-key	

Which would allow you to login by typing ssh user123@tufts, rather than typing out the whole long host name. If you add User user123 on a different line, you can just do ssh tufts, and the ssh protocol will fill in the rest for you.

Here is a bit of Kevin’s current config (the actual thing is about 3x as long):

Host github.com
    User git
    IdentityFile /home/kevin/.ssh/github-key
Host gitlab.com
    User git
    IdentityFile /home/kevin/.ssh/gitlab-key
Host code.bonhamlab.bio
    User git
    IdentityFile /home/kevin/.ssh/forgejo-key
Host dogen
    HostName 130.64.46.214
    User kevin
    IdentityFile /home/kevin/.ssh/dogen-key
Host tuftshpc
    User kbonha01
    IdentityFile /home/kevin/.ssh/tuftshpc-key
    HostName login-prod.pax.tufts.edu
Host tufts1
    User kbonha01
    IdentityFile /home/kevin/.ssh/tuftshpc-key
    HostName login-p01.pax.tufts.edu
Host tuftsxfer
    User kbonha01
    IdentityFile /home/kevin/.ssh/tuftshpc-key
    HostName xfer.pax.tufts.edu
Host dogen
    HostName dhcp-130-64-46-214.boston.tufts.edu
    User kevin
    IdentityFile /home/kevin/.ssh/dogen-key
    RequestTTY yes