The Secure Shell (SSH) protocol uses encryption to provide authentication and privacy when logging in to other computers over a network, such as Romulus, Remus, or the Computing Cluster. It can also be used to securely execute remote commands. By default logins use a password, but it’s also possible to set up passwordless connections. The latter are very convenient, and are also required to initiate remote commands. However, for security reasons they should not be used from computers that are accessible to others.
SSH by default uses RSA encryption to encode and decode information. It uses software keys consisting of two related parts, a public key and a private key, both of which are long strings of characters, e.g.
AAAAB3NzaC1yc2EAAAABIwAAAIEAxrbRWzvkWLIBnF6lSmyC4Vb2StULViRpdVASWJp5/52xpE...
These strings represent numeric values, and the longer they are the more security they provide (but also the longer they can take to “unlock” your access). Currently, 2048-bit strings seem to be a preferred length for long term use.
The basic idea in this scheme is that a public key can be used by anyone to encrypt a message to be sent over an insecure network, but only the intended recipient can decrypt it using their private key. For example, when using a password to log in to a remote computer such as Romulus, that computer or host provides you with its unique public key, which you use to encrypt your password and other data. The host can then decrypt your password with its private key, which it uses to verify that you should have access to your account. It then uses your computer’s public key to encrypt its response (SSH will generate a temporary key pair for each connection if one is not already defined).
One security issue issue here is that it’s possible for another computer to intercept your login request and send you its own public key to pretend to be the intended host (a “man in the middle”); hence your computer will maintain a list of known hosts and their public keys. This reduces the issue to your first contact with the intended host, which is announced by the SSH software so you can verify its certification. Note that occasionally host keys will change and you’ll have to reaccept them — though it should raise questions in your mind about whether another computer is pretending to be your destination.
It’s also possible to create software keys to uniquely identify yourself to a host. By putting your keys on both computers, they can immediately communicate with each other in a secure fashion, without the need for you to enter your password. This is particularly important if you want applications to easily talk to each other between computers, as on our computing cluster.
It’s a good idea to set up your keys once, and then copy them to the remote systems you wish to use. That way you can ensure you are using a single key pair everywhere, which will be less confusing (though not required). This information is stored in your home directory (folder), which is shared between Romulus and Remus, so you only need to set it up there once; you could then copy them to the computing cluster, whose nodes also share a home directory.
Setting Up an SSH Key Pair on Romulus, Remus, the Cluster, or Another Unix or Unix-Like System (Including a Macintosh)
For these instructions you will need to access your Unix system from a shell, a text-only interface.
- If you are on Windows, you can use Git Bash to follow these instructions locally or log in to a remote host. You can also putty, though it’s somewhat more difficult to set it up locally.
- If you are using a Macintosh, open the folder Applications, then the folder Utilities, and start up the application Terminal.
For convenience, it’s easiest to set up your first set of keys remotely, then copy them locally. So login to the remote host (e.g. Remus), with Mac Terminal or Windows Git Bash using the command:ssh <remote host> <Enter>
(<Enter> is the key on the keyboard, also called Return on Macs and other computers).
Command lines in Unix typically begin with account, computer, and directory information followed by a $, e.g.
[YourAccount@Host ~]$
or
Host:~ YourAccount$
The ~
represents your home directory (folder), with all of the rest of your files there or in subdirectories (subfolders). If there’s no ~
in the above, or there’s a /
following ~
, you’re in another directory.
Important: be aware that spaces are used to separate the words in the commands you type below.
To set up the SSH keys:
- If you aren’t in your home directory, return there by typing the command
cd <Enter>;
- Make the OpenSSH directory by typing the command
mkdir .ssh <Enter>
- Restrict the access mode of the OpenSSH directory by typing the command
chmod go-rwx .ssh <Enter>
- Change to the OpenSSH directory by typing the command
cd .ssh <Enter>
- Create your private and public keys in OpenSSH format by typing the command
ssh-keygen <Enter>
- When it asks you to
Enter file in which to save the key
, choose the defaultid_rsa
by pressing the key <Enter>; - When it asks you to
Enter passphrase
, don’t, just press the key <Enter>;
- When it asks you to
- To protect your private key from other Unix users, you should immediately change its permission mode by typing the command
chmod go-rwx id_rsa <Enter>
- Copy your public key to the authentication file by typing the command
cat id_rsa.pub >> authorized_keys <Enter>
.
Both of the two files authorized_keys
and id_rsa.pub
now contain your personal public key. The first is used when you log in to this computer from elsewhere, so it can authenticate you without a password; it can have multiple keys in it (in case you’ve set up more than one). The second is used when you are logging in to another computer from this one. It should always contain just one public key corresponding to the single private key in id_rsa
.
As discussed above, if you now log in to another computer with ssh
(e.g. if you log in from Romulus to Remus), you will be queried the first time as to whether you trust this new computer. If you say yes, its public key will be stored in a fourth file in the .ssh
directory named known_hosts
. You can save yourself some trouble by copying the prepared file below to your .ssh
directory, since it already has these keys set up for the Amherst College unix systems. Simply execute this command:
curl https://www.amherst.edu/system/files/known_hosts.gz | gunzip >> known_hosts <Enter>
Now that that your .ssh directory is set up on Unix, you can establish passwordless login capability on other Unix computers by copying this directory to them as a unit (note that this procedure will overwrite any preexisting SSH information):
- If you aren’t in your home directory, return there by typing the command
cd <Enter>
- Type the command
scp -r .ssh <remote host>: <Enter>
where<remote host>
is the name of the destination (prepend <username>@ if the username is different). Note the colon (:) on the end of the name, indicating a host rather than a file! - You will probably be asked again if you trust this computer, and for your password.
- To install this on your local computer, you’ll have to “pull” the .ssh directory rather than “push” it.
- Using Mac Terminal or Windows Git Bash, log out of the remote computer. Then type the command
scp -r <username>@<remote host>:.ssh ~ <Enter>
Then secure your private key(s):chmod go-r ~/.ssh/id_rsa ~ <Enter>
- Using Putty, open the associated program PuTTYgen (if not present, download it here) and follow these instructions to convert the unix-format RSA files.
- Using Mac Terminal or Windows Git Bash, log out of the remote computer. Then type the command