diff --git a/modules/qualifying/assets/index.html b/modules/qualifying/assets/index.html
new file mode 100644
index 0000000..a97214d
--- /dev/null
+++ b/modules/qualifying/assets/index.html
@@ -0,0 +1,5 @@
+
+
+ look at me! I am a website
+
+
diff --git a/modules/qualifying/learning_ssh.md b/modules/qualifying/learning_ssh.md
index 0ce9df0..548857c 100644
--- a/modules/qualifying/learning_ssh.md
+++ b/modules/qualifying/learning_ssh.md
@@ -644,5 +644,46 @@ This is both good and bad, you'll be able to pinpoint who is responsible inside
**Let's expose an internal ssh server to the web!**
+The quick ones amongst you might have noticed the reverse ssh tunnel opens a shell on the remote ssh server.
+This can be dangerous from the remote server point of view, and annoying from the client's point of view.
+Let's fix the client's problem first.
+There are two arguments to the `ssh` client that can be very handy when creating reverse ssh tunnels.
+
+* `-N` won't open a shell on the remote server
+* `-f` will send the connection to the background so you can still use the same terminal to do other things
+
+Both options can be combined to construct the following command.
+Do note that the tunnel will close when you close the terminal used to create it in (remember backgound processes!).
+
+```
+ssh -Nf -R 9999:192.168.0.44:8888 waldek@sproutsin.space
+```
+
+The remote server issue is a bit more problematic but there is an easy fix.
+The way I resolve it is by adding a dedicated reverse ssh user account on the remote server with a dedicated ssh key pair.
+Let's call this one `bridgy`.
+In the `~/.ssh/authorized_keys` I add the dedicated public key
+I copy the **private** key to the `bridgy` account to all the clients I want initiate tunnels from.
+Up until now nothing is different compared to our starting point, it's even worse from a security point of view, but the solution is both magical and simple.
+Every client that has the private key to the `bridgy` account can now connect to the server and get's a shell but we have control over *which* shell they get serverside.
+If we change the default shell of `bridgy` to `/bin/false` they will never get a shell but the tunnel will still work!
+So in short:
+
+1. add a dedicated user account on the server
+2. deploy ssh keys
+3. set the user's login shell to `/bin/false`
+
+You can further control this one specific user with `Match` blocks in the `sshd_config` file of the server in case you want to.
+
+#### Local forwarding
+
+TODO
+
+#### X forwarding
+
+TODO
+
## Autossh
+TODO
+