Chisel TCP/UDP Tunnel on AWS User Guide

Overview

This guide covers the deployment and configuration of Chisel on AWS using cloudimg AWS 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 instance'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 instance 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 VPC; TCP and UDP application streams are multiplexed over that single connection

• A per instance username and password and a per instance 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 AWS account, an EC2 key pair, a VPC + subnet in the target region

• Subscription to the Chisel listing on AWS Marketplace

• A security group allowing TCP 22 (admin) and TCP 8080 (Chisel tunnel) from the clients that will connect

Recommended instance type: m5.large (2 vCPU, 8 GB RAM). Light tunnels run comfortably; busy tunnels can move to a larger instance type.

Step 1: Launch from AWS Marketplace

Find Chisel on AWS Marketplace, published by cloudimg, and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Select the Ubuntu 24.04 delivery option, your instance type (m5.large), your key pair, and a security group that allows 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: Connecting to your instance

SSH in with your EC2 key pair as the login user for the OS variant you launched.

Step 3: First boot

On first boot the image resolves the instance public IP via EC2 instance metadata, generates a per instance SSH server key, generates a per instance username and password, captures the server fingerprint, and starts Chisel. This completes within a minute. SSH in and read the per instance 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 instance username and password and pinning the per instance 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 instance 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 instance 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 instance 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 security group. 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 instance. 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 instance.

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 instance username, password and server key), the systemd integration, and 24/7 support.

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 AWS

Find Chisel on the AWS Marketplace, published by cloudimg. Subscribe and launch the Ubuntu 24.04 delivery option as shown above.

Need Help?

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