Shell and DoC Systems

In general (as in, for other organisations and institutions) you can SSH from one machine to another provided you have a valid login for the remote machine you’re trying to access. However, this can pose some security issues, and so at Imperial you need to set up SSH keys (yes, the very same as for git from earlier) to use for validation when accessing DoC machines from outside the college network.

So, we need to set up SSH authentication on your personal device.

This is pretty straightforward, and nowhere near as complicated as that probably made it sound.

Setting Up Keys On Your Device

If your machine runs MacOS, Linux, Windows 10 (updated since October 2018), or Windows 11, this is actually exactly the same as we described for git earlier.

In MacOS and Linux systems, simply open a terminal. In Windows, open the Command Prompt or PowerShell (the Windows system terminal equivalents). Alternatively, on Windows, you can install the Windows Subsystem for Linux (WSL), which will give you access to a Linux virtual machine within your Windows OS (in which case, you can simply continue as if on a Linux machine).

Then we type the same command as before (we can omit the -C flag and argument):

ssh-keygen -t rsa

We follow the same procedure, accepting default filepaths for the keys, and entering a passphrase.

What Is a Key?

Without getting into the details of encryption (we have cryptography and network courses for that!), a key pair, as created by ssh-keygen, has a “private key” and a “public key”. At a very basic level, this kind of encryption involves posing mathematical problems that are easy to create using the private key, and easy to verify if you have the public key, but otherwise very difficult to solve (as in, “on average takes longer than the lifetime of the Universe to solve” kinda difficult).

The private key is the actually secret part. Don’t share this file or its contents. It is essentially your password.

The public key (that’s the contents of the file ending in .pub) can happily be public. Post it on a billboard, if you want. Its function is to verify data encrypted using the private key. It can’t be used to compromise your login by itself (well, not unless you solve one of those “lifetime of the Universe” problems mentioned above, so we’re probably safe for now).

So, now that we have this basic idea, what do we do with them?

What To Do With Your Keys

So, your private key (id_rsa, no extension), is created on your device, and should stay there. You can use your key to access a remote system by giving that system your public key, and essentially telling them “if you meet someone who knows the secret this key unlocks, it’s me!”.

That means you need to get your public key onto the department computers.

Easiest way?

Email it to yourself.

To get the key, you can cat its contents in the terminal and then copy it into an email (this can be better than trying to attach the file, as sometimes email clients get a bit funny about files without a recognisable extension):

cat ~/.ssh/id_rsa.pub

(Don’t forget to include the parts at the beginning and end.)

Email it yourself (this will be from your personal machine). Open the email on a lab machine, and Right-Click-copy the contents (just like our primary school teachers taught us).

Then, using your favourite text editor, open a file at ~/.ssh/authorized_keys (it may already exist, which is fine, just add your public key to the bottom), and paste your key into that file (all on one line). The file must have this exact name, no changes in spelling or capitalisation.

nano ~/.ssh/authorized_keys

And that’s it! You’re all set. Now let’s talk about how to actually SSH into the department…