Termix 26.10.6 on AWS User Guide

Overview

This guide covers launching and using Termix 26.10.6 on Ubuntu 24.04 from cloudimg on Amazon EC2. It is one version of the cloudimg Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace; you pick it as the software version when you launch.

Termix is a self-hosted server management platform that runs in your browser. You save the servers you manage as hosts, then open SSH terminals in tabs and split panes, browse and edit their files over SFTP, run SSH port-forwarding tunnels, open RDP, VNC and Telnet remote desktops, manage Docker containers and keep reusable command snippets, all from one web interface. Termix 26.x ships those features as plugins; this image carries upstream's standard plugin set.

What the cloudimg image adds:

• No default login, no open sign-up. The image contains no Termix account and no database. On the first boot of your instance a one-time service creates the single administrator admin with a password generated on the instance, turns self-registration off, proves both, and only then opens the web interface. Nobody can become the first administrator by reaching the page before you.
• HTTPS on port 443, from the first boot. nginx serves Termix on port 443 with a certificate generated on your instance. Port 80 redirects to HTTPS, and a request for a host name the instance does not serve is dropped.
• Termix on localhost only. The Termix backend listens on 127.0.0.1:30001, behind nginx. Port 30001 is not open to the network and the listing's security group does not include it.
• Per-instance keys for your saved credentials. Termix's four keys (session signing, database encryption, credential encryption and its internal token) are generated on your instance's first boot, kept in root-only files and handed to Termix by systemd. The database is stored encrypted, and every user's saved SSH passwords and private keys are encrypted with a key of their own.
• Hardened front door. nginx hands Termix the real client address and the configured host name (never values a client sends), and refuses a request that changes something, or opens a WebSocket, when it carries another site's Origin.
• Instance metadata blocked. Termix connects out to the hosts you add (SSH, SFTP, RDP, VNC, Telnet, tunnels, status checks). Neither Termix nor nginx can reach the EC2 instance metadata service (169.254.169.254 and fd00:ec2::254), so a host entry aimed at it cannot read this instance's role credentials.
• The current Termix release. Termix 26.10.6, outside every published Termix security advisory at the time of the build, built from the unmodified upstream source with six npm dependencies raised to their fixed releases.
• No phone-home plugin. Upstream's Usage Statistics (telemetry) plugin is not installed. Only signed plugins can be added later.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: Termix 26.10.6 with 19 plugins (built from the v26.10.6 source), Node.js 24.22.2 LTS (for Termix only, not on the shell path), nginx 1.24 (from Ubuntu 24.04), cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Root volume: 8 GiB gp3

Security posture

• Per-instance secrets only. The administrator password, Termix's session signing secret, database key, credential encryption key, internal token and the TLS key are all generated on your instance's first boot. Two instances launched from the same AMI share none of them.
• Fails closed. Termix and nginx start only after first boot has written this instance's configuration and a ready marker. A start-up check refuses to start Termix if a key is missing or too short, if a plaintext database appears, or if the data directory holds a key or a symbolic link.
• End-entity certificate. The self-signed certificate can only vouch for this instance's own names (it is not a certificate authority). Compare its fingerprint with the one in the credentials file, or replace it with a CA-issued certificate (Step 8).
• Sandboxed service. Termix runs as its own termix account with no capabilities, a read-only view of the system and write access to /var/lib/termix only.
• Per-instance identity. SSH host keys and the machine ID are generated fresh on every instance.

Prerequisites

1. An AWS account and permission to launch EC2 instances
2. An EC2 key pair in the Region you launch in
3. A security group that allows TCP 22 (SSH) from your admin network and TCP 443 (the Termix web interface) from the networks your users browse from, plus TCP 80 if you want plain-HTTP visitors redirected. Never open 30001: the Termix backend listens on localhost only.

Recommended instance type: m5.large. Termix itself is light; open terminals, file transfers and remote-desktop sessions add memory and CPU, so size up for many concurrent users.

Connecting to your instance

Step 1: Launch the instance

Option A: AWS Marketplace console

1. Open the cloudimg Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
2. Once the subscription is active, choose Launch your software.
3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for the full launch wizard). In Version, choose Termix 26.10.6 on Ubuntu 24.04, then choose your Region.
4. Pick an instance type (m5.large recommended) and your key pair.
5. Security group: the listing's default group allows SSH (22), HTTP (80) and HTTPS (443). Restrict SSH, and preferably 443, to your own addresses.
6. Choose your VPC and a subnet with a route to the servers you will manage (and a public IP if you browse to Termix over the internet), leave the metadata defaults (the image already requires IMDSv2), then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH and HTTPS from your management address, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and the VPC, subnet, key pair and CIDR range with your own.

