SSH Key Authentication for Absolute Beginners (in Plain English!)
Tags: ssh, beginners
Published: 2019-06-19 14:23:30

---
title: SSH Key Authentication for Absolute Beginners (in Plain English!)
published: true
description: 
tags: ssh, beginners
---
There are so many articles on SSH online, but when I was learning it felt like very few were beginner-friendly. My goals here are to provide you with a basic understanding of SSH, and enough information to create your SSH keys and connect to a server. I've tried to keep technical terms to a minimum and stick to the basics. 

# What exactly is SSH?
According to [Techopedia](https://searchsecurity.techtarget.com/definition/Secure-Shell):

> Secure Shell (SSH) is a cryptographic protocol and interface for executing network services, shell services and secure network communication with a remote computer. Secure Shell enables two remotely connected users to perform network communication and other services on top of an unsecured network.

But what is it really?
Basically, SSH is a way to connect your computer to different computers or services. There are a wide range of authentication methods ([source](https://www.secureblackbox.com/kb/articles/SSH-Authentication-methods.rst)), but usually, when people talk about connecting to something via SSH, they're referring to public key authentication.

Using SSH's public key authentication is like using a username and password to log in and connect to some service, but more convenient (no need to enter your credentials every time) and secure.
For example, if you register your credentials (called SSH keys) with a remote computer, you can access that computer from yours using the terminal. When you connect, you can use the terminal as if you're using the terminal in that remote computer, and execute the same commands (like `cd` or `ls`).

So what are SSH keys, and how do they work?

# What are SSH Keys?

SSH keys consist of a pair of keys, called a public and private key.
This [article](http://blakesmith.me/2010/02/08/understanding-public-key-private-key-concepts.html) has the most intuitive explanation on this topic that I've seen, so I highly recommend it.

> * Think of a public key as being the lock. It’s not actually a key, it’s a padlock you can make lots of copies of and distribute wherever you want. For example, if you want to put your ‘padlock’ on an ssh account on another machine, you would copy it to ‘authorized_keys’ in the ~/.ssh folder. You’ve setup the padlock.
> * Think of a private key as being the actual key. This is what you use to open the padlock that is stored on the other machine. Just like a regular key you keep it secret, safe, and out of the wrong hands.

__The most important takeaway here is: NEVER share your private key.
If you do, anyone can pretend to be you.__

One common usage of SSH is to connect to Github. Most people probably run into this situation when they're starting out. Until you add your SSH key to Github, you have to enter your username and password each time you want to push some code. But once you add your public key (the padlock) to Github, and have your private key (the key) registered in the [ssh-agent](https://www.ssh.com/ssh/agent) (basically a key manager that tries each of your keys one by one), you're authenticated automatically and no longer have to enter your credentials.
If you haven't done this yet, Github's [guide](https://help.github.com/en/articles/connecting-to-github-with-ssh) walks you through it.

How do the keys actually work? We won't go into details here, but I think this [article](https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server#how-do-ssh-keys-work) explains it well (the "client" is your computer and the "server" is the remote computer/service):

> When a client attempts to authenticate using SSH keys, the server can test the client on whether they are in possession of the private key. If the client can prove that it owns the private key, a shell session is spawned or the requested command is executed. 

# Generating your keys
Computers don't come with auto-generated keys; you have to make them using a command called `ssh-keygen`. For details, you can refer to Github's [guide](https://help.github.com/en/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key) that I mentioned earlier.

A few questions that come to mind regarding key generation:

* __Q. Do I need to `ssh-keygen` a different key pair for each server/service, or can I use the same keys everywhere?__
A. You can use the same keys. Having separate keys for separate destinations doesn't make it safer from an authentication perspective. ([source](https://security.stackexchange.com/a/40061))


* __Q. I have a multiple computers. Should I copy the keys from one device to another and share them, or generate new ones for each computer?__
A. Technically you can do either, but I recommend the latter approach, and it also seems to be the more common one ([source](https://unix.stackexchange.com/a/208498)). I have a work computer and a personal one, but they have different keys.
  * Sharing the same keys:
      - [Pro] More convenient because you only have to register one key for all your devices to access a service.
      - [Con] If one of your devices gets stolen and the key gets compromised, the keys for all your devices would be compromised.
  * Using different keys for each computer:
      - [Pros] Even if one of your devices gets stolen, you can simply delete that particular key from the list of authorized keys and your other devices would stay safe. Also, you can control which of your computers have access to what.
      - [Con] You have to manually register multiple SSH keys if you want multiple devices to be able to connect to a service.


* __Q. Where are my keys stored and how can I see them?__
A. If you've used the default settings, your keys are probably saved in `~/.ssh`. Try the first line of the commands below in your terminal and see if the result is a long string that starts with `ssh-rsa`. If so, that file, called `id_rsa.pub`, is your public key. Your private key should be saved in the same directory as `id_rsa`.

```bash
cat ~/.ssh/id_rsa.pub # public key
cat ~/.ssh/id_rsa # private key
```

# How to connect to a server via SSH
Once you've generated your SSH keys, you need to copy your _public_ key to the server(s) you want to access. This can be done with a command called `ssh-copy-id`, which looks like below. If you need more details, SSH's official [guide](https://www.ssh.com/ssh/copy-id) covers the specifics.

```
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server.address.com
```

Afterwards, if you want to access the remote server, you can do so with this  command from the terminal.

```
ssh user@server.address.com
```

For example, my company has a server. Let's say it's called `companyserver.com`. And my username is `risa`. Then, the command would look like this: `ssh risa@companyserver.com`

If you're connecting to that server for the first time, you will most likely see a prompt like `The authenticity of host 'companyserver.com' can't be established. ECDSA key fingerprint is <long string>. Are you sure you want to continue connecting (yes/no)?` Enter `yes` to continue connecting.

The default port for SSH is `22`. If you need to connect to a different port, you can do so by adding the `-p` option, like `-p 1234`.

# Copy files between your computer and remote server using `scp`
Let me tell you about a handy command that uses SSH. You may be familiar with the terminal's `cp` command, which lets you copy a file inside your computer and rename it.

```
cp original_folder/file_name new_folder/new_file_name
```

[`scp`](https://www.ssh.com/ssh/scp/) is a similar command that lets you do this to/from a remote server. In other words, it lets you upload and download files remotely.

```bash
scp file user@server.address.com:path # upload to remote server
scp user@server.address.com:file path # download from remote server
```

For example, if I wanted to upload a file to my company server, it would look like this:
`scp file_to_upload.txt risa@companyserver.com:`
If no path is specified after the colon, the file should be uploaded to the home directory with the same name. Do remember to include the colon though!
On the flip side, if I wanted to download a file from my company server, it should look like this:
`scp risa@companyserver.com:file_to_download.txt local_path`

Remember, the order is always `original_location` then `new_location`.

-----

Hopefully this post has served as a starting point for anyone learning about SSH. Thank you for reading!