lblnest/ssh-tunnel repository overview

⁠What is lblnest/ssh-tunnel?

The lblnest/ssh-tunnel image uses ssh to provide direct access to ports that are shielded by a firewall/gateway. The administrator of the firewall/gateway will need to allow access for the ssh protocol (port 22 unless explicitly changed), and need to be running an sshd daemon. This host will and need to have a valid user account in which the public key for the incoming user is stored.

⁠How to use this image

The simplest way to use this image is to use your own ssh configuration. In that case for each node to which you want to tunnel, you need an entry like the following in your ${HOME}/.ssh/config file. (Note that the tnl_ prefix to the Host name is used to identify which entries in this file should be used to create tunnels.)

Host tnl_<node>
    GatewayPorts yes
    Hostname <gateway_node>
    IdentityFile /usr/share/tunnels/id_rsa
    LocalForward <container_port> <target_node>:<target_port>
    StrictHostKeyChecking no
    User <gateway_user>

In this case the <node> is a simple name for the target node, while <target_node> is the fully qualified domain name. The <gateway_node> is the node on which the sshd is running and the <gateway_user> the account that exists and contains the public key that matches the one held in ${HOME}/.ssh/id_rsa on the host of the container. The <target_port> is the port on the target node that should be one end of the tunnel, and the <container_port> is the port inside the container that will be the other end. The <container_port> is then mapped onto the host's interface with a docker run command, such as the following.

docker run --name my-tunnels -v ${HOME}/.ssh:/usr/share/tunnels -p 127.0.0.1:8080:8080/tcp -d ssh-tunnel

In this case the container's port is only mapped onto the local interface of the host so that the tunnel is not exposed to other hosts.

⁠Using StrictHostKeyChecking yes

In the config file shown above the setting StrictHostKeyChecking no is included to enable the first connection to be made without having to confirm that gateway hosts public key. While this simplifies connecting, it does reduce the security of the connection as a man-in-the-middle attack may not be detected. This solution to this, when the gateway host is know in advance, is to include public host key in a file and update the config file to point to this file.

For example, by adding the line below to the Host entry, while using the command above, it will use the known_hosts files in the your .ssh directory.

UserKnownHostsFile /usr/share/tunnels/known_hosts

(At this point you can remove the StrictHostKeyChecking options completely as the default is "yes".)

⁠Environment Variable

This image supports the following environmental variable.

TUNNEL_SSH_CONFIG

If this exists, its value will be used at the location of the the config file.