Cloud Commander on AWS User Guide

Overview

This image runs Cloud Commander 19.19.1, the open source web based orthodox (two panel) file manager with a built in Edward text editor and the full set of file operations - browse, create, rename, copy, move, delete, pack and unpack, upload and download - on Ubuntu 24.04 LTS. Cloud Commander (cloudcmd) is installed globally with npm on the Node.js 22 LTS runtime and runs as an unprivileged cloudcmd system account under a systemd service that starts it on boot and restarts it on failure.

Cloud Commander listens on the loopback address 127.0.0.1:8000 by design and is never exposed directly. nginx terminates TLS on port 443 and reverse proxies to the loopback listener, forwarding the WebSocket upgrades Cloud Commander uses for its live channel. Port 80 redirects to HTTPS, and an unauthenticated /healthz endpoint (served by nginx itself) is available on both ports for load balancer health checks.

The image is secure by default. Cloud Commander ships upstream with authentication turned off and a well known default login - the exact anti-pattern this image avoids. Here authentication is on, and on the first boot of every deployed instance a one-shot service generates a fresh per-instance admin credential, writes only a one way hash of the password into the server configuration, regenerates a per-instance self signed TLS certificate, and writes the plain credential to /root/cloudcmd-credentials.txt (mode 0600, readable only by root). Two instances launched from the same AMI never share a credential, and no default or shared password ships in the image. The built in terminal and console are disabled by default to minimise the attack surface; you can enable them behind the same authentication if you need them (see Step 7).

The file manager root is a dedicated managed workspace at /srv/cloudcmd, which lives on its own independently resizable EBS data volume kept separate from the operating system disk - not the whole operating system filesystem.

The default security group for this listing opens port 22 (SSH), port 80 (HTTP, redirect + health) and port 443 (HTTPS).

Self signed certificate. The per-instance TLS certificate is self signed, so your browser will show a warning the first time you connect. This is expected. For production, install a CA signed certificate for a real domain (see Step 8) or terminate TLS at an AWS load balancer.

Prerequisites

• An AWS account subscribed to this product in AWS Marketplace.
• An EC2 key pair in your target region for SSH access.
• A security group allowing inbound TCP 22 (SSH) from your IP, and TCP 443 (HTTPS) - and optionally TCP 80 - from your users.
• Recommended instance type: m5.large or larger.

Connecting to your instance

SSH in as the default login user for your operating system variant, using the key pair you launched with.

Step 1 - Launch from the AWS Marketplace console

1. Open the product page in AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration.
2. Select the software version and your AWS Region, then choose Continue to Launch.
3. Choose an instance type (m5.large or larger), your VPC subnet, the security group described above, and your EC2 key pair.
4. Launch the instance and wait for it to reach the running state with status checks passed.

Step 2 - Launch from the AWS CLI (alternative)

Replace the AMI id, key name, security group and subnet with your own values:

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type m5.large \
  --key-name your-key \
  --security-group-ids sg-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cloud-commander}]'

Cloud Commander's first boot resolves the instance's public IPv4 through IMDSv2, so launching with HttpTokens=required (IMDSv2) is fully supported.

Step 3 - Retrieve the per-instance admin credential

Each instance generates its own admin username and password on first boot and stores them in a root only file. SSH in and read it:

sudo cat /root/cloudcmd-credentials.txt

You will see the generated CLOUDCMD_USER, CLOUDCMD_PASS and the CLOUDCMD_URL for this instance. Keep this file secret - it is readable only by root (0600).

Step 4 - Sign in to the web file manager

Browse to your instance over HTTPS and sign in with the credential from Step 3:

https://<instance-public-ip>/

Your browser will warn about the self signed certificate the first time - accept it to continue (or install a real certificate, Step 8). Cloud Commander then prompts for the username and password. After signing in you get the two panel file manager:

The two panels let you browse two locations at once - the classic orthodox layout - and the function key bar along the bottom exposes the file operations (view, edit, copy, move, make directory, delete and more).

Step 5 - Browse, upload and download files

Click a folder to open it. Each entry shows its size, date, owner and permissions:

