Chisel on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Chisel on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Chisel is a fast TCP/UDP tunnel, transported over HTTP and secured via SSH. A single self contained Go binary is both the server and the client: it multiplexes tunnelled connections over one HTTP connection and authenticates the endpoints with an SSH key exchange, so it traverses restrictive firewalls and proxies while staying end to end encrypted.

The image installs the official Chisel binary (pinned at build) and runs it as a chisel server under systemd, so a tunnel endpoint is listening within minutes of launch.

Security by design — no baked password. There is no default password inside the image. A unique username and password are generated on this machine's first boot and written into the server's authentication file and a root only credentials file. The server is started with that authentication file, so an unauthenticated or wrong-password client is rejected at the SSH handshake and cannot open a tunnel.

Security by design — per VM server key. A unique SSH server key is generated on first boot, so the private key is never baked into the image. The server presents a stable fingerprint that clients pin, which prevents a machine-in-the-middle from impersonating your server.

Security by design — reverse tunnels off. Reverse port forwarding, which would let a client open inbound listening sockets on the server, is deliberately left disabled. The SOCKS proxy on the server is likewise off until you enable it.

What is included:

• Chisel (official pinned binary), run under systemd as the unprivileged chisel user (chisel.service)

• The HTTP tunnel transport on port 8080, listening on all interfaces so the server is reachable inside your VNet; TCP and UDP application streams are multiplexed over that single connection

• A per VM username and password and a per VM SSH server key, all generated on first boot and never baked into the image

• A shipped round trip self test that proves an authenticated, fingerprint pinned client carries traffic through the tunnel and that a wrong-credential client is rejected

• Unattended security upgrades left enabled so the server keeps receiving patches

Prerequisites

• Active Azure subscription, SSH public key, VNet + subnet in the target region

• Subscription to the Chisel listing on Azure Marketplace

• Network Security Group rules allowing TCP 22 (admin) and TCP 8080 (Chisel tunnel) from the clients that will connect

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) for light use. Busy tunnels should use Standard_D2s_v5 or larger.

Step 1: Deploy from the Azure Portal

Search Chisel in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 8080 (Chisel tunnel) from your client networks, and TCP 22 for administration. For internet exposure, front port 8080 with TLS (see Step 9).

Step 2: Deploy from the Azure CLI

RG="tunnel-prod"; LOCATION="eastus"; VM_NAME="chisel1"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/chisel-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
# Open the tunnel and admin ports on the VM's NSG:
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 8080 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

Step 3: First boot

On first boot the image resolves the VM public IP, generates a per VM SSH server key, generates a per VM username and password, captures the server fingerprint, and starts Chisel. This completes within a minute. SSH in as azureuser and read the per VM details, including the username, password and fingerprint:

sudo cat /root/chisel-credentials.txt

Step 4: Confirm the server is running

chisel.service is active and listening on 8080 across all interfaces.

systemctl is-active chisel.service
/usr/local/bin/chisel --version
ss -tln | grep :8080

Step 5: Prove a tunnel round trip

The image ships a self test that starts a loopback service, connects a Chisel client authenticated with the per VM username and password and pinning the per VM server fingerprint, opens a local port forward, and confirms traffic flows end to end through the tunnel. It also confirms that a wrong-credential client is rejected. Run it to prove the server is healthy end to end:

sudo bash /usr/local/lib/cloudimg/chisel-roundtrip.sh

Step 6: Authentication is enforced

The server is started with an authentication file, so a client that presents no credentials or the wrong password is rejected at the SSH handshake and cannot open a tunnel. You can see this directly: a client with a bad password fails the handshake and never establishes a forward.

sudo bash -c 'FP=$(grep ^chisel.server.fingerprint= /root/chisel-credentials.txt | cut -d= -f2-); \
  /usr/local/bin/chisel client --max-retry-count 0 --auth bad-user:bad-pass --fingerprint "$FP" \
  http://127.0.0.1:8080 19099:127.0.0.1:22 2>&1 | grep -E "Fingerprint|Listening|Authentication failed"'

Step 7: Connect a client from another machine

