Ubuntu 24.04 LTS Minimal on Azure User Guide
Overview
This guide covers the deployment and configuration of Ubuntu Server 24.04 LTS Minimal on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.
Ubuntu is a widely used Linux distribution produced by Canonical. Version 24.04 is a long term support (LTS) release, with standard security maintenance to 2029. What makes this image different from the standard Ubuntu Server 24.04 LTS image is the package profile: the installed set is trimmed to Canonical's own published Ubuntu Minimal cloud image seed — the package set Canonical themselves define as Minimal — plus the Azure provisioning stack. The result, measured at capture on this exact image: 664 packages on the standard image, 322 on this one (342 fewer), a dpkg payload 902 MiB smaller, and a root filesystem that ships over a gigabyte leaner. Fewer installed packages means a smaller attack surface, fewer packages to patch and scan, and faster update runs.
The image describes itself: a manifest generated from its own package database ships at /usr/share/cloudimg/ubuntu-24-04-minimal.manifest, stating exactly what is installed, what was removed and what that means in practice. Anything you miss is one apt install away from the standard Ubuntu archives.
What's included:
- Ubuntu Server 24.04 LTS with the Minimal package profile: 322 packages, cut to Canonical's published Minimal seed from cloudimg's own hardened standard image
- The full Azure provisioning path, protected from the trim by construction: cloud-init, the Azure Linux Agent (walinuxagent), OpenSSH, netplan, the Azure kernel flavour and its initramfs boot chain
- A shipped manifest and trim ledger derived from the image's own package database — the delta is measured, never asserted
- Every available security update applied at build time, with
unattended-upgradesarmed so the machine keeps patching itself (the update path is part of the Minimal seed) - Automatic root filesystem growth at first boot on larger disks (cloud-init growpart, proven below)
- chrony for NTP time synchronisation
- AppArmor in enforcing mode
- Gen2 Hyper V virtual machine support
- 24/7 cloudimg support
What's deliberately NOT included (matching Canonical's Minimal seed — each is one apt install away): the man command, full screen editors (vim, nano), ping and network diagnostic tools, classic cron (systemd timers remain), rsyslog (journald remains), an NFS client, ufw, and hundreds of libraries and utilities a cloud VM managed by automation never touches.
Platform: Microsoft Azure (Gen2 Hyper V, x64)
Default user: azureuser
Security posture
This image ships with no known credential. There is no default password and no baked in SSH key:
- The root account password is locked, so no one can log in as root with a password.
PasswordAuthenticationis disabled in the SSH daemon, so every login is by key.PermitRootLoginis set toprohibit-password, so root cannot be reached with a password even if one were later set.- The only key that works is the public key you supply when you create the virtual machine. Azure injects it into
azureuserat first boot, so no two machines you launch ever share a secret. - The machine identity and the SSH host keys are regenerated uniquely on every instance, so no two machines share a host key either.
- AppArmor is left enabled and enforcing, the Ubuntu default.
- The trim itself is a security feature: 342 fewer installed packages is 342 fewer things to carry vulnerabilities, patch and audit.
Prerequisites
Before deploying this image, ensure you have:
- An active Microsoft Azure subscription
- Access to the Azure Portal or Azure CLI
- An SSH key pair for Linux VM access
- Familiarity with Azure VM management
Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger. The Minimal profile is also comfortable on Standard_B1s for light duties.
Disk size: the image ships as a 30 GiB OS disk. If you deploy onto a larger disk, the root filesystem grows itself at first boot — no manual steps (see Step 7).
Step 1: Deploy the Virtual Machine
Option A: Azure Portal
- Navigate to the Azure Marketplace and search for "Ubuntu 24.04 LTS Minimal cloudimg"
- Select the image and click Create
- Configure the basics:
- Subscription: Select your Azure subscription
- Resource Group: Create new or select existing
- Virtual Machine Name: Enter a name for your VM
- Region: Select your preferred Azure region
- Size:
Standard_B2srecommended - Under Administrator Account, select SSH public key and enter your key
- Under Inbound Port Rules, allow SSH (port 22)
- On the Disks tab, set the OS disk size you want — the root filesystem will fill it automatically at first boot
- Click Review + Create, then Create
Option B: Azure CLI
az vm create \
--resource-group myResourceGroup \
--name my-ubuntu-minimal-vm \
--image cloudimg:ubuntu-24-04-minimal:ubuntu2404minimal:latest \
--size Standard_B2s \
--os-disk-size-gb 64 \
--admin-username azureuser \
--generate-ssh-keys \
--public-ip-sku Standard
--os-disk-size-gb 64 deploys the 30 GiB image onto a 64 GiB disk. Unlike an LVM layout, nothing further is needed: cloud-init grows the partition and the filesystem to fill the disk during first boot.
Step 2: Connect via SSH
Run these on your own workstation, not on the VM. Find the public IP, then connect:
az vm show --resource-group myResourceGroup --name my-ubuntu-minimal-vm --show-details --query publicIps -o tsv
ssh azureuser@<vm-ip>
There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.
Step 3: Confirm the release and the Minimal profile
Check that the machine is the Ubuntu 24.04 LTS release you expect:
grep -E '^(NAME|VERSION|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release
uname -srm
dpkg --print-architecture
Expected output:
PRETTY_NAME="Ubuntu 24.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.5 LTS (Noble Numbat)"
ID=ubuntu
Linux 6.17.0-1022-azure x86_64
amd64

