jnovack / autossh

Heavily customizable AutoSSH Docker container

autossh

Highly customizable AutoSSH docker container.

Overview

jnovack/autossh is a small lightweight (~15MB) image that attempts to provide a secure way to establish an SSH Tunnel without including your keys in the image itself or linking to the host.

There are thousands of autossh docker containers, why use this one? I hope you find it easier to use. It is smaller, more customizable, an automated build, easy to use, and I hope you learn something. I tried to follow standards and established conventions where I could to make it easier to understand and copy and paste lines from this project to others to grow your knowledge!

Description

autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic.

Before we begin, I want to define some terms.

• local - THIS docker container.

• target - The endpoint and ultimate destination of the tunnel.

• remote - The 'middle-man', or proxy server you are tunnelling through to get to your target.

• source - The initial endpoint you are starting from that does not have access to the target endpoint, but does have access to the remote endpoint.

The local machine is USUALLY the same as the target but since we are using Docker, we have to abstract out the local container from the target endpoint where we want autossh to land. Normally, this is where autossh is usually run from.

Typically, the target can be on a Home LAN segment without a publicly addressible IP address; whereas the remote machine has an address that is reachable by both target and source. And source can only reach remote.

target ---> |firewall| >--- remote ---< |firewall| <--- source
10.1.1.101               203.0.113.10            192.168.1.101

The target (running autossh) connects up to the remote server and keeps a tunnel alive so that source can proxy through remote and reach resources on target. Think of it as "long distance port-forwarding".

Example

You are running docker on target, your home computer. (Note: Linux Docker hosts automatically create a docker0 interface with 172.17.0.1 so the containers can route to the host and out to other networks. A container that starts up could have the IP address 172.17.0.2, for our example.) You have a Virtual Private Server (VPS) on the Internet that is accessible to all. This local docker container will make a connection to the remote VPS and tunnel remote port 2222 to target port 22. Any connection to remote port 2222 will actually be to the target server on port 22. This is known as a "reverse tunnel".

      TARGET_PORT                  REMOTE_PORT    TUNNEL_PORT
 target <--------------- local ------------> remote <--------------- source
 10.1.1.101           172.17.0.2          203.0.113.10        192.168.1.101

The LOCAL (172.17.0.2) device connects to the REMOTE (203.0.113.10) REMOTE_PORT (:22) to create the tunnel on REMOTE (203.0.113.10) TUNNEL_PORT (:11111).

The SOURCE (192.168.1.101) connects to the REMOTE (203.0.113.10) TUNNEL_PORT (:11111) to get to the TARGET (10.1.1.101) TARGET_PORT (:22).

By default, SSH server applications (such as OpenSSH, Dropbear, etc), only permit connections to forwarded ports from the loopback interface (127.0.0.1).

This means, you must be authenticated and connected the remote and use it as a "jump point" (for a lack of a better term) before proceeding to connect to the tunnel.

In the example above, from the source, you first have to open an SSH connection to the remote (203.0.113.10), then you can continue to connect to the target (10.1.1.101) by connecting to 127.0.0.1:TUNNEL_PORT. It is a two-step process.

To make this a one-step process (connecting from source to target via remote), you must make some security changes on the remote (not-advised). Please see the SSH_BIND_IP section below.

Disclaimer

By tunneling remote port 2222 to target port 22, you may be exposing a home server (and by extension, your home network) to the Internet at large, commonly known as "a bad thing(TM)". Be sure to use appropriately use firewalls, fail2ban scripts, non-root access, key-based authentication only, and other security measures as necessary.

Setup

To start, you will need to generate an SSH key on the Docker host. This will ensure the key for the container is separate from your normal user key in the event there is ever a need to revoke one or the other.

