adds reverse forwarding

modules/qualifying/learning_ssh.md

@@ -256,7 +256,7 @@ 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/).
+It's a **two part** process that 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/).
 
 ## Standard usage
 
@@ -292,7 +292,7 @@ As an example I would like to add a shortcut to my matrix server.
 ssh: Could not resolve hostname matrixserver: No address associated with hostname
 ```
 
-To create the shortcut I append the following to my `~/.ssh/config` file.
+To create the shortcut I append the following to my `~/.ssh/config` file or create it if it doesn't exist.
 
 ```
 Host matrixserver
@@ -372,13 +372,13 @@ You can even add these mounts to your `/etc/fstab` file!
 ## SSHuttle
 
 SSHFS gives us a poor man's NFS and SSHuttle a poor man's VPN.
-Again, this is very handy additional program to install on your ssh **client** which requires no modifications to the ssh **server** you're connection to.
+Again, this is very handy additional program to install on your ssh **client** which requires no modifications to the ssh **server** you're connecting to.
 You install it with trusty old `apt`, `sudo apt install sshuttle`.
 
 Now, what does it do?
 It creates a connection to a **remote** ssh server and adds **local** iptable rules to send all (or some) traffic via that remote server onto the internet.
 In practice it behaves as a VPN.
-To test this out I added an for you to one of my remote servers.
+To test this out I added an account for you to one of my remote servers.
 Use the private key I'll give you in class to authenticate yourself as student@sproutsin.space.
 The syntax is as follows.
 
@@ -400,7 +400,7 @@ This might look a bit intimidating but I'll break down the command line options
 * `-r student@sproutsin.space` is the remote host you want to send your traffic to
 * `-x sproutsin.space` is needed to exclude traffic to *that* specific host (the connection would fail otherwise)
 * `0.0.0.0/0` is the IP range you want to send through the VPN, in this case it's everything
-* `--ssh-cmd -i student` is needed to specify our specific private key (not needed if you use `~/.ssh/id_rsa.pub`)
+* `--ssh-cmd 'ssh -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.
@@ -460,7 +460,7 @@ 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.
+		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.
@@ -489,7 +489,7 @@ PasswordAuthentication
 
 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.
+It's worth noting that upon a restart of your sshd service, your active connection is **not** interrupted so keep it open and try a login from 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.
@@ -581,9 +581,61 @@ PrintMotd
         is also printed by the shell, /etc/profile, or equivalent.)  The default is yes.
 ```
 
-### Tunneling and X forward
+### Forwarding
 
-## Tunnels
+Port forwarding is one of **the** most powerful features of ssh and is a blessing and a curse at the same time.
+It gives us, legitimate administrators an excellent tool to work with but it can be used for very malicious purposes.
+A lot of [backdoors](https://en.wikipedia.org/wiki/Backdoor_(computing)) are made with the help of ssh reverse forwarding which we'll see now.
+
+#### Reverse forwarding
+
+Reverse forwarding is an easy way to push a hole in a firewall.
+Most networks are heavily limited for **incoming** connections but it's quite rare to have serious outgoing limitations.
+As a reverse forwarding connection is **initiated** by the client **inside** the network, most firewall will let it go though.
+The client will then forward a port on the **external** ssh server back to a host and port **inside** the network.
+You have to remember that TCP connections are **bi-directional** so it's a way back into the network for outside.
+Take the following diagram as an example.
+
+![reverse ssh](./assets/ssh_reverse_forwarding.png)
+
+1. bad client `192.168.0.66` connects to an outside ssh server
+2. port `9999` on the external server will feed back into the firewalled network
+3. the external server has an `nginx reverse proxy` running for domain `exploit.sproutsin.space` that forwards to `http://localhost:9999`
+3. on the bad client all traffic coming over port `9999` will be sent to the good guy server `192.168.0.44:8888`
+4. a third party can now access the internal website by going to `exploit.sproutsin.space` 
+
+**Let's try this out!**
+
+The documentation of `man ssh` is a bit cryptic but I'm leaving it here for reference purposes.
+
+```
+-R [bind_address:]port:host:hostport
+-R [bind_address:]port:local_socket
+-R remote_socket:host:hostport
+-R remote_socket:local_socket
+-R [bind_address:]port
+        Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be
+        forwarded to the local side.
+
+        This works by allocating a socket to listen to either a TCP port or to a Unix socket on the remote side.
+        Whenever a connection is made to this port or Unix socket, the connection is forwarded over the secure
+        channel, and a connection is made from the local machine to either an explicit destination specified by
+        host port hostport, or local_socket, or, if no explicit destination was specified, ssh will act as a
+        SOCKS 4/5 proxy and forward connections to the destinations requested by the remote SOCKS client.
+
+        Port forwardings can also be specified in the configuration file.  Privileged ports can be forwarded only
+        when logging in as root on the remote machine.  IPv6 addresses can be specified by enclosing the address
+        in square brackets.
+
+        By default, TCP listening sockets on the server will be bound to the loopback interface only.  This may
+        be overridden by specifying a bind_address.  An empty bind_address, or the address ‘*’, indicates that
+        the remote socket should listen on all interfaces.  Specifying a remote bind_address will only succeed if
+        the server's GatewayPorts option is enabled (see sshd_config(5)).
+
+        If the port argument is ‘0’, the listen port will be dynamically allocated on the server and reported to
+        the client at run time.  When used together with -O forward the allocated port will be printed to the
+        standard output.
+```
 
 ## Autossh