From 3e3d031abb684f4f529719eeb14e3ada6ff20a0c Mon Sep 17 00:00:00 2001 From: waldek Date: Tue, 13 Jul 2021 23:59:17 +0200 Subject: [PATCH] adds bridgy info --- modules/qualifying/assets/index.html | 5 ++++ modules/qualifying/learning_ssh.md | 41 ++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 modules/qualifying/assets/index.html 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 +