Chisel's single binary is also the client. From any machine that has Chisel installed, forward a local port to a service that is reachable from this server, pinning this server's fingerprint and authenticating with the per VM credentials from /root/chisel-credentials.txt. For example, forward your local port 5000 to a database at db-internal:5432 that only the server can reach:

chisel client \
  --fingerprint '<CHISEL_FINGERPRINT>' \
  --auth '<CHISEL_USER>:<CHISEL_PASS>' \
  http://<CHISEL_HOST>:<CHISEL_PORT> \
  5000:db-internal:5432

Now localhost:5000 on your workstation reaches db-internal:5432 through the encrypted tunnel. You can pass multiple remotes on one command line, and remotes may be TCP or UDP (append /udp).

Step 8: Run a SOCKS proxy hop

To use the server as a dynamic SOCKS5 proxy (route arbitrary traffic through it), request the special socks remote. This opens a SOCKS5 listener locally that tunnels out through the server:

chisel client \
  --fingerprint '<CHISEL_FINGERPRINT>' \
  --auth '<CHISEL_USER>:<CHISEL_PASS>' \
  http://<CHISEL_HOST>:<CHISEL_PORT> \
  1080:socks

Point your browser or tool at the SOCKS5 proxy on localhost:1080.

Step 9: Front the server with TLS for internet exposure

Port 8080 speaks plain HTTP as the tunnel transport (the tunnel payload itself is always SSH-encrypted). For exposure to the public internet, terminate TLS in front of Chisel — either with Chisel's built in TLS by supplying a certificate and key, or with a reverse proxy such as Caddy or nginx. To use Chisel's built in TLS, place a certificate and key on the VM and add the flags to the service, for example by editing the unit's ExecStart with sudo systemctl edit chisel:

ExecStart=/usr/local/bin/chisel server --port 8080 \
    --keyfile /etc/chisel/chisel.key --authfile /etc/chisel/users.json \
    --tls-cert /etc/chisel/fullchain.pem --tls-key /etc/chisel/privkey.pem

Then sudo systemctl restart chisel and connect clients with https:// instead of http://.

Step 10: Restrict and extend access

The per VM authentication file lives at /etc/chisel/users.json. Each entry maps "user:password" to a list of address regular expressions the user is allowed to reach; an empty pattern allows all destinations. To restrict a user to a single database, or to add more users, edit the file and restart the service:

{
  "<CHISEL_USER>:<CHISEL_PASS>": ["^db-internal:5432$"],
  "readonly:another-secret": ["^metrics-internal:9090$"]
}

Reverse port forwarding (clients opening listeners on the server) and the server SOCKS proxy are off by default. Enable them deliberately, and only when scoped, by adding --reverse or --socks5 to the ExecStart line as in Step 9.

Step 11: Security recommendations

• Restrict the NSG. Allow TCP 8080 only from the client networks that need to connect, and TCP 22 for administration only.

• Front public exposure with TLS. Use Chisel's built in TLS or a reverse proxy (Step 9) whenever the endpoint is reachable from the internet.

• Keep the credentials secret. The username, password and fingerprint live only in /root/chisel-credentials.txt (root only) and are unique to this VM. The authentication file /etc/chisel/users.json is readable only by root and the chisel group.

• Scope access with the authfile. Restrict each user to the exact destinations they need with address regular expressions (Step 10), rather than allowing all.

• Keep reverse tunnels off unless you specifically need a client to open a listener on the server.

• Keep the OS and Chisel patched. Unattended security upgrades remain enabled on the running VM.

Step 12: Support and Licensing

Chisel is developed by Jaime Pillora (jpillora) and distributed under the MIT license. This cloudimg image bundles the unmodified official Chisel binary. cloudimg provides the packaging, the secure by default first boot (per VM username, password and server key), the systemd integration, and 24/7 support with a guaranteed 24 hour response SLA.

cloudimg is not affiliated with or endorsed by the Chisel project. Chisel is a mark of its respective owner and is used here only to identify the software.

Deploy on Azure

Find Chisel on Ubuntu 24.04 LTS on the Azure Marketplace, published by cloudimg. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.