Chisel
Overview
This guide covers the deployment and configuration of Chisel on AWS using SecureAnyCloud AWS Marketplace images. Chisel is a fast TCP and UDP tunnel, transported over HTTP and secured by SSH. A single self-contained Go binary is both the server and the client. It multiplexes tunneled 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.
No baked-in 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 starts with that authentication file, so a client that is unauthenticated or uses a wrong password is rejected at the SSH handshake and cannot open a tunnel.
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.
Reverse tunnels off. Reverse port forwarding, which would let a client open inbound listening sockets on the server, is left disabled. The SOCKS proxy on the server is likewise off until you enable it.
What you get:
- Chisel (official pinned binary), run under systemd as the unprivileged
chiseluser (chisel.service) - The HTTP tunnel transport on port 8080, listening on all interfaces so that 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 that the server keeps receiving patches
Prerequisites
- An active AWS account, an EC2 key pair, and a VPC and subnet in the target region
- A subscription to the Chisel listing on AWS Marketplace
- A security group that allows 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, and busy tunnels can move to a larger instance type.
Launch from AWS Marketplace
Find Chisel on AWS Marketplace, published by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Select the Ubuntu 24.04 delivery option, your instance type (m5.large) and your key pair. Choose 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).
Connect to your instance
Connect over SSH with your EC2 key pair, as the login user for the OS variant that you launched.
OS variant: Ubuntu 24.04. SSH login user: ubuntu. Example: ssh -i your-key.pem ubuntu@<instance-public-ip>
First boot
On first boot, the image resolves the instance public IP through EC2 instance metadata and generates a per-instance SSH server key. It also generates a per-instance username and password, captures the server fingerprint and starts Chisel. This process completes within a minute. Connect over SSH and read the per-instance details, including the username, password and fingerprint:
sudo cat /root/chisel-credentials.txtConfirm the server is running
Confirm that chisel.service is active and listening on 8080 across all interfaces:
systemctl is-active chisel.service /usr/local/bin/chisel --version ss -tln | grep :8080Prove a tunnel round trip
The image ships a self-test that starts a loopback service. It connects a Chisel client that authenticates with the per-instance username and password and pins the per-instance server fingerprint. It then opens a local port forward and confirms that traffic flows end to end through the tunnel. The self-test also confirms that a wrong-credential client is rejected. Run it to prove that the server is healthy end to end:
sudo bash /usr/local/lib/sac/chisel-roundtrip.shVerify that authentication is enforced
The server starts 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"'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. Pin this server's fingerprint, and authenticate 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:5432Now localhost:5000 on your workstation reaches db-internal:5432 through the encrypted tunnel. You can pass multiple remotes on one command line, and a remote can be TCP or UDP (append /udp).
Run a SOCKS proxy hop
To use the server as a dynamic SOCKS5 proxy that routes arbitrary traffic through it, request the special socks remote. This opens a local SOCKS5 listener that tunnels out through the server:
chisel client \
--fingerprint '<CHISEL_FINGERPRINT>' \
--auth '<CHISEL_USER>:<CHISEL_PASS>' \
http://<CHISEL_HOST>:<CHISEL_PORT> \
1080:socksPoint your browser or tool at the SOCKS5 proxy on localhost:1080.
Front the server with TLS for internet exposure
Port 8080 speaks plain HTTP as the tunnel transport, and the tunnel payload itself is always SSH-encrypted. For exposure to the public internet, terminate TLS in front of Chisel. You can use Chisel's built-in TLS by supplying a certificate and key, or 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, edit 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.pemThen sudo systemctl restart chisel and connect clients with https:// instead of http://.
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 that 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 only when you need them, and scope them, by adding --reverse or --socks5 to the ExecStart line as in Step 9.
Security recommendations
- Restrict the security group. Allow TCP 8080 only from the client networks that need to connect, and allow 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.jsonis readable only by root and thechiselgroup. - Scope access with the authfile. Restrict each user to the exact destinations that they need, with address regular expressions (Step 10), instead of allowing all destinations.
- 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.
Support and licensing
Chisel is developed by Jaime Pillora (jpillora) and distributed under the MIT license. This SecureAnyCloud image bundles the unmodified official Chisel binary. SecureAnyCloud provides the packaging, the secure-by-default first boot (per-instance username, password and server key), the systemd integration and 24/7 support.
SecureAnyCloud 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 SecureAnyCloud. Subscribe and launch the Ubuntu 24.04 delivery option as shown above.
Need Help?
Email sales@secureanycloud.com for deployment help, configuration questions or licensing inquiries.
Deploy on AWS
Launch Chisel TCP/UDP Tunnel with 24/7 support from SecureAnyCloud.
View on Marketplace
Need Help?
Our support team is available 24/7.
sales@secureanycloud.com