$ ssh-keygen -t rsa -b 4096 -C "autossh" -f autossh_id_rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jnovack/autossh_id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jnovack/autossh_id_rsa.
Your public key has been saved in /home/jnovack/autossh_id_rsa.pub.
The key fingerprint is:
00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff autossh
The key's randomart image is:
+-----[ RSA 4096]-----+
|     _.-'''''-._     |
|   .'  _     _  '.   |
|  /   (_)   (_)   \  |
| |  ,           ,  | |
| |  \`.       .`/  | |
|  \  '.`'""'"`.'  /  |
|   '.  `'---'`  .'   |
|     '-._____.-'     |
+---------------------+

Command-line Options

What would a docker container be without customization? I have an extensive list of environment variables that can be set.

Environment Variables

All the envrionment variables are prefaced with SSH_ NOT because you are required to tunnel SSH, but for ease of grouping. The only SSH connection that is required is from the LOCAL device to the REMOTE server. However, if you are interested in tunneling other protocols securely (e.g. mysql, redis, mongodb) across networks with certificates, you may wish to consider my other project ambassador.

SSH_REMOTE_USER

Specify the usename on the remote endpoint. (Default: root)

SSH_REMOTE_HOST

Specify the address (ip preferred) of the remote endpoint. (Default: localhost)

SSH_REMOTE_PORT

Specify the ssh port the remote endpoint to connect. (Default: 22)

SSH_TUNNEL_PORT

Specify the port number on the remote endpoint which will serve as the tunnel entrance. (Default: random > 32768) If you do not want a new port every time you restart jnovack/autossh you may wish to explicitly set this.

This option reverses if you set SSH_MODE (see below).

SSH_TARGET_HOST

Specify the address (ip preferred) of the target.

SSH_TARGET_PORT

Specify the port number on the target endpoint which will serve as the tunnel exit, or destination service. Typically this is ssh (port: 22), however, you can tunnel other services such as redis (port: 6379), elasticsearch (port: 9200) or good old http (port: 80) and https (port: 443).

If you are interested in tunneling other protocols securely (e.g. mysql, redis, mongodb) across networks via certificates you may wish to consider my other project ambassador.

SSH_STRICT_HOST_IP_CHECK

Set to false if you want the IP addresses of hosts to not be checked if the known_hosts file is provided. This can help avoid issues for hosts with dynamic IP addresses, but removes some additional protection against DNS spoofing attacks. Host IP Checking is enabled by default.

SSH_KEY_FILE

In the event you wish to store the key in Docker Secrets, you may wish to set this to /run/secrets/*secret-name*

SSH_KNOWN_HOSTS_FILE

In the event you wish to store the known_hosts in Docker Secrets, you may wish to set this to /run/secrets/*secret-name*

SSH_MODE

Defines how the tunnel will be set up:

• -R is default, remote forward mode.
• -L means local forward mode.

SSH_BIND_IP

You can define which IP address the tunnel will use to bind on remote (SSH_MODE of -R) or local (SSH_MODE of -L). The default is 127.0.0.1 only.

SSH_MODE of -R (default)

WARNING: This process involves changing the security on the server and will expose your target to additional networks and potentially the Internet. It is not recommended to do this procedure without taking additional precautions.

Use of this option will NOT have an effect unless you properly configure the GatewayPorts variable in your remote server's configuration file. Please see your SSH server documentation for proper set up.

SSH_MODE of -L

You may want to set this to 0.0.0.0 in order to bind your SSH_TUNNEL_PORT to all interfaces on local side.

SSH_SERVER_ALIVE_INTERVAL

Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server.

• 0 turns the option off.
• 10 is default for this image.

Additional details are available from ssh_config(5)

SSH_SERVER_ALIVE_COUNT_MAX

Sets the threshold of alive messages after which the connection is terminated and reestablished.

• 3 is the default for this image.
• SSH_SERVER_ALIVE_INTERVAL=0 makes this variable ineffective.

Additional details are available from ssh_config(5)

SSH_OPTIONS

Sets additional parameters to ssh connection. Supports more than one parameter.

Examples:

• SSH_OPTIONS="-o StreamLocalBindUnlink=yes" for recreate socket if it exists
• SSH_OPTIONS="-o StreamLocalBindUnlink=yes -o UseRoaming=no" for multiple parameters

Additional details are available from ssh_config(5)

Additional Environment variables

• autossh(1)
• ssh_config(5)

Mounts

Mounts are optional, for simple usage. It is far superior to use environment variables which can be stored in configuration files and transported (and backed up!) easily.

/id_rsa

Mount the key you generated within the Setup step, or set SSH_KEY_FILE.

-v /path/to/id_rsa:/id_rsa

/known_hosts

Mount the known_hosts file if you want to enable StrictHostKeyChecking, or set SSH_KNOWN_HOSTS_FILE.

-v /path/to/known_hosts:/known_hosts

Samples

docker-compose.yml

In the top example ssh-to-docker-host, a tunnel will be made from the docker container (aptly named autossh-ssh-to-docker-host) to the host running the docker container.

To use, ssh to fake internet address 203.0.113.10:2222 and you will be forwarded to 172.17.0.2:22 (the host running the docker container).

In the second example, ssh-to-lan-endpoint, a tunnel will be made to a host on the private LAN of the docker host. sshing to fake internet address 203.0.113.10:22222 will traverse through the docker container through the docker host, and onto the private lan where the connection will terminate 192.168.123.45:22.

Finally, in the third example, ssh-local-forward-on-1234, a local forward to 198.168.123.45:22 will be created on the container, mapped to port 1234. The tunnel will be created via 203.0.113.10:22222.

version: '3.7'

services:
  ssh-to-docker-host:
    image: jnovack/autossh
    container_name: autossh-ssh-to-docker-host
    environment:
      - SSH_REMOTE_USER=sshuser
      - SSH_REMOTE_HOST=203.0.113.10
      - SSH_REMOTE_PORT=2222
      - SSH_TARGET_HOST=172.17.0.2
      - SSH_TARGET_PORT=22
    restart: always
    volumes:
      - /etc/autossh/id_rsa:/id_rsa
    dns:
      - 8.8.8.8
      - 1.1.1.1

  ssh-to-lan-endpoint:
    image: jnovack/autossh
    container_name: autossh-ssh-to-lan-endpoint
    environment:
      - SSH_REMOTE_USER=sshuser
      - SSH_REMOTE_HOST=203.0.113.10
      - SSH_REMOTE_PORT=22222
      - SSH_TARGET_HOST=198.168.123.45
      - SSH_TARGET_PORT=22
    restart: always
    volumes:
      - /etc/autossh/id_rsa:/id_rsa
    dns:
      - 8.8.8.8
      - 4.2.2.4
  
  ssh-local-forward-on-1234:
    image: jnovack/autossh
    container_name: autossh-ssh-local-forward
    environment:
      - SSH_REMOTE_USER=sshuser
      - SSH_REMOTE_HOST=203.0.113.10
      - SSH_REMOTE_PORT=22222
      - SSH_BIND_IP=0.0.0.0
      - SSH_TUNNEL_PORT=1234
      - SSH_TARGET_HOST=198.168.123.45
      - SSH_TARGET_PORT=22
      - SSH_MODE=-L
    restart: always
    volumes:
      - /etc/autossh/id_rsa:/id_rsa
    dns:
      - 8.8.8.8
      - 4.2.2.4
    

Multi-Arch Images

This image has the following architectures automatically built on Docker Hub.

• amd64
• armv6 (e.g. Raspberry Pi Zero)
• armv7 (e.g. Raspberry Pi 2 through 4)
• arm64v8 (e.g. Amazon EC2 A1 Instances)

autossh's Issues

Intended use of non-root-user manipulation of /etc/passwd

Hello, I am confused about this code's intent.

autossh/rootfs/entrypoint.sh

Lines 27 to 32 in 816f453

	# Add entry to /etc/passwd if we are running non-root
	if [[ $(id -u) != "0" ]]; then
	USER="autossh:x:$(id -u):$(id -g):autossh:/tmp:/bin/sh"
	echo "[INFO ] Creating non-root-user = $USER"
	echo "$USER" >> /etc/passwd
	fi

If the user is not root, then they don't (unlikely) have write permission to /etc/passwd. So this block of code fails most of the time.

To run jnovack/autossh as a non-root user, I used a workaround where I pre-create /etc/passwd and mount it as a read-only volume.

Graceful Tunnel Shutdown

I noticed an issue when stopping the container and then restarting it again immedietly after. It seems like the session was still active on the remote server and the port was used up. Therefore when it tried to reconnect it couldn't reuse the same port again. It doesn't seem to happen all the time, so I wasn't able to reproduce it reliably.

It think this could be fixed by a more graceful shutdown, something like this at the beginning of the entrypoint.sh script:

cleanup() {
    pkill -3 autossh
}
trap 'cleanup' SIGTERM

Please let me know your thoughts.

Request for Model dynamic

maybe a mode of dynamic (-mode D) is useful,

thanks.

Please create a new release

Dear @jnovack , thank you once again for this very useful autossh container!

Could you please kindly create a new release and upload it to dockerhub? The latest release dates back to 2021, and does not include new important features contributed recently.

Docker image changing without a corresponding version change.

The docker tag of LATEST seems to be it's own image rather than pointing to a distinct version. Doing it this way makes me wonder if the most recent, non-latest image (2.0.0) is a reasonable alternative when LATEST breaks.

As of March 31, defining jnovack/autossh yields this on my RPi4 (image hash: sha256:51114f14d3f42a0142f5056d73ac92bb97a4a6ed5d2e9ad8221c15d190b4fce9):

autossh_web_1        | jnovack/autossh v2.0.0-4-g91ad8b5 revision 91ad8b5 built 2021-02-11T21:09:05Z
autossh_web_1        | Agent pid 9
autossh_web_1        | Identity added: (stdin) (autossh_user@router)
autossh_web_1        | [INFO ] Using STRICT_HOSTS_KEY_CHECKING
autossh_web_1        | sh: clock_gettime(MONOTONIC) failed

Yet jnovack/autossh:2.0.0 works as expected (image hash: sha256:8517e3b5f377fba6cbb81248285409ac588459f341acee3e2a78d65dda39ba81):

autossh_web_1        | jnovack/autossh v2.0.0 revision 1cb6609 built 2020-11-25T11:05:43Z
autossh_web_1        | Agent pid 10
autossh_web_1        | Identity added: (stdin) (autossh_user@router)
autossh_web_1        | [INFO ] Using STRICT_HOSTS_KEY_CHECKING
autossh_web_1        | [INFO ] Using autossh 1.4g
autossh_web_1        | [INFO ] Tunneling 127.0.0.1:58080  on [email protected]:22  to caddy:80
autossh_web_1        | [INFO ] # autossh -M 0 -N -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/known_hosts -o ServerAliveInterval=10 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -t -t -R 127.0.0.1:58080:caddy:80 -p 22 [email protected]

Really this issue is less about the breakage in LATEST and more about the broken image versioning.

arm32v7 architecture not building properly

Dockerhub says "linux/amd64"

Container Port closed

I am able to setup the tunnel correctly as you can see below:

However, when I try to reach it from another container within the same docker-compose project, that door is closed, as you can see below:

I setup autossh in my docker-compose.yml file like this:

What am I missing?

Unnecessary SSH_BIND_IP warning

Every time I start up, the log shows a scary warning:

[WARN ] SSH_BIND_IP requires additional server configuration to work properly

Since I am using SSH_MODE=-L I think there is no need for the warning.

Ignores SSH_STRICT_HOST_IP_CHECK=false

This still checks the hosts

My compose:

version: '3.7'

services:
  tunnel:
    image: jnovack/autossh
    container_name: tunnel
    environment:
      - SSH_REMOTE_USER=pi
      - SSH_REMOTE_HOST=docker.lan
      - SSH_REMOTE_PORT=22
      - SSH_TUNNEL_PORT=2222
      - SSH_TARGET_HOST=192.168.88.254
      - SSH_TARGET_PORT=22
      - SSH_STRICT_HOST_IP_CHECK=false
    restart: unless-stopped
    volumes:
      - ./id_rsa:/id_rsa
      - ./known_hosts:/known_hosts

output when running:

Creating tunnel ... done
Attaching to tunnel
tunnel    | jnovack/autossh v2.0.1 revision 816f453 built 2021-04-01T10:51:38Z
tunnel    | Agent pid 9
tunnel    | Identity added: (stdin) (ssh-client@303d7e380c29)
tunnel    | [WARN ] Not using STRICT_HOSTS_KEY_CHECKING
tunnel    | [INFO ] Using STRICT_HOSTS_KEY_CHECKING
tunnel    | [INFO ] Using autossh 1.4g
tunnel    | [INFO ] Tunneling 127.0.0.1:2222  on [email protected]:22  to 192.168.88.254:22
tunnel    | [INFO ] # autossh -M 0 -N -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/known_hosts -o CheckHostIP=no -o ServerAliveInterval=10 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -t -t -R 127.0.0.1:2222:192.168.88.254:22 -p 22 [email protected]
tunnel    | No ECDSA host key is known for docker.lan and you have requested strict checking.
tunnel    | Host key verification failed.

As you can see -o StrictHostKeyChecking=yes

Quirky to mount a volume that contains the id_rsa and known_hosts

I suggest that the destination mounting point should be something like /config/id_rsa instead of /id_rsa so we can mount a volume to /config that contains both id_rsa and known_hosts

You can of course work around this by mounting the volume to config and set SSH_KEY_FILE and SSH_KNOWN_HOSTS_FILE.

SSH_KEY_FILE default doesn't work

KEY_FILE is given a default of /id_rsa if SSH_KEY_FILE is not set:

# Set up key file
KEY_FILE=${SSH_KEY_FILE:=/id_rsa}

But then when the key is added to the SSH agent SSH_KEY_FILE is used rather than KEY_FILE:

eval $(ssh-agent -s)
cat "${SSH_KEY_FILE}" | ssh-add -k -

This means that if SSH_KEY_FILE is not set and a key is mounted to /id_rsa it will not be used in authentication.

This issue seems to have originated in 2295b90

Latest image broken for Raspberry Pi

The latest image breaks on my RPi4 (image hash: sha256:51114f14d3f42a0142f5056d73ac92bb97a4a6ed5d2e9ad8221c15d190b4fce9):

autossh_web_1        | jnovack/autossh v2.0.0-4-g91ad8b5 revision 91ad8b5 built 2021-02-11T21:09:05Z
autossh_web_1        | Agent pid 9
autossh_web_1        | Identity added: (stdin) (autossh_user@router)
autossh_web_1        | [INFO ] Using STRICT_HOSTS_KEY_CHECKING
autossh_web_1        | sh: clock_gettime(MONOTONIC) failed

Randomized Port

Apologies but this is more of a question than an issue.

We intend on utilising this for a specific use case where we have to use randomised ports.

You stated that if the value of SSH_TUNNEL_PORT is not set, a random port above 32768 will be chosen.

So my question is, what would be the behaviour if the random port that's chosen is a port that is already in use by another ssh tunnel? Would it crash and restart (therefore randomising the port again) ? Would it just fail to connect and not restart ?

Problems with docker-compose example in the README.md

Reading the ssh key file seems to fail as specified in the example, because it refers to the id_rsa file directly.

  volumes:
     - /etc/autossh/id_rsa:/id_rsa

It works if you map the volume to the directory containing the id_rsa file, and specify the path via SSH_KEY_FILE as an environment variable.

   environment:
     SSH_KEY_FILE: /ssh/id_rsa  
   volumes:
     - /etc/autossh=:/ssh

Default SSH_MODE environment variable doesn't work with a for a strict proxy (no login). Must set it to:

SSH_MODE: -Ng -L

SSH_KNOWN_HOSTS should be SSH_KNOWN_HOSTS_FILE

Rename variable SSH_KNOWN_HOSTS to be SSH_KNOWN_HOSTS_FILE to comply with Docker naming conventions.

This is a breaking change.

Create tunnel for container?

Hello,

I'm looking for a way to create a tunnel for a redash container. Is it possible to use this docker container to create an autossh tunnel and allow the redash container to use it?

This is the command I'm currently using which I would like to turn into an autossh container:
autossh -M 20017 -f -N -L 3304:127.0.0.1:3304 -p 22 -i /tunnel/key [email protected]

No Version file (missing docker copy)

Since the latest update, autossh doesnt work.

/entrypoint.sh: source: line 2: can't open 'version.sh': No such file or directory
you added this swiftly, but forgot to do COPY /version.sh /version.sh in the Dockerfile

Please fix this, thanks.

"*:port" doesn't work as catchall bind host for -L forwards in 2.0.0 & produces invalid autossh call

Hi there!

First of all thank you very much for the work you've put into this, I've been using your autossh image for a long time now and greatly appreciate how easy you've made everything.

I have my docker containers deployed with watchtower enabled and recently got updated to version 2.0.0 by that. That caused a bit of confusion at first, but I finally was able to figure out the stuff I needed to change after actually comparing the README with my compose file 😅

I wanted to bind the forwarded port in the docker container to *:19999 and thus set SSH_TUNNEL_PORT=*:19999 as written in the docs:

However that results in an invalid command line which autossh complains about, e.g. -L 127.0.0.1:*:19999:127.0.0.1:19999 which obviously is wrong.

So I dug into the entrypoint script and noticed that I should actually be using an undocumented env var called SSH_BIND_IP for this. Setting that to 0.0.0.0 achieved what I wanted:

  autossh:
    image: jnovack/autossh
    container_name: autossh
    environment:
      - SSH_REMOTE_USER=someuser
      - SSH_REMOTE_HOST=somehost
      - SSH_REMOTE_PORT=22
      - SSH_BIND_IP=0.0.0.0
      - SSH_TUNNEL_PORT=19999
      - SSH_TARGET_HOST=127.0.0.1
      - SSH_TARGET_PORT=19999
      - SSH_MODE=-L

I this a documentation bug (wrong reference to *:port and missing docs for SSH_BIND_IP) or a bug in the implementation (missing parsing)? If it is a documentation bug, I'd be happy to send a PR your way to fix it.

github readme and dockerhub readme have different variable names all over

Enable monitor port

I've seen situations, when remote host went offline, but autossh containers remained with dangling ssh connection, which is neither online nor offline. Eventually, autossh restarts them, perhaps when some port lease expires within the kernel. But it takes time, about 30 minutes.

Monitor port is disabled by -M 0, but is actually useful for resuming connection that is stalled due to an issue described above.

Enabling monitor port isn't easy, because it is hardcoded in autossh:

char    *mhost = "127.0.0.1";   /* host in port forwards */
...
     /* 
      * Only if we're doing the network monitor thing.
      * Socket once opened stays open for listening for 
      * the duration of the program.
      */
     if (writep) {
         if (!echop) {
             sock = conn_listen(mhost, readp);
             /* set close-on-exec */
             (void)fcntl(sock, F_SETFD, FD_CLOEXEC);
         } else
             sock = NO_RD_SOCK;
     }

As we know, assumption of 127.0.0.1 being a loopback address is wrong in Docker. Should we [ask for a] patch autossh source code, or do you see some other workaround?

What about passphrase protected private keys?

Hello,
i'm using private keys with passphrase protection.
Is there a possibility to enter these passphrase while the connection init?

Enter passphrase for (stdin): [email protected]: Permission denied (publickey).

[INFO ] # autossh -M 0 -N -o StrictHostKeyChecking=no -o ServerAliveInterval=10 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -t -t -R 127.0.0.1:61454:172.17.0.35:80 -p 22 [email protected]
[INFO ] Tunneling 127.0.0.1:61454  on [email protected]:22  to 172.17.0.35:80
[INFO ] Using autossh 1.4g
Agent pid 9

question about "ExitOnForwardFailure yes"

is there a difference between "ExitOnForwardFailure yes" and "ExitOnForwardFailure=yes"?

Tunneling into another container?

Apologies if this is a stupid question; I am new to this. I'm running Plex media server in bridged mode inside of another docker container on the same host machine. My question is, how would I configure this (if possible) to set up a tunnel from the remote server into the Plex container? Would I need to generate the rsa key inside of the Plex container? Also, can I use the same ports for both the remote server and the target; or would this be ill-advised? Thanks!

Feature: add env var for additional ssh options

Hi,

I found that you cannot simply pass ssh options for tunnel. Think it can be done via mounting .ssh/config ⇒ /etc/ssh/ssh_config, but it would be good to add some explicit option like SSH_OPTIONS or something like for this.

PS: Great project, simple and usable! 🚀

Support for multiple ports

Hey Justin,

I find the container extremely useful, thanks so much for putting it together. I have one feature request - can you please add support for forwarding multiple ports via single instance of the container?

Currently, for every forwarded port I have to spin up a separate instance of the container. AutoSSH supports multiple ports out of the box so this will likely require just piping arguments to the binary correctly.

Thanks again!