linux_course_doc/modules/qualifying/learning_ssh.md

# Pushing SSH a bit further

## What is SSH

### Origins

SSH is *the* current standard for remote logins but you might want to read up a bit on what was used before SSH existed.
[This](https://www.jeffgeerling.com/blog/brief-history-ssh-and-remote-access) is a pretty good blog post on the history of SSH.
You should never use the following the following programs anymore but it's good to be aware of their historic existance.

* rlogin
* rsh
* rcp
* telnet (still has some legitimate usage such as with munin)

The main advantage of SSH is it's encryption.
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.
It's not mandatory to fully understand the math behind encryption to use it though.
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!

![key pairs](./assets/key_encryption.png)

### Generating keys

### Deploying keys

## Standard usage

## Tweaking the sshd configuration file

All server configuration is done in the `/etc/ssh/sshd_config` file.
Starting version TO_CHECK you can use the modern `/etc/ssh/sshd_config.d/` folder system to override default system configuration.
This way any changes to the standard configuration made by the package maintainers won't mess with your custom preferences and tweaks.

### Version

A modern sshd configuration will only allow version 2 but you can check or specify this in the configuration file.
You'll probably never have to set this yourself but do keep it in mind when you're confronted with old installations.

```
Protocol
             Specifies the protocol versions sshd(8) supports.  The possible values are ‘1’ and
             ‘2’.  Multiple versions must be comma-separated.  The default is ‘2’.  Protocol 1
             suffers from a number of cryptographic weaknesses and should not be used.  It is
             only offered to support legacy devices.

             Note that the order of the protocol list does not indicate preference, because the
             client selects among multiple protocol versions offered by the server.  Specifying
             “2,1” is identical to “1,2”.
```

## Tunnels

## SFTP

## SSHFS

## SSHuttle