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
*`*` allows access from everywhere (e.g. from the Internet, if your firewall allows that) if `GatewayPorts clientspecified` is set in `/etc/ssh/sshd_config`
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`
*`-g` (not used here) does the same as `[bind_address:]` set to `*:` (with -L the client offers the port publicly; with -R the server offers the port publicly)
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).
In this example we forward a http based service running on the client (port 80) to the server (port 2280). The server can than deliver the service via its own webserver. Port 2280 on the server is only available locally.\
Additionally the client accesses the remote mail server (port 25) and provides local access for applications running on the client (through port 2225). That way an application on the client can send mail via the remote server. It is not necessary to to open the remote mail relay to the internet. Requests to port 2225 on the client are treated as if they were done locally on the server.\
The last forwarding coud be used to publicly offer a service runninging on the client (port 9999) via the server (port 8080). Port 8080 on the server can be accessed by everyone on the internet and will be forwarded to port 9999 on the client.
Before running the script, test the command manually. This is also important if you were not connected to this server before from your client. On your first connection you have to accept the server key!
