luciusm/ssh-tunnel repository overview

⁠Container image for local ssh tunneling into firewall-protected servers

⁠Basic idea

In many scenarios, the ssh server of a campus computer or HPC cluster is protected by firewalls, requiring VPN on the client side. It become impractical if the client needs to connect to multiple such servers, since by default the VPN softwares renders global network traffic.

The ssh-tunnel image provides an approach to circumvent such situation, by setting up individual containers as OpenSSH-server with individual VPN environments, for example:

• Client --ssh--> [container-1, VPN-1, port: 2222] --ssh--> [protected server-1, port: 22]
• Client --ssh--> [container-2, VPN-2, port: 3333] --ssh--> [protected server-2, port: 22]

On the client side, the host computer does not interfere with the VPN interface at all. Such settings can be quite useful if the user is controlling several firewall-protected servers for HPC calculations or supervision.

The image is based on ghcr.io/linuxserver/openssh-server. Currently using openconnect⁠ as the VPN client since most campus VPN are using Cisco SSL VPN. More to be added if necessary

⁠Usage

Basically, use the following steps for ssh-tunneling:

1. Start the ssh-tunnel image in daemon mode, with proper VPN settings
2. ssh into the protect server by the ssh proxy server

For best practice, prepare the following files:

• A pair of keys for your local machine (e.g. ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa generated by ssh-keygen) for password-less authentication into the containers
• SSH-host-key pairs (e.g. ssh_host_rsa_key etc.) for fingerprints on the container if you want to avoid the WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! error. Place all the key pairs under one folder (e.g. ~/ssh_host_keys)
• Necessary authentication files for the firewall-protected server, e.g. the private key.

⁠Start the daemon container

Use docker-cli

docker run -d \
  --cap-add NET_ADMIN `#Need NET_ADMIN privilege for networking`\
  --name=ssh-tunnel-vpn0 \
  -p 3333:2222 `#3333 is the ssh tunnel port on your localhost`\
  -v /path/to/host_key_files:/config/ssh_host_keys `#if you want to fix ssh-keys`\
  -e PUBLIC_KEY="$(cat ~/.ssh/id_rsa.pub)" `#change if using other public keys`\
  -e OPENCONNECT_USERNAME="[email protected]" `#change accordingly`\
  -e OPENCONNECT_SERVER="vpn.campus.edu" `#change accordingly`\
  -e OPENCONNECT_PW="Some password" `#VPN password, cat from a password file if necessary`\
  --restart unless-stopped \
  luciusm/ssh-tunnel

Most of the parameters can be refered to the linuxserver/openssh-server⁠ image.

Alternatively, password variables can be set using file secrets by prepending FILE__, e.g.

-e FILE__OPENCONNECT_PW=/run/secrets/vpnpasswd

if the /run/secrets/vpnpasswd is mounted

⁠SSH proxy connection

For the first time use, it's better to test if the VPN actually works inside the container. While the daemon container is running, execute the ssh connection inside the container:

# Change the container name according to your case
docker exec ssh-tunnel-vpn0 ssh <options> <username>@<protected-server>

For troublingshooting, check if sshd and openconnect are running in the container. Make sure the line

AllowTcpForwarding yes

is present in the /etc/ssh/sshd_config file.

Then the actual ssh tunneling stuff:

ssh -o ProxyCommand="ssh -W %h:%p -p <proxy-port> -i <private-key> ssh-user@localhost" <ssh-options> <username>@<protected-server>

• For <proxy-port> and <private-key> please see the previous step of running container
• ssh-user is the default user in the container. If you have the same username on localhost, remember to specify via -e USER_NAME=<new_username> when starting the container.

If everything's fine now you should have access to the protected server