# Set up SSH keys

As a member of the Data Team, you’re going to need to use SSH keys for multiple reasons. Most importantly, you should have one personal key pair.

If you don’t know what the hell SSH keys or you kind of know but you always have a headache, you have two options on how to deal with this:

- You follow the instructions here like a robot, and talk with Pablo whenever something is not working as expected.
- You consume these wonderful materials, finally understand what the hell an SSH key is and how it works, and you use these instructions as a guide, but you know what the hell is going on so you have some chance at dealing with issues (of course, you can still talk with Pablo when something doesn’t work)
    - https://www.youtube.com/watch?v=dPAw4opzN9g (How keys work)
    - https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys (How keys work and practical info)

## Creating your key pair

- You will need to have a Linux terminal available. If you still don’t have WSL working on your laptop, get this done first: [How to set up WSL and Docker Desktop](How%20to%20set%20up%20WSL%20and%20Docker%20Desktop%204771651ae49a455dac98d7071abcd66d.md)
- You should also have Keeper ready. But that’s fine because it’s very first thing you did when you joined the company, right even before learning how the coffee machine works… right?
    - Just in case, a reminder on onboarding: [Onboarding checklist](Onboarding%20checklist%20d5eb8cb36b404fc9a0ccacddf9862001.md)
- Open up an Ubuntu terminal
- Run `ssh-keygen -t rsa -b 4096`  (note: DevOps only accepts RSA keys, not modern EC ones. Nasty, nasty microsoft)
    - You will get ask where do you want to store the key and how do you want to name it. Up to you. I advise you to store them in `home/<your-user>/.ssh/`. Feel free to use any name.
    - You will be asked to add a passphrase. This is highly recommended. Make sure you note the passphrase, there’s absolutely no way to recover this.
- This will have created two files
    - One with the name you provided (your private key)
    - Another with the same name, but an additional `.pub` at the end (the matching public key. These two match together. That’s why it’s a *key pair*).
    - Now make an entry in Keeper, private to you, to store these. You should store the passphrase in some text field, and the two key files (private and public) **as attachments.** Don’t store them as text, high chances of mistakes doing that.
- Finally, change the permissions on your private key by traveling with the terminal to `~/.ssh/` and running `chmod 400 <the-name-of-your-private-key-file>`.

## Adding your keys to Azure Devops

There are two steps to set up SSH access to Azure Devops: placing your public key and configuring your ssh client to use your private key.

To place your public key:

- Go to https://guardhog.visualstudio.com/.
- Go to `User Settings`. It’s the little icon of a person with a gear on the top right.
- Click on `SSH Public Keys`
- In the new page, add a new key.
    - You can give it any name.
    - The `Public Key Data` should hold the public key. To fill it in, run `cat ~/.ssh/<your-public-key-that-ends-in-.pub>`, copy the output and paste it here.
- That should be it. You should now see the public key listed.

To configure your ssh client:

- Create (or edit if it already exists) the file in `~/.ssh/config`
- Add a block like this:
    
    ```bash
    Host ssh.dev.azure.com
        Hostname ssh.dev.azure.com
        IdentityFile ~/.ssh/<your-private-key-file>
    ```
    
- That’s it. Your SSH client will now know which key to use when interacting with Devops.

Finally, be aware you might experience some buggy behaviour with the URL paths provided by Devops when cloning Git repositories with SSH. **Do not fall back to HTTP just because it’s giving you a headache.** The problem is probably easily fixable, you can read more here: [Little Git SSH cloning trick](Little%20Git%20SSH%20cloning%20trick%203d33758de34742b9ac180fd9c7b5e6b3.md) 

## Using SSH to access production VMs

Some of the machines in production are accessible through SSH.

If you need to log in there, depending on the circumstances, either we should add your public key to the right machine, or you should receive access to some of the service SSH keys that exist in the team.

If you need this, contact Pablo to discuss and he will sort things out for you.