completes the sshd doc

modules/qualifying/learning_ssh.md

@@ -403,13 +403,38 @@ This might look a bit intimidating but I'll break down the command line options
 * `--ssh-cmd -i student` is needed to specify our specific private key (not needed if you use `~/.ssh/id_rsa.pub`)
 * `-D` will daemonize the VPN so you can continue to use the shell
 
+A more basic way of creating a VPN over ssh, if you use your main `~/.ssh/id_rsa` file is identity, would be as follows.
+You can't execute this command because your public key is not present on this server but it's to give you a more bare bones idea of a valid sshuttle.
+Note that here I connect not to the standard port 22 but to a custom port 4040.
+This command won't daemonize so you would need to open a second terminal to execute other commands.
+
+```
+➜  ~ git:(master) ✗ sshuttle -r pi@home.86thumbs.net:4040 -x home.86thumbs.net 0.0.0.0/0       
+```
+
+**Can you explain me why you need you're prompted for your `sudo` password?**
+
 ## 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.
+I highly recommend to read through the `man sshd_config` pages for a detailed explanation of all possible settings.
+The Debian configuration is quite secure but we can improve it a bit.
+Below are some standard security improvements you'll find on lot's of servers.
 
-### Version
+**A word of caution.**
+You can lock yourself out of your server!
+Try out some options now on your virtual machines so you get a firm understanding of what they all do.
+If you lock yourself out of a remote server you'll have to either gain physical access or reboot the VPS in rescue mode.
+For OVH, the VPS provider I tend to use, the rescue mode is detailed [here](https://support.us.ovhcloud.com/hc/en-us/articles/360010553920-How-to-Recover-Your-VPS-in-Rescue-Mode).
+With other providers it will be different but similar.
+
+### Some classic security enhancements
+
+There are more options available but these are some of the most used one.
+
+#### 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.
@@ -426,7 +451,135 @@ Protocol
        “2,1” is identical to “1,2”.
 ```
 
-### Some classic security enhancements
+#### Root login
+
+Most systems we install, and the ones you'll deploy later, perform system management via `sudo` so there is no point in even allowing the `root` user to log in.
+We can deny any attempt to log in as root with the following option.
+I would advise to always set this option to no.
+
+```
+PermitRootLogin
+		Specifies whether root can log in using ssh(1).  The argument must be yes, prohibit-password,
+        forced-commands-only, or no.  The default is prohibit-password.
+
+        If this option is set to prohibit-password (or its deprecated alias, without-password), password and key‐
+        board-interactive authentication are disabled for root.
+
+        If this option is set to forced-commands-only, root login with public key authentication will be allowed,
+        but only if the command option has been specified (which may be useful for taking remote backups even if
+        root login is normally not allowed).  All other authentication methods are disabled for root.
+
+        If this option is set to no, root is not allowed to log in.
+```
+
+#### Key only login
+
+Once you properly understand how to do key based login it's wise to disable password login all together for internet facing servers.
+This protects you for [bruteforce](https://en.wikipedia.org/wiki/Brute-force_attack) attacks and script kiddies.
+On a LAN you can get away with leaving them but I would still advise to keep it key only as we'll later see how an attacker can forward your ssh server to an off-site remote server.
+Here I would put no to override the default.
+
+```
+PasswordAuthentication
+		Specifies whether password authentication is allowed.  The default is yes.
+
+```
+
+#### Allow only specific users and groups
+
+On systems with lot's of users and groups it might be wise to only permit certain groups and/or users.
+Messing with this setting is a common way of locking oneself out of a server so think before you restart sshd.
+It's worth noting that upon a restart of your sshd service, your active connection is **not** interrupted so keep it upen en try a login in a different terminal.
+If you would happen to have locked yourself out you can still use the previous connection to rectify the problem.
+For VPS servers I often create a group `ssh_allowed` and add myself and other administrators to this group.
+Then I set the `AllowGroups ssh_allowed` to block all users not in that group from connecting to the server.
+I often use the `AllowUsers` setting together with `Match` blocks to allow TCP forwarding for one special user but more on that later.
+
+```
+AllowGroups
+        This keyword can be followed by a list of group name patterns, separated by spaces.  If specified, login
+        is allowed only for users whose primary group or supplementary group list matches one of the patterns.
+        Only group names are valid; a numerical group ID is not recognized.  By default, login is allowed for all
+        groups.  The allow/deny directives are processed in the following order: DenyUsers, AllowUsers,
+        DenyGroups, and finally AllowGroups.
+
+        See PATTERNS in ssh_config(5) for more information on patterns.
+
+AllowUsers
+        This keyword can be followed by a list of user name patterns, separated by spaces.  If specified, login
+        is allowed only for user names that match one of the patterns.  Only user names are valid; a numerical
+        user ID is not recognized.  By default, login is allowed for all users.  If the pattern takes the form
+        USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particu‐
+        lar hosts.  HOST criteria may additionally contain addresses to match in CIDR address/masklen format.
+        The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and
+        finally AllowGroups.
+
+        See PATTERNS in ssh_config(5) for more information on patterns.
+```
+
+#### Forwarding
+
+Unless you need, and we'll need it later, port forwarding it's best to set the `DisableForwarding` option to yes.
+It is be a bit of an extreme measure but fully understandable.
+Why enable it if you don't need it?
+
+```
+DisableForwarding
+        Disables all forwarding features, including X11, ssh-agent(1), TCP and StreamLocal.  This option over‐
+        rides all other forwarding-related options and may simplify restricted configurations.
+```
+
+#### Multiple network interfaces
+
+If you have multiple network interfaces such as an ethernet and a wireless interface you can restrict the server to only listen on one of them.
+I rarely use this option but it's good to know it exists.
+Do note that similar behavior can be achieved with `iptables`.
+
+```
+ListenAddress
+        Specifies the local addresses sshd(8) should listen on.  The following forms may be used:
+
+              ListenAddress hostname|address [rdomain domain]
+              ListenAddress hostname:port [rdomain domain]
+              ListenAddress IPv4_address:port [rdomain domain]
+              ListenAddress [hostname|address]:port [rdomain domain]
+
+        The optional rdomain qualifier requests sshd(8) listen in an explicit routing domain.  If port is not
+        specified, sshd will listen on the address and all Port options specified.  The default is to listen on
+        all local addresses on the current default routing domain.  Multiple ListenAddress options are permitted.
+        For more information on routing domains, see rdomain(4).
+```
+
+#### Maximum of authentication tries
+
+You can limit the amount of tries a user has before the connection is canceled by the server but **watch out with this one**.
+It acts differently from how you think it does!
+When a user presents himself to the server, every key in their `~/.ssh/` is presented one by one to the server and each key is a try.
+So if you set this value too low you might lock yourself out in the future without realizing why.
+Imagine you only have one key, then everything is fine with a low value but if later down the line you create more keys this could become a problem and I guarantee you it will take you a while to figure it out.
+
+```
+MaxAuthTries
+        Specifies the maximum number of authentication attempts permitted per connection.  Once the number of
+        failures reaches half this value, additional failures are logged.  The default is 6.
+```
+
+Have a look at [this](https://unix.stackexchange.com/questions/418582/in-sshd-config-maxauthtries-limits-the-number-of-auth-failures-per-connection) for a more detailed explanation of **what** counts as a **try**.
+
+### Some *fun* stuff
+
+You can set banner and motd (message of the day) files that will be shown to the user upon login.
+This is what bandit uses to draw their ASCII banner when you log in.
+
+```
+Banner
+		The contents of the specified file are sent to the remote user before authentication is allowed.  If the
+        argument is none then no banner is displayed.  By default, no banner is displayed.
+
+PrintMotd
+        Specifies whether sshd(8) should print /etc/motd when a user logs in interactively.  (On some systems it
+        is also printed by the shell, /etc/profile, or equivalent.)  The default is yes.
+```
 
 ### Tunneling and X forward