The -azure kernel matters: this image keeps the Azure kernel flavour of the standard image, with the Hyper V drivers built in — the same arrangement Canonical use for their own Azure images. Then confirm the defining property of this image — the Minimal package profile:
dpkg-query -Wf '${Package}\n' | sed 's/:.*$//' | sort -u | wc -l
df -h /
Expected output on a fresh VM deployed with the default 30 GiB disk:
322
Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 1.3G 27G 5% /

322 packages against the standard image's 664. The trim was performed as a single guarded, simulated first package transaction against Canonical's published Minimal manifest, and the provisioning path (cloud-init, the Azure agent, OpenSSH, netplan, the boot chain) is on the guard's protected list — it cannot be trimmed by construction.
Step 4: Read the shipped manifest
The image states what it is. The manifest is generated from the package database at capture — never written by hand — so it cannot disagree with the machine you are on:
head -8 /usr/share/cloudimg/ubuntu-24-04-minimal.manifest
Expected output:
# Ubuntu 24.04 LTS Minimal — cloudimg shipped manifest
# DERIVED from the dpkg database on this image at 2026-09-11T21:03:26Z (capture time) — never hand-written.
# Baseline: the cloudimg 'Ubuntu Server 24.04 LTS' (std) image this Minimal is cut from.
#
# Measured trim delta vs the std baseline: 664 -> 322 packages (-342), dpkg payload -902 MiB.
# Trim target: Canonical's published Ubuntu 24.04 Minimal cloud-image package seed (manifest sha256 c65cc54232807f02...).
# Guard refusals (candidates KEPT because their removal would cascade a keeper): dracut-install hwdata klibc-utils libdw1t64 libip4tc2 libip6tc2 libklibc libnetfilter-conntrack3 libnfnetlink0 libnftnl11 libnl-3-200 libnl-genl-3-200 libnuma1 libpopt0 libpython3.12t64 libslang2 libtraceevent1 python3-passlib python3-setuptools tzdata-legacy usb.ids
# Installed now: 322 packages, dpkg payload 614 MiB, rootfs used 1288 MiB.
The capability notes further down tell you, in plain terms, what is not on board and how to restore each piece:
sed -n '/capability notes/,/^#$/p' /usr/share/cloudimg/ubuntu-24-04-minimal.manifest
Expected output:
# --- capability notes, each DERIVED from a probe on this image ---
NFS: this image has NO NFS client. nfs-common is not part of the Ubuntu Minimal seed,
NFS: so 'mount -t nfs' will not work as shipped. Restore it with: sudo apt install nfs-common
MAN: no man command (man-db is not part of the Minimal seed). Restore with: sudo apt install man-db
CRON: no classic cron daemon (cron is not part of the Minimal seed); systemd timers
CRON: provide scheduling. Restore classic cron with: sudo apt install cron
EDITOR: no full-screen editor ships (matching Canonical's Minimal seed).
EDITOR: Install one with: sudo apt install nano (or vim)
PROVISIONING: cloud-init 26.1 + walinuxagent 2.15.0.1 are installed — the full Azure provisioning path is retained.
KERNEL: 6.17.0-1022-azure (the Azure kernel flavour — Hyper-V drivers built in, matching Canonical's own Azure minimal SKUs).
UPDATES: unattended-upgrades is installed and armed — security updates auto-apply, exactly as on the std image.
DOCS: unlike Canonical's minimal cloud image, this image does NOT strip documentation of
DOCS: RETAINED packages at the dpkg level — the trim is package-level; /usr/share/doc of the kept set is intact.

The full installed package list follows the notes in the same file, one package per line with its version — useful for compliance snapshots and drift comparisons.
Step 5: Check the patch level
The image is fully updated at build time. Confirm that no upgrades are pending and that the update path is intact:
apt-get -s -o APT::Get::Always-Include-Phased-Updates=true dist-upgrade | grep -c '^Inst ' | sed 's/^/pending upgrades: /'
apt-mark showhold
dpkg -l | awk '/^ii linux-image-[0-9]/{print $2, $3}'
Expected output shows pending upgrades: 0, no held packages, and exactly one installed Azure kernel:
pending upgrades: 0
linux-image-6.17.0-1022-azure 6.17.0-1022.22
The Always-Include-Phased-Updates=true flag matters on Ubuntu: without it, a plain check can silently hide phased security updates held back on this particular machine. This image also arms unattended-upgrades — which is part of Canonical's Minimal seed, so automatic security updates survive the trim by design. You can still run updates on your own schedule:
sudo apt-get update && sudo apt-get -y dist-upgrade
Reboot if a new kernel was installed:
sudo systemctl reboot
Step 6: Verify the security posture
Confirm AppArmor is enforcing, root is locked, and SSH is key only:
sudo aa-status --enabled && echo "apparmor: enabled"
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
Expected output:
apparmor: enabled
root L 2009-12-22 -1 -1 -1 -1
permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication no

without-password is how OpenSSH reports the prohibit-password setting. Both names mean the same thing: root may not authenticate with a password. The L from passwd -S means the root account is locked.
Step 7: Disk growth — automatic on this image
If you deployed onto a disk larger than 30 GiB (as in the Step 1 CLI example), there is nothing to do: this image keeps the standard flat root layout, and cloud-init's growpart module extends the root partition and filesystem during first boot. Confirm it:
df -h /
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT "$(readlink -f /dev/disk/azure/root)"
Expected output on a 64 GiB disk, exactly as produced by this image:
Filesystem Size Used Avail Use% Mounted on
/dev/root 61G 1.3G 60G 3% /
NAME SIZE TYPE MOUNTPOINT
sda 64G disk
|-sda1 63G part /
|-sda14 4M part
|-sda15 106M part /boot/efi
`-sda16 913M part /boot
The proof of the automatic grow is in cloud-init's own log:
grep 'resized' /var/log/cloud-init.log | tail -1
Expected output (byte counts vary with your disk size):
2026-09-11 19:23:20,360 - cc_growpart.py[INFO]: '/' resized: changed (/dev/disk/by-partuuid/054c3354-42bf-4a6d-8c6f-2cf42bd83e63) from 31138496000 to 67644669440
Growing an existing VM later: enlarge the OS disk (deallocate the VM, az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, start the VM — or use the portal's Disks blade). cloud-init grows the root again on the next boot; no manual partitioning is ever needed on this layout.
Step 8: Networking and the firewall
The Azure Network Security Group is the control plane for inbound and outbound traffic, and it is the first and usually the only place you need to open a port. The image advertises a single inbound port, SSH on 22. Confirm what is listening:
sudo ss -tlnp
Expected output — sshd on port 22 (IPv4 and IPv6), and systemd-resolved on the loopback-only stub addresses:
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1098,fd=3),("systemd",pid=1,fd=98))
LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=564,fd=17))
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=564,fd=15))
LISTEN 0 4096 [::]:22 [::]:* users:(("sshd",pid=1098,fd=4),("systemd",pid=1,fd=99))
ufw is not installed on this image — it is not part of Canonical's Minimal seed. The NSG is the enforced firewall, which is the normal arrangement on Azure. If your policy requires a host firewall as well, install and enable one, adding the SSH rule first so you do not lock yourself out:
sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw enable
Once ufw is running, a port must be open in both the Azure NSG and ufw before traffic reaches your service. (The iptables layer itself is present — the Azure agent uses it to protect the platform metadata endpoint.)
Step 9: Install software
The trim removes nothing from your reach: the machine points at the standard Ubuntu archives, and every removed package — and anything else in the archive — installs normally. Search, then install what you need:
apt-cache search --names-only '^nginx' 2>/dev/null | sed -n '1,3p'
Install a package and enable it in the usual way, for example sudo apt-get install -y nginx followed by sudo systemctl enable --now nginx. The everyday absences and their one-line restores are in the shipped manifest (Step 4): man-db for manual pages, nano or vim for an editor, iputils-ping for ping, cron for classic cron jobs, nfs-common for NFS mounts.
To add another administrator, create the account with sudo adduser <name>, add it to the sudo group with sudo usermod -aG sudo <name>, then copy your public key into /home/<name>/.ssh/authorized_keys with mode 600 and the .ssh directory mode 700, owned by that user. The image ships with no human accounts at all, so azureuser is the only login until you add one:
getent group sudo
Expected output:
sudo:x:27:azureuser
Common Use Cases
- Container and automation hosts that want the smallest practical Ubuntu base under their workloads
- Security conscious deployments: fewer installed packages to patch, scan and audit
- Fleets managed entirely by SSH and configuration management, where interactive niceties are dead weight
- A fast booting, quick patching Ubuntu LTS base for ephemeral and scale out workloads
Troubleshooting
Cannot connect via SSH
- Verify the VM is in Running state in the Azure Portal
- Check that port 22 is allowed in the Network Security Group
- Ensure you are using the correct username:
azureuser - Verify your SSH key matches the one you supplied at create time. Password login is disabled by design, so a wrong key cannot fall back to a password prompt.
To see which key your client is actually offering, run ssh -v azureuser@<vm-ip> from your workstation and look for the Offering public key lines.
"command not found" for man, vim, nano, ping or crontab
Expected — those tools are not part of Canonical's Minimal seed this image is cut to. Each is one command away (see the shipped manifest, Step 4): sudo apt install man-db, sudo apt install nano, sudo apt install iputils-ping, sudo apt install cron. Until an editor is installed, remember that sed -i and here-documents cover most quick edits, and systemctl edit opens its own fallback editor.
df shows 29G on a bigger disk
The automatic grow runs during first boot. If you resized the disk while the VM was running, the VM has not rebooted since the disk grew — reboot once (sudo systemctl reboot) and cloud-init claims the space. Check the evidence trail in /var/log/cloud-init.log: a cc_growpart line reading '/' resized: changed means the grow ran; '/' NOCHANGE: no change necessary means the partition already fills the disk.
Azure agent not running
sudo systemctl status walinuxagent
sudo systemctl enable --now walinuxagent
Package manager issues
Refresh the metadata cache first:
sudo apt-get update
If repositories are unreachable, check DNS resolution. getent is always present and resolves through the same system resolver:
getent hosts archive.ubuntu.com
A service is blocked and the logs mention AppArmor
AppArmor is enforcing on this image. A healthy machine has no denials — measured on this exact build:
sudo journalctl -k --no-pager | awk '/apparmor/ && /DENIED/{n++} END{print "apparmor denials: " n+0}'
Expected output:
apparmor denials: 0
If you see denials after installing software, the denied profile's name appears in the log line — adjust or disable that one profile rather than turning AppArmor off.
Important Notes
Ubuntu is free and open source. It is not covered by a single licence: it is a distribution assembled from thousands of independently packaged components, each carrying its own terms, including the GPL, LGPL, MIT, BSD, Apache 2.0 and MPL. Every package's terms are readable with dpkg -s <package> and under /usr/share/doc/<package>/copyright. No subscription or licence key is required to run this image; Ubuntu Pro is an optional Canonical subscription that is neither included nor required here.
Ubuntu 24.04 LTS receives standard security maintenance until 2029. Plan a move to a newer LTS image before that date for workloads that need to outlive it.
This image's Minimal profile is package level: the installed set matches Canonical's published Minimal cloud image seed (plus the Azure provisioning stack), while documentation belonging to the packages that remain is kept on disk. Canonical's own minimal cloud image additionally strips documentation files at the dpkg level; if you want that behaviour you are better served installing their image outside the Marketplace — this image chooses the less surprising default.
Ubuntu is a trademark of Canonical Ltd. The name is used here nominatively, only to identify the distribution this image contains. cloudimg is not affiliated with, endorsed by or sponsored by Canonical Ltd.
Support
For assistance with this image, contact cloudimg support:
- Website: www.cloudimg.co.uk
- Product Catalogue: www.cloudimg.co.uk/products
- User Guides: www.cloudimg.co.uk/guides
- SLA: 24 hour response guaranteed