waldek
/
linux_course_doc
1
0
Fork 0
Code Issues 2 Pull Requests Projects Releases Wiki Activity

adds bridgy info

This commit is contained in:
waldek 2021-07-13 23:59:17 +02:00
parent d367c46d98
commit 3e3d031abb
2 changed files with 46 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
modules/qualifying/assets/index.html Normal file
View File

@ -0,0 +1,5 @@
<html>
<body>
<h1>look at me! I am a website</h1>
</body>
</html>

41
modules/qualifying/learning_ssh.md
View File

@ -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