SG=$(aws ec2 create-security-group --group-name termix \
  --description "Termix" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22  --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 443 --cidr <your-mgmt-cidr>
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=termix}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required. First boot takes about a minute after the instance is running.

Step 2: Connect and check the services

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

systemctl is-active termix nginx
sudo test -f /var/lib/cloudimg/termix-firstboot.done && echo FIRSTBOOT_DONE

active
active
FIRSTBOOT_DONE

termix-firstboot ran once on the first boot; termix is the Termix backend and nginx serves the web interface. Only SSH and nginx listen on network ports; Termix listens on the loopback address:

sudo ss -lntp | awk 'NR>1 {print $4}' | grep -v '127.0.0.5' | sort -u

0.0.0.0:22
0.0.0.0:443
0.0.0.0:80
127.0.0.1:30001
[::]:22
[::]:443
[::]:80

Step 3: Get your URL and admin password

The URL and the administrator password are in a file only root can read:

sudo cat /root/termix-credentials.txt

# Termix 26.10.6 - generated on first boot by termix-firstboot.service.
# Every value below is unique to this instance; nothing was baked into the image. Keep this file private.

# Web interface (HTTPS, self-signed certificate unique to this instance): sign in as admin with the password below,
# then change it (User profile -> Security). Self-registration is OFF; add users under Settings -> Users.
TERMIX_URL=https://203.0.113.10/
TERMIX_ADMIN_USERNAME=admin
TERMIX_ADMIN_PASSWORD=<your-password>
TERMIX_HOST=203.0.113.10
# The certificate served on 443 (/etc/nginx/cloudimg/tls/termix.crt), to compare with your browser's warning:
TLS_CERT_SHA256=15:83:3A:...:4C

# Self-test: sudo termix-selftest      Serve Termix under your own DNS name: sudo termix-set-host <dns-name>
# Guide: https://www.cloudimg.co.uk/guides/termix-26-10-6-on-ubuntu-24-04-aws/

The URL uses the instance's public IPv4 address (its private address when it has no public one). Termix also answers on the instance's public DNS name.

Step 4: Sign in

Open TERMIX_URL in your browser. The certificate is self-signed, so the browser warns once: compare the fingerprint it shows with TLS_CERT_SHA256 from the credentials file, then continue. Sign in as admin with TERMIX_ADMIN_PASSWORD.

On your first sign-in Termix walks you through a four-step Set up your workspace wizard: which plugins to keep on (the recommended set is pre-selected; the ones you turn off stay installed and can be turned on later from the plugin manager), the layout, the text size and language, and optionally a passkey or security key for two-factor sign-in. You can change all of it later.

Then change the password: open User Profile (the avatar at the bottom left, or User Profile under Quick Actions on the dashboard). Consider adding two-factor authentication (TOTP or a passkey) there too.

Step 5: Add a host and open a terminal

1. In the Hosts panel choose + Add Host.
2. Enter a name, the server's address and SSH port, the user name, and either a password or a private key. Termix encrypts what you save with your own data key, which only unlocks while you are signed in.
3. Save, then choose the terminal icon (>_) on the host's card. On the first connection Termix shows the server's SSH host key fingerprint: compare it with the server's own (ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub on that server) before you choose Accept & Continue. The file manager (SFTP) and host metrics are the other icons on the card and at the foot of the terminal.

Termix connects from this instance, so the servers you add must be reachable from its subnet and security group. Remote desktop (RDP, VNC and Telnet) uses Termix's built-in engine; no separate guacd service is needed.

Step 6: Users and sign-up

Self-registration is off on this image in two places: the Allow registration setting is off, and the systemd drop-in /etc/systemd/system/termix.service.d/60-cloudimg-registration.conf pins it off (ALLOW_REGISTRATION=false). Add users yourself under Admin Settings (Quick Actions on the dashboard), which manages users and roles. Check from the instance:

H=$(sudo sed -n 's/^TERMIX_HOST=//p' /root/termix-credentials.txt)
curl -s --cacert /etc/nginx/cloudimg/tls/termix.crt --resolve "$H:443:127.0.0.1" "https://$H/users/registration-allowed"; echo

{"allowed":false}

If you do want open sign-up, remove the drop-in (sudo rm it, then sudo systemctl daemon-reload and sudo systemctl restart termix) and turn the setting on in Termix. Anyone who can reach port 443 can then create an account, so restrict the security group first.

Step 7: Tunnels and the security group

The Tunnels plugin runs SSH port forwards from this instance. A forward listens on 127.0.0.1 unless you choose another bind address. A forward bound to another address is reachable only after you open its port in the instance's security group; the default group opens 22, 80 and 443 only.

Step 8: Your own DNS name and certificate

Point a DNS A record at the instance, then:

sudo termix-set-host termix.example.com

This issues a new self-signed certificate for that name, updates nginx and the credentials file, and prints the new fingerprint. sudo termix-set-host with no name returns to the instance's own address.

To use a CA-issued certificate instead, put the certificate chain and key in /etc/nginx/cloudimg/tls/termix.crt and /etc/nginx/cloudimg/tls/termix.key (key mode 0600, owned by root), then run sudo nginx -t && sudo systemctl reload nginx. Do not add the self-signed certificate to your computer's trust store; compare its fingerprint, or replace it.

Step 9: Security checks

Run the built-in self-test:

sudo termix-selftest

Termix 203.0.113.10: termix + nginx up, backend 127.0.0.1:30001 only, HTTPS OK, anonymous API refused, registration closed, IMDS denied
SELFTEST_OK

An anonymous API request is refused, and the backend port is not reachable from the network:

H=$(sudo sed -n 's/^TERMIX_HOST=//p' /root/termix-credentials.txt)
curl -s -o /dev/null -w '%{http_code}\n' --cacert /etc/nginx/cloudimg/tls/termix.crt --resolve "$H:443:127.0.0.1" "https://$H/host/db/host"
P=$(hostname -I | awk '{print $1}')
timeout 5 bash -c "exec 3<>/dev/tcp/$P/30001" 2>/dev/null && echo "30001 OPEN" || echo "30001 refused"

401
30001 refused

Termix and nginx are denied the instance metadata service:

systemctl show -p IPAddressDeny termix nginx

IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32

IPAddressDeny=fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32

Termix's keys are root-only files, and its database is stored encrypted:

sudo ls -l /etc/termix/secrets | awk 'NR>1 {print $1, $3, $9}'
sudo ls /var/lib/termix

-rw------- root database_key
-rw------- root encryption_key
-rw------- root internal_auth_token
-rw------- root jwt_secret
backups
db.sqlite.encrypted
uploads

Step 10: Passwords and access

• Lost the admin password: on the sign-in page choose Forgot Password?. Termix writes a reset code to its log on the instance, which you read over SSH with sudo journalctl -u termix | grep -i reset.
• SSH to the instance is key-only: password and keyboard-interactive logins and root logins are disabled in /etc/ssh/sshd_config.d/00-cloudimg.conf.
• Keep port 443 limited to the networks your users work from: a Termix account opens shells on every server it holds.

Step 11: Versions, provenance and file locations

cat /usr/share/doc/termix/BUILD-INFO.txt | head -4
head -2 /usr/share/doc/termix/PLUGINS.txt

Step 12: Backup and maintenance

Back up /var/lib/termix and /etc/termix/secrets together, with Termix stopped (sudo systemctl stop termix); the database cannot be read without this instance's database_key, and saved credentials need encryption_key. Keep the backup as private as the keys themselves. Termix's own data export and import (the Import and Export plugin, off by default) is an alternative for moving hosts to another instance.

Ubuntu security updates install automatically. Termix itself is updated by moving to a newer cloudimg version of this listing.

Step 13: Security recommendations

• Restrict ports 22 and 443 in the security group to your own networks.
• Change the administrator password on first sign-in and turn on two-factor authentication.
• Give each person their own Termix account; do not share the administrator.
• Install only signed plugins (the image enforces it) and only the ones you need.
• Replace the self-signed certificate with a CA-issued one for wider use.

Support and licensing

Termix is open-source software under the Apache License 2.0 (/usr/share/doc/termix/LICENSE); its plugins are Apache-2.0 too. cloudimg provides the hardened image and support for its configuration at support@cloudimg.co.uk. Termix is a project of its own authors; cloudimg is not affiliated with or endorsed by them.