There are many good reasons to do secure port forwarding through ssh. For example if you own two servers in different datacenters and you want to connect them to a single service which is less restricted when accessed locally (e.g. port 25 for SMTP) or you want to forward a service from a system behind a firewall (e.g. a web service on your home server).
Traditionally you would use autossh to manage permanent ssh connections. However through many hours of testing this has prooven unreliable in many ways. When connecting multiple times to the same server autossh by default uses the same ports for monitoring, which leads to the termination of at least one connection. There also were inexplicable cases when sshd remained running on the server, while the client was actually disconnected and could not restore the connection due to the broken process on the server. Even worse, autossh does not check if ssh has built up all forwardings successfully, leading to incomplete connections with partial port forwardings (e.g. if a port on the server is still in use by an other process).
Luckily openssh made autossh redundant because it already offers built-in monitoring. No additional monitoring ports are necessary anymore. However, there are quite a few options that you should know about in order to improve security and reliability of such a setup. This is the motivation behind this tutorial.
When you follow this guide, you can make otherwise protected services accessible to the public Internet (when using `ssh -R`). This might be an attack vector into your protected network.
When you don't set restrictions properly, an attacker might gain access to your server, either via direct shell access or through forwarding the port of your unprotected service (e.g. a database on localhost).
This allows any user to forward his local ports to an unprivileged public port on the server (`ssh -R`). You have to restrict this later on through the `permitlisten` variable in the `authorized_keys` file. The other two variables specify how often the server should send keep alive messages and how many missed messages from the client it will tolerate. The same has to be set on the client side, but there it can be done as a command line parameter.
First use the `ssh-keygen` command to create a private and public key pair on the client side. Don't type any password! Then use `cat ~/.ssh/id_rsa.pub` to display the content of your newly created public key. After that add a new line in the `authorized_keys` file on the server. Use the following line as an example. Your clients public key starts at `AAAA...` and this all needs to be in a single line per key.
*`permitlisten="localhost:9999"`: permit client to create a listening socket (via `ssh -R`) on port 9999 on the server, which forwards requests to a service on the client
*`permitopen="localhost:80"`: permit client to access (via `ssh -L`) port 80 port on server, which will then be offered as a local port on the client
You should run the client side ssh command in a loop because it is tuned to terminate as soon as errors are detected. Don't worry, this is well tested. If you are old school you simply put this into `/etc/rc.local`:
```
#!/bin/bash
(while true; do
ssh ...
sleep 30
done) &
disown
exit 0
```
Don't forget to mark the script as executable: `chmod +x /etc/rc.local`
*`-4` (not shown above) is optional to foce ssh to use IPv4 only (in case of problems with IPv6)
*`-L` (can be repeated multiple times)
*`-R` (can be repeated multiple times)
Please beware that the hostname part in the `-L` and `-R` options must be spelled exactly the same as in the `permitlisten` and `permitopen` variables on the server ("Localhost", "localhost" and "127.0.0.1" are treated different).