• Upload: drag files onto the panel, or use the upload action, to copy files from your computer into the current folder.
• Download: select a file and download it, or open it directly.
• Copy / move: select items in one panel and copy (F5) or move (F6) them to the folder open in the other panel.
• New folder / delete / rename: use the function key bar or the right click menu.

All files live under the managed root /srv/cloudcmd on the dedicated data volume.

Step 6 - Edit files in the built in editor

Select a text file and press F4 (Edit) to open it in Cloud Commander's built in Edward editor, with syntax highlighting for common formats:

Save with the editor's save action and close it to return to the file panels. This lets you make quick edits to configuration and text files straight from the browser, with no SSH session or desktop needed.

Step 7 - Verify the service and the security posture

You can confirm the appliance is healthy and correctly hardened at any time over SSH.

Check the services are running and the pinned version:

systemctl is-active cloudcmd.service nginx.service
cat /opt/cloudcmd/VERSION

Confirm Cloud Commander is bound to loopback only, that port 80 redirects to HTTPS, that the health endpoint answers, and that the API refuses unauthenticated access:

ss -tlnH | awk '{print $4}' | grep -E ':(443|8000)$' | sort -u
curl -s -o /dev/null -w 'http_80_root=%{http_code}\n' http://127.0.0.1/
curl -sk -o /dev/null -w 'healthz=%{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'unauth_api=%{http_code}\n' https://127.0.0.1/api/v1/fs/

You should see 127.0.0.1:8000 as the only Cloud Commander listener (nginx owns 443), http_80_root=301, healthz=200, and unauth_api=401 - the API rejects any request without the admin credential.

Run the built in self test, which proves the full authenticated round trip - it verifies an unauthenticated request is refused, an authenticated listing succeeds, and a file uploaded through the API downloads back byte for byte:

sudo /usr/local/bin/cloudcmd-selftest

Confirm authentication is on and the terminal and console are disabled in the server configuration:

sudo grep -E '"(auth|terminal|console)"' /opt/cloudcmd/.cloudcmd.json

Step 8 - Change the file manager root (optional)

By default the file manager is confined to /srv/cloudcmd. To point it somewhere else - for example a mounted data disk - edit the root value in the server configuration and restart the service:

sudo nano /opt/cloudcmd/.cloudcmd.json     # change "root": "/srv/cloudcmd"
sudo systemctl restart cloudcmd

Make sure the cloudcmd system user can read (and, if you want to write, write) the new location.

Step 9 - Enable the built in terminal or console (optional)

The built in terminal and console give a shell inside the browser and are disabled by default because they are a powerful remote shell surface. If you understand the risk and want them, enable them behind the same authentication and TLS by setting the values in the configuration and restarting:

sudo nano /opt/cloudcmd/.cloudcmd.json     # set "terminal": true and/or "console": true
sudo systemctl restart cloudcmd

Only enable these on instances that are restricted to trusted networks - they are as powerful as SSH.

Step 10 - Install a CA signed certificate for a real domain (optional)

The image ships a per-instance self signed certificate. For production, point a DNS name at the instance and install a CA signed certificate. The simplest route is Let's Encrypt with certbot:

sudo apt-get update
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

certbot obtains the certificate and updates the nginx server block automatically. Alternatively, terminate TLS at an AWS Application Load Balancer or CloudFront in front of the instance.

Maintenance

• Services: sudo systemctl status cloudcmd nginx shows service health; both restart automatically on failure.
• Logs: sudo journalctl -u cloudcmd -e for the application, sudo journalctl -u nginx -e for the proxy.
• Updates: keep the operating system patched with sudo apt-get update && sudo apt-get upgrade. Cloud Commander itself is a global npm package (cloudcmd); upgrade guidance is available from cloudimg support.
• Backups: back up the managed workspace at /srv/cloudcmd (its own EBS volume) with EBS snapshots or your preferred backup tooling.
• Data volume: the workspace volume is independently resizable - grow it in the EC2 console and extend the filesystem without touching the operating system disk.

Support

cloudimg provides 24/7 technical support for this product by email and live chat, with a one hour average response for critical issues. We help with deployment, signing in, changing the file manager root, enabling the terminal safely, installing a CA signed certificate and using a real domain, TLS termination with AWS load balancers, backups and scaling.

• Email: support@cloudimg.co.uk
• Live chat: available 24/7