Cloud Commander on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Cloud Commander on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Cloud Commander (cloudcmd) is an open source, web based file manager with the classic two panel (orthodox) layout and a built in text editor. It lets you browse, create, rename, copy, move, delete, pack, upload and download files on a server from any device with a browser, without exposing SSH or a remote desktop.

The image installs the latest stable Cloud Commander release from the npm registry and pins the exact version (recorded in /opt/cloudcmd/VERSION). Cloud Commander runs on Node.js 22 LTS under systemd as the unprivileged cloudcmd system user and binds to loopback only (127.0.0.1:8000). nginx is the sole network facing surface and terminates TLS on port 443, reverse proxying to Cloud Commander. Port 80 redirects to HTTPS.

Secure by default. Cloud Commander ships upstream with authentication turned off and a well known default login, which would leave an unprotected deployment open to anyone who can reach it. This image turns authentication on and generates a unique administrator credential on each virtual machine's first boot. Only a one way hash of the password is written to the server configuration; the plain password is placed in a root only file for the administrator to read. There are no shared or default credentials, and nothing is baked into the image. The built in terminal and console are disabled to keep the attack surface minimal, and the file manager root is a dedicated managed workspace at /srv/cloudcmd rather than the whole operating system filesystem.

What is included:

• The latest stable Cloud Commander release, installed from npm on Node.js 22 LTS and run under systemd as the unprivileged cloudcmd system user

• Cloud Commander bound to loopback only (127.0.0.1:8000); it is never network exposed directly

• nginx terminating TLS on :443 and reverse proxying to Cloud Commander, with HSTS and sensible security headers, forwarding WebSocket upgrades for the live interface

• Port :80 returns a 301 redirect to HTTPS for every path except an unauthenticated /healthz endpoint (HTTP 200) for load balancer probes

• Authentication on by default with a unique admin credential generated per VM on first boot; only the one way hash is stored in the server config, the plain password lands in a root only file

• The built in terminal and console disabled by default to minimise the attack surface (re enable behind the same login if you need them)

• A self signed TLS certificate regenerated per VM on first boot (its Subject Alternative Names include the VM public IP, hostname and 127.0.0.1); replace it with your own CA signed certificate for production

• A built in self test at /usr/local/bin/cloudcmd-selftest that proves the authenticated upload and download round trip end to end over TLS

• Ubuntu 24.04 LTS base with the latest security patches applied at build time

• Azure Linux Agent for seamless cloud integration and SSH key injection

• 24/7 cloudimg support with a guaranteed 24 hour response SLA

Prerequisites

• An Azure subscription with permission to deploy virtual machines

• An SSH key pair for administrative access to the VM as the azureuser account

• A Network Security Group allowing inbound TCP 443 (HTTPS) and 80 (redirect) from the networks that should reach the service, and 22 (SSH) from your management network only

• A recommended size of Standard_B2s or larger

Step 1: Deploy from the Azure Portal

1. Locate the Cloud Commander on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.

2. Choose your subscription, resource group and region.

3. Select a VM size (Standard_B2s or larger) and provide your SSH public key for the azureuser account.

4. On the Networking tab, allow inbound 443 and 80 from your users, and restrict 22 to your management network.

5. Review and create. When the VM is running, browse to https://<your-public-ip>/.

Step 2: Deploy from the Azure CLI

Deploy the image from the command line, restricting SSH to your management network. Replace the placeholder values with your own before running:

az vm create \
  --resource-group my-resource-group \
  --name cloudcmd \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

# Allow the web UI from your users and SSH from your management network only
az vm open-port --resource-group my-resource-group --name cloudcmd --port 443 --priority 1001
az network nsg rule create --resource-group my-resource-group --nsg-name cloudcmdNSG \
  --name allow-ssh --priority 1002 --destination-port-ranges 22 \
  --source-address-prefixes <your-mgmt-cidr> --access Allow --protocol Tcp

When the VM is running, browse to https://<public-ip>/.

Step 3: Retrieve your per instance admin credential

Authentication is on by default. Each VM generates its own admin username and password on first boot, written to a root only file. Read it over SSH:

ssh azureuser@<vm-ip> 'sudo cat /root/cloudcmd-credentials.txt'

The file contains the CLOUDCMD_USER, CLOUDCMD_PASS and CLOUDCMD_URL for this specific VM. Keep it secret. The server configuration only ever stores a one way hash of the password, never the plain text.

Step 4: Sign in to the web interface

Browse to https://<vm-ip>/. Because the certificate is self signed per VM, your browser will show a certificate warning the first time; accept it to proceed (or install the per VM certificate, or place a CA signed certificate in front, as covered in Step 9). Sign in with the username and password from Step 3.

Cloud Commander presents its classic two panel file manager, with the function key bar along the bottom for common operations. The left and right panels can each browse a different directory, which makes copying and moving files between locations straightforward.

Double click a folder to open it in the active panel. Here the left panel has navigated into the documents folder while the right panel stays at the workspace root, ready to copy files between the two.

Step 5: Edit files with the built in editor

Select a text file and press F4 (or double click it) to open the built in editor. Edits are saved straight back to the server. This is convenient for tweaking configuration files or notes without opening an SSH session.

Step 6: Work with files and the operations bar

Click a file to select it, then use the function key bar or the on screen buttons to act on it: F3 view, F4 edit, F5 copy, F6 move or rename, F7 new folder, F8 delete. Uploading is a drag and drop into the panel, and downloading is available from the file menu. All operations run as the unprivileged cloudcmd user within the managed workspace.

Step 7: Verify the deployment

SSH to the VM as azureuser and confirm the services are running and Cloud Commander is bound to loopback only:

systemctl is-active cloudcmd nginx
sudo ss -tlnp | grep 8000

Both services report active, and Cloud Commander listens on 127.0.0.1:8000 only. nginx is the only component exposed on :80 and :443.

Run the built in self test. It reads this VM's credential and proves the full authenticated round trip over TLS: an unauthenticated request is refused, an authenticated directory listing succeeds, and a test file is uploaded then downloaded back byte for byte:

sudo /usr/local/bin/cloudcmd-selftest

Step 8: TLS and the per instance certificate

nginx terminates TLS on port 443 and redirects plain HTTP on port 80 to HTTPS. Confirm the redirect and the unauthenticated health probe from the VM:

curl -s -o /dev/null -w 'port 80 -> HTTP %{http_code}\n' http://127.0.0.1/
curl -sk -o /dev/null -w 'healthz over TLS -> HTTP %{http_code}\n' https://127.0.0.1/healthz

Port 80 returns 301 and the health endpoint returns 200. An unauthenticated request to the file API is refused with 401, while a request carrying this VM's credential succeeds with 200. The self signed certificate is regenerated per VM on first boot, with the VM IP and hostname in its Subject Alternative Names:

Step 9: Replace the certificate for production

The per VM certificate is self signed, so browsers warn on first use. For a public deployment, put a real certificate in front. The simplest path is to point a DNS name at the VM and obtain a free certificate with Certbot:

# Point https://<your-domain> at this VM first, then:
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Alternatively, terminate TLS at an Azure Application Gateway or a load balancer in front of the VM and forward to port 443.

Step 10: Change the workspace root or enable the terminal

By default the file manager is rooted at /srv/cloudcmd and the built in terminal and console are disabled for security. Both are controlled by /opt/cloudcmd/.cloudcmd.json. To point the manager at a different directory, or to enable the terminal behind the existing login, edit that file and restart the service. Browse back to https://<vm-ip>/ afterwards:

# Edit the root ("root": "/srv/cloudcmd") or enable the terminal ("terminal": true),
# then apply the change. Browse to https://<vm-ip>/ afterwards.
sudo nano /opt/cloudcmd/.cloudcmd.json
sudo systemctl restart cloudcmd

The baked version and this VM's credential summary are recorded on the VM. The password line is redacted below; read the full value from the root only file in Step 3:

Security notes

• No default login. Authentication is on by default and a unique admin credential is generated on each VM's first boot. Only a one way hash is stored in the server configuration; the plain password lives in the root only /root/cloudcmd-credentials.txt.

• Loopback only application. Cloud Commander binds to 127.0.0.1:8000 and is only reachable through the nginx TLS reverse proxy on :443. Keep it that way and let nginx (or a load balancer) be the sole network facing surface.

• Terminal and console disabled. The built in remote shell surfaces are off by default. Only enable them (Step 10) if you understand that they grant command execution as the cloudcmd user to anyone who signs in.

• Scope the workspace. The manager is rooted at a dedicated /srv/cloudcmd workspace, not the whole filesystem. Keep the root scoped to the data you intend to manage.

• Restrict access. Allow 443 only from the networks that need it, keep 22 restricted to your management network, and replace the self signed certificate with a CA signed one for production.

• Rotate the credential by regenerating it and restarting the service, or by placing your own identity aware proxy in front.

Support

This image is backed by 24/7 cloudimg support with a guaranteed 24 hour response SLA. Contact support@cloudimg.co.uk for assistance. Cloud Commander is open source software distributed under the MIT License and is free; the cloudimg charge covers packaging, hardening, security patching, image maintenance and support.