It works similarly to SSL which you use all the time to do most of your web browsing.
When using encryption it becomes **very** hard to sniff the data traveling between the client and the server.
There are two versions of SSH, version 1 and version 2, and you should only use version 2 as the former is not considered [secure]() anymore.
The recommended encryption used by most SSH servers is [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard).
If you're interested in understanding the mathematics behind AES, [this](https://www.youtube.com/channel/UC1usFRN4LCMcfIV7UjHNuQg) class is exceptionally good but not for the faint of heart.
The main takeaway would be the number of **bit's used** where **higher** is **better**.
By default ssh uses a very secure cipher but you can specify which one you want with the `-c` flag to `ssh`.
Do keep in mind that the server needs to support the cipher you're requesting.
## SSH keys
SSH encryption and SSH keys are not the same thing.
**Keys** are used for **authentication** with a server.
Once the client is authenticated and granted access to the server, the encryption is set to **encrypt** the **traffic** from client to server and visa versa.
SSH keys are [asymmetric](https://en.wikipedia.org/wiki/Public-key_cryptography) key pairs where you have two simple text files.
One with the **private** part, which is used for **decrypting**, and one **public** part which is used for **encrypting**.
Both parts together form one **key pair**.
If you're interested in the maths behind key pairs, have a look at this 15min [video](https://www.youtube.com/watch?v=4zahvcJ9glg&t=1s), it's a lot easier than you expect!
Keys are by default stored in `~/.ssh/` and named `id_rsa` for the **private** part, and `id_rsa.pud` for the **public** part.
**Important**, each generated key is **unique** so if you overwrite a key you made previously that old key is **gone!**.
There is **no way** to recover that old key anymore, gone is gone.
I highly advise you to keep backup's of your important keys, preferably in multiple locations.
GNOME [Seahorse](https://wiki.gnome.org/Apps/Seahorse/) or [keepass2](https://keepass.info/) are good password managers you can use to store both passwords and key pairs.
An ssh key can be generated by running the `ssh-keygen` command.
You'll be prompted with a dialog that will ask to name and where to save the key pair, plus whether you want a password for that key or not.
For automated logins you should not set a password as it would defeat the purpose but you **must** realise that everyone that has access to the **private** key will be able to log in to each server the key is deployed to.
Keeping this file safe becomes very important.
**Remember the bandit SSH key level?**
```
➜ ~ git:(master) ✗ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/waldek/.ssh/id_rsa): my_ssh_key
The connection will try any form of authentication allowed by the server in order of most secure to least secure.
Publickeys are considered more secure than passwords so it will try that first.
You can see this at the following line `debug1: Will attempt key: /home/waldek/.ssh/id_rsa RSA SHA256:tOuvE+Qq1B/eXyGcyIfs0MVXaaSI/GNYjLqO3D+Tz+k`.
The `student` account does not have the matching public key as an authorized key so the client tries a password login next `debug1: Next authentication method: password`.
On the server side the sshd process will look for a matching **public** key in the users home directory.
By default it will try every line in the `~/.ssh/authorized_keys` file for authentication.
If a match is found, you'll be granted access, if not it will try an other authentication method until every method allowed by the server is exhausted and you'll be denied access.
The verbose output of a successful login with a key pair can be seen below.
So, how did I add my public key to the `student`'s account authorized keys?
There is a program called `ssh-copy-id` that can do it for you, but I personally always just copy and paste it to the users `~/.ssh/authorized_keys` file.
This is an example of a server I use with the public keys that are allowed to log in.
As you can see there are **four** key's that are allowed to log in.
### Keys for gitea
Now that you know how to **create** your own RSA keys I would like you to:
* create one (and save it somewhere safe)
* use it to push/pull from your personal [gitea](https://gitea.86thumbs.net)
I'll let you figure it out by yourself but if you're stuck have a look at [this](https://gitea.86thumbs.net/user/settings/keys) and [this](https://pandammonium.org/how-to-change-a-git-repository-from-https-to-ssh/).
We've done quite a bit of SFTP before so we won't go into detail here but if you forgot, go have a look at the networking exercises in the resources directory.
I'm mentioning it because it's crucial to remember it's existence in order to understand the next topic, sshfs.
## SSHFS
Thanks to the sftp subsystem of ssh we can use it to copy files form one system to an other.
Some clever guy's used it to build [sshfs]() which mounts a remote folder into our system so we can use it like a network share.
It's a poor mans NFS that can be a true lifesaver.
You'll have to install it onto the client where you want to mount the folder to.
This can be done as follows, `sudo apt install sshfs`.
The server just needs a running sshd process with the internal-sftp subsystem configured but most, if not all, default ssh servers have this.
