Ubuntu 22.04 LVM

Option A: Azure Portal

• Go to the Azure Marketplace and search for "Ubuntu 22.04 LTS LVM SecureAnyCloud".
• Select the image and click Create.
• On the basics tab, set Subscription to your Azure subscription, Resource Group to a new or existing group, Virtual Machine Name to a name for your VM, and Region to your preferred Azure region.
• Set Size to Standard_B2s (recommended).
• 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. Choose a size larger than 30 GiB if you plan to grow the root.
• Click Review + Create, then click Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:ubuntu-22-04-lvm:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-ubuntu-lvm-vm \
  --image sac1647283583153:ubuntu-22-04-lvm:default: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. The extra space is claimed in Step 7 with three LVM commands, online.

Run these commands on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-ubuntu-lvm-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks for one, your client is not offering the key that you supplied at create time.

Check that the machine runs the Ubuntu 22.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 22.04.5 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.5 LTS (Jammy Jellyfish)" ID=ubuntu Linux 6.8.0-1065-azure x86_64 amd64

Then confirm the defining property of this image, the root filesystem on an LVM logical volume:

findmnt -no SOURCE,FSTYPE /
sudo pvs
sudo vgs
sudo lvs

Expected output on a fresh VM deployed with the default 30 GiB disk:

/dev/mapper/ubuntu--vg-ubuntu--lv ext4 PV VG Fmt Attr PSize PFree /dev/sda3 ubuntu-vg lvm2 a-- <27.50g 0 VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 1 0 wz--n- <27.50g 0 LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert ubuntu-lv ubuntu-vg -wi-ao---- <27.50g

/ on /dev/mapper/ubuntu--vg-ubuntu--lv is what the standard image cannot give you: a root volume that you can extend online and a volume group that you can reshape. The disk is GPT with a 512 MiB EFI system partition, a 2 GiB /boot partition, and the rest as the LVM physical volume. That boot partition is a plain partition so the bootloader never depends on LVM activation. VFree 0 is deliberate. The root volume takes every extent, and growth comes from enlarging the disk, not from space held back.

The image is fully updated at build time. Confirm that no upgrades are pending and that the update path works:

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 '/linux-image-[0-9]/{print $2, $3}'

Expected output shows pending upgrades: 0, no held packages, and the installed Azure kernel:

pending upgrades: 0 linux-image-6.8.0-1065-azure 6.8.0-1065.73~22.04.1

The Always-Include-Phased-Updates=true flag matters on Ubuntu. Without it, a plain check can hide phased security updates that are held back on this machine. This image also arms unattended-upgrades, so security updates are downloaded and applied on a timer without any action from you. 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

Confirm that 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 12/22/2009 -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 in the passwd -S output means the root account is locked.

Confirm that the Azure Linux Agent, cloud-init and time synchronization are healthy, that unattended security updates are armed, and check your resources:

systemctl is-active walinuxagent 2>/dev/null || systemctl is-active waagent cloud-init --version
systemctl is-enabled apt-daily-upgrade.timer apt-config dump | grep -E 'APT::Periodic::(Update-Package-Lists|Unattended-Upgrade) '
systemctl is-active chrony df -h /

Expected output:

active /usr/bin/cloud-init 26.1-0ubuntu1~22.04.1 enabled APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; active Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 27G 1.9G 24G 8% /

The Azure Linux Agent lets Azure provision your SSH key, run extensions and report VM health, so it should always be active. When apt-daily-upgrade.timer is enabled and the apt periodic config contains Unattended-Upgrade "1", the machine keeps applying security updates on its own after launch.

This step is the reason to choose the LVM image. If you deployed with an OS disk larger than 30 GiB (as in the Step 1 CLI example), the extra space sits unclaimed beyond the LVM partition. You claim it on the running system with no reboot, no unmount and no downtime.

First, note that cloud-init does not claim the space for you. This was measured on this image. The growpart module skips LVM roots by design, and /var/log/cloud-init.log records '/' SKIPPED: Resizing mapped device (/dev/mapper/ubuntu--vg-ubuntu--lv) skipped as it is not encrypted.. On first boot the partition, the physical volume and the root volume therefore stay at their shipped 27.5 GiB. This is standard Ubuntu behavior for an LVM root, and it leaves you in control of when and how the space is used. The chain below claims all of the space into /. Run it as is, or stop after pvresize to keep the space free in the volume group for other volumes.

DISK="$(readlink -f /dev/disk/azure/root)"
sudo growpart "${DISK}" 3
sudo pvresize "${DISK}3"
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv df -h /
FREE=$(sudo vgs --noheadings -o vg_free_count ubuntu-vg | tr -dc '0-9')
PVB=$(sudo pvs --noheadings --units b --nosuffix -o pv_size "${DISK}3" | tr -dc '0-9')
PARTB=$(( $(cat /sys/class/block/$(basename "${DISK}")3/size) * 512 )) if [ "${FREE:-1}" -ne 0 ]; then echo "FAIL: ${FREE} free extents remain in VG ubuntu-vg"; exit 1; fi if [ "$(( PARTB - PVB ))" -gt 8388608 ]; then echo "FAIL: pvresize did not take - partition ${PARTB}B vs physical volume ${PVB}B"; exit 1; fi echo "root volume fully extended: 0 free extents in VG ubuntu-vg, and the physical volume fills the partition"

Expected output on a 64 GiB disk, as produced by this image:

CHANGED: partition=3 start=5244928 old: size=57667584 end=62912512 new: size=128972767 end=134217695 Physical volume "/dev/sda3" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized Size of logical volume ubuntu-vg/ubuntu-lv changed from <27.50 GiB (7039 extents) to <61.50 GiB (15743 extents). Logical volume ubuntu-vg/ubuntu-lv successfully resized. Filesystem at /dev/ubuntu-vg/ubuntu-lv is mounted on /; on-line resizing required old_desc_blocks = 4, new_desc_blocks = 8 The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 16120832 (4k) blocks long. Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 61G 1.9G 56G 4% / root volume fully extended: 0 free extents in VG ubuntu-vg, and the physical volume fills the partition

The resize2fs output says on-line resizing required, and it resizes the mounted root, so the whole chain runs on the live system. Keep the two checks at the end in your own automation. A vg_free_count of 0 proves that lvextend claimed everything. A physical volume that fills the partition (to within LVM's small metadata gap) proves that pvresize took effect. Each check catches a failure that the other cannot see.

If the disk is already fully claimed, growpart reports NOCHANGE and exits non zero, lvextend reports that the size already matches, and the final checks still pass. The chain is safe to re-run.

Growing an existing VM later: enlarge the OS disk first. Deallocate the VM, run az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, and start the VM, or use the portal's Disks blade. Then run the same chain. The LVM layout also lets you go further than root growth. Attach a data disk and add it to the volume group with sudo pvcreate on the new disk's partition and sudo vgextend ubuntu-vg. Then create dedicated volumes for data or logs with sudo lvcreate, all without touching the root filesystem.

The Azure Network Security Group controls inbound and outbound traffic, and it is usually the only place where you need to open a port. The image advertises a single inbound port, SSH on 22.

ufw (the Uncomplicated Firewall) is available on this image but inactive by default. It does not filter traffic, so your NSG rules take effect as written, with no second layer to keep in sync. Confirm what is listening before you open anything:

sudo ss -tlnp

On a fresh machine the listeners are sshd on port 22 (IPv4 and IPv6) and systemd-resolved on the loopback-only 127.0.0.53:53. Only port 22 is advertised for inbound access, and the Azure NSG governs what is reachable from outside.

If your policy also requires a host firewall, enable the one that is already installed. Add the SSH rule before you enable the firewall, so that you do not lock yourself out:

sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable

Once ufw is running, open each port in both the Azure NSG and ufw before traffic can reach your service.

The Ubuntu archive carries the application packages. Search the archive, then install what you need:

apt-cache search nginx 2>/dev/null | sed -n '1,5p'

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.

To add another administrator, create the account with sudo adduser <name> and add it to the sudo group with sudo usermod -aG sudo <name>. Then copy your public key into /home/<name>/.ssh/authorized_keys, set mode 600 on the file and mode 700 on the .ssh directory, and make that user the owner of both. The image ships with no human accounts, so azureuser is the only login until you add one:

getent group sudo

Expected output:

sudo:x:27:azureuser

Option A: AWS Marketplace console

• Open the SecureAnyCloud Ubuntu listing on AWS Marketplace. Choose Continue to Subscribe, then Continue to Configuration.
• Under Software version, choose Ubuntu 22.04 LTS LVM. Pick your Region and choose Continue to Launch.
• Choose Launch through EC2 to open the full launch wizard.
• Pick an instance type (m5.large is recommended) and your key pair.
• Under Network settings, allow SSH (port 22) from My IP only.
• Under Configure storage, set the root volume size you want (12 GiB minimum). Extra space is added to the disk but is not allocated to a volume until you choose where it goes (Step 12).
• Choose Launch instance.

Option B: AWS CLI

Run this command on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and replace the key pair, security group and subnet with your own. The root device of this AMI is /dev/xvda:

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --block-device-mappings 'DeviceName=/dev/xvda,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ubuntu-lvm}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required.

From your workstation, connect as ubuntu with the key pair you chose:

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

There is no password to enter. If SSH asks for one, or says Too many authentication failures, see Troubleshooting below.

You can also connect without opening port 22 through AWS Systems Manager Session Manager, if the instance has an instance profile that allows Systems Manager. The agent is installed and running on this image.

grep -E '^(NAME|VERSION|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release uname -srm dpkg --print-architecture

Expected output:

PRETTY_NAME="Ubuntu 22.04.5 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.5 LTS (Jammy Jellyfish)" ID=ubuntu Linux 6.8.0-1066-aws x86_64 amd64

The -aws kernel is Canonical's kernel flavor for EC2, with the Nitro network and NVMe drivers built in. Your kernel version may be newer if updates have installed since this image was built.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/nvme0n1
sudo vgs
sudo lvs -o lv_name,lv_size,lv_path ubuntu-vg findmnt -lo TARGET,SOURCE,OPTIONS -t ext4,vfat

Expected output with the default 12 GiB root volume:

NAME SIZE TYPE FSTYPE MOUNTPOINTS nvme0n1 12G disk ├─nvme0n1p1 1M part ├─nvme0n1p2 200M part vfat /boot/efi ├─nvme0n1p3 1G part ext4 /boot └─nvme0n1p4 10.8G part LVM2_member ├─ubuntu--vg-root 4G lvm ext4 / ├─ubuntu--vg-home 1G lvm ext4 /home ├─ubuntu--vg-tmp 1G lvm ext4 /tmp ├─ubuntu--vg-var 1.5G lvm ext4 /var ├─ubuntu--vg-var_tmp 512M lvm ext4 /var/tmp ├─ubuntu--vg-var_log 1G lvm ext4 /var/log └─ubuntu--vg-var_log_audit 1G lvm ext4 /var/log/audit VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 7 0 wz--n- 10.80g 820.00m LV LSize Path home 1.00g /dev/ubuntu-vg/home root 4.00g /dev/ubuntu-vg/root tmp 1.00g /dev/ubuntu-vg/tmp var 1.50g /dev/ubuntu-vg/var var_log 1.00g /dev/ubuntu-vg/var_log var_log_audit 1.00g /dev/ubuntu-vg/var_log_audit var_tmp 512.00m /dev/ubuntu-vg/var_tmp TARGET SOURCE OPTIONS / /dev/mapper/ubuntu--vg-root rw,relatime /boot /dev/nvme0n1p3 rw,nosuid,nodev,relatime /tmp /dev/mapper/ubuntu--vg-tmp rw,nosuid,nodev,noexec,relatime /var /dev/mapper/ubuntu--vg-var rw,nosuid,nodev,relatime /boot/efi /dev/nvme0n1p2 rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=winnt,errors=remount-ro /home /dev/mapper/ubuntu--vg-home rw,nosuid,nodev,relatime /var/log /dev/mapper/ubuntu--vg-var_log rw,nosuid,nodev,noexec,relatime /var/tmp /dev/mapper/ubuntu--vg-var_tmp rw,nosuid,nodev,noexec,relatime /var/log/audit /dev/mapper/ubuntu--vg-var_log_audit rw,nosuid,nodev,noexec,relatime

• The disk has a 1 MiB BIOS boot partition, a 200 MiB EFI system partition, a 1 GiB /boot and one LVM physical volume. The boot loader is installed for both BIOS and UEFI boot.
• The mount options are set in /etc/fstab by filesystem UUID, so they survive reboots and apply on every instance launched from the image.
• /dev/shm is also mounted nodev,nosuid,noexec.

The evaluation that the build ran after its reboot ships on the image. List the files:

ls -lh /usr/share/doc/sac/ python3 -c "import json; s=json.load(open('/usr/share/doc/sac/cis-l1-summary.json')); print('profile: ', s['profileLabel'], '(SCAP Security Guide', s['ssgVersion'] + ')'); print('scored rules: ', s['scored'], ' pass:', s['pass'], ' fail:', s['fail'], ' rate:', str(s['ratePct']) + '%'); print('waived: ', s['waived'], ' not applicable:', s['notapplicable']); print('evaluated at: ', s['evaluatedAt'])"

Expected output:

total 20M -rw-r--r-- 1 root root 17M Oct 18 22:49 cis-l1-arf.xml -rw-r--r-- 1 root root 2.6M Oct 18 22:49 cis-l1-report.html -rw-r--r-- 1 root root 1.3K Oct 18 22:49 cis-l1-summary.json -rw-r--r-- 1 root root 2.0K Oct 18 22:49 cis-l1-tailoring.xml -rw-r--r-- 1 root root 2.0K Oct 18 22:49 cis-l1-waivers.txt -rw-r--r-- 1 root root 1.6K Oct 18 22:44 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 360 pass: 355 fail: 5 rate: 98.6% waived: 5 not applicable: 33 evaluated at: 2026-10-18T22:49:18Z

• cis-l1-report.html is the full OpenSCAP report, rule by rule. Copy it to your workstation and open it in a browser.
• cis-l1-arf.xml is the same evaluation in the machine-readable ARF format, for compliance tooling.
• cis-l1-tailoring.xml is the exact tailoring used, so you can re-run the same evaluation (Step 6).
• The pass rate is pass / (pass + fail + error + unknown). Rules that are not applicable to this machine, not selected, or waived are not counted.

To copy the report to your workstation, run this command on the workstation:

scp -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>:/usr/share/doc/sac/cis-l1-report.html .

The five waived rules

grep -v '^#' /usr/share/doc/sac/cis-l1-waivers.txt | cut -f1,2

Expected output:

grub2_password [serial-console-and-boot] grub2_uefi_password [serial-console-and-boot] accounts_maximum_age_login_defs [key-only-account-aging] account_disable_post_pw_expiration [key-only-account-aging] sshd_limit_user_access [ssh-access-list]

The full reason for each is the third column of the same file. In short:

• Boot loader passwords: a GRUB password would have to be baked into the image, which gives every instance the same secret. Set your own if you need one (see Step 11).
• Password aging defaults: the accounts that cloud-init creates are key-only. An aging limit would expire them and lock the SSH key out.
• SSH AllowUsers/AllowGroups: a list fixed at build time would refuse accounts that you create later. Your security group restricts who can reach port 22.

The separate partition rules (/tmp, /var, /var/tmp, /var/log, /var/log/audit, /home) are not waived on this version: they are scored, and they pass.

The five rules that do not pass

python3 -c "import json; [print(r) for r in json.load(open('/usr/share/doc/sac/cis-l1-summary.json'))['failingRules']]"

Expected output:

ensure_root_access_controlled service_nftables_enabled set_nftables_loopback_traffic set_nftables_table set_ufw_default_rule

What each one means on this image:

• ensure_root_access_controlled: the Ubuntu 22.04 content passes this rule only when root has a password hash. This image has no password on any account, because a password set at build time would be the same on every instance. Root is locked instead (Step 11). If your policy requires a root password, set your own with sudo passwd root.
• service_nftables_enabled, set_nftables_loopback_traffic and set_nftables_table: these rules check an nftables service with a hand-written configuration. The firewall on this image is ufw, and the nftables service is masked so that it cannot flush the ufw rules at boot, so these rules do not describe it.
• set_ufw_default_rule: the benchmark wants outbound traffic denied by default. This image allows outbound traffic so that the SSM agent, metadata service, DNS, time sync and updates work out of the box.

Repeat the evaluation at any time with the same content and tailoring. It takes about a minute:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/sac/cis-l1-tailoring.xml \
  --profile xccdf_co.sac_profile_cis-l1_ec2_lvm \
  --cpe /usr/share/sac/openscap/ssg-split/ssg-ubuntu2204-cpe-dictionary.xml \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/sac/openscap/ssg-split/ssg-ubuntu2204-xccdf.xml > /tmp/cis-check.log 2>&1 echo "oscap exit code: $? (2 = at least one rule did not pass)"
sudo python3 -c "import re,collections; c=collections.Counter(re.findall(r'<result>(\w+)</result>', open('/tmp/cis-check-results.xml').read())); s=sum(c[k] for k in ('pass','fail','error','unknown')); print(dict(sorted(c.items()))); print('pass rate: %.1f%%' % (100.0*c['pass']/s))"

Expected output:

oscap exit code: 2 (2 = at least one rule did not pass) {'fail': 5, 'notapplicable': 33, 'notselected': 246, 'pass': 355} pass rate: 98.6%

Your own report is at /tmp/cis-check-report.html. Re-run the evaluation as you install software and change settings to see how your changes affect the result.

Why the command reads /usr/share/sac/openscap/ssg-split/. Some rules (the ufw and nftables rules, and the file ownership checks) are small shell scripts inside the SCAP content. The OpenSCAP 1.2 scanner in Ubuntu 22.04 unpacks a data stream's scripts into /tmp and runs them from there, which noexec on /tmp refuses. The image therefore ships the same pinned SCAP Security Guide content already unpacked into /usr/share/sac/openscap/ssg-split/, where the scripts can run, and the build used it too. If you evaluate the data stream file /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml directly instead, those seven script-checked rules report error rather than pass or fail.

curl -s -o /dev/null -w 'IMDSv1 request without a token: HTTP %{http_code}\n' http://169.254.169.254/latest/meta-data/instance-id
TOKEN=$(curl -s -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" -w '\n' http://169.254.169.254/latest/meta-data/placement/region

Expected output (your Region may differ):

IMDSv1 request without a token: HTTP 401 us-east-1

A request without a session token is refused with HTTP 401, and the same request with a token works. Scripts and SDKs on the instance must use IMDSv2. Every current AWS SDK and the AWS CLI do this automatically.

sudo ufw status verbose
sudo ss -tlnp

Expected output:

Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- Anywhere on lo ALLOW IN Anywhere 22/tcp ALLOW IN Anywhere 68/udp ALLOW IN 67/udp
# DHCP client: replies from a DHCP server (port 67) Anywhere DENY IN 127.0.0.0/8 Anywhere (v6) on lo ALLOW IN Anywhere (v6) 22/tcp (v6) ALLOW IN Anywhere (v6) Anywhere (v6) DENY IN ::1 Anywhere ALLOW OUT Anywhere on lo Anywhere (v6) ALLOW OUT Anywhere (v6) on lo State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess LISTEN 0 100 127.0.0.1:25 0.0.0.0:* users:(("master",pid=1415,fd=13)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=677,fd=14)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=915,fd=3)) LISTEN 0 100 [::1]:25 [::]:* users:(("master",pid=1415,fd=14)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=915,fd=4))

Only sshd listens on the network. The DNS stub resolver (53) and the local mail relay (25, for system mail) listen on loopback only. The 68/udp rule admits only the replies a DHCP server sends from port 67 to the instance's DHCP client, which keeps its address; it opens no service.

To open a port for your own service, allow it in the instance's security group and in ufw. For example, for a web server on 443, run this on the instance:

sudo ufw allow 443/tcp

If a port is open in the security group but not in ufw, or the reverse, the traffic does not arrive.

systemctl is-active chrony amazon-ssm-agent chronyc -n sources | head -6 dpkg -s snapd >/dev/null 2>&1 && echo "snapd: installed" || echo "snapd: not installed"

Expected output (the pool servers and timings vary):

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 169.254.169.123 3 4 377 3 -6831ns[ -12us] +/- 391us ^- 91.189.91.157 2 6 377 19 +36us[ +29us] +/- 28ms ^- 185.125.190.56 2 6 377 20 -3450us[-3457us] +/- 44ms ^- 185.125.190.58 2 6 377 21 -3014us[-3020us] +/- 44ms snapd: not installed

The ^* marks the source that chrony uses: 169.254.169.123, the Amazon Time Sync Service. Every instance can reach it without internet access, so time stays correct in a private subnet too. The public Ubuntu pool servers are fallbacks.

The AWS Systems Manager agent is installed from Amazon's Debian package instead of a snap, and snapd is removed.

The image is fully patched at build time. Check which updates are pending now:

sudo apt-get update -qq apt-get -s -o APT::Get::Always-Include-Phased-Updates=true dist-upgrade | awk '/^Inst /{n++} END{print "pending upgrades: " n+0}' apt-mark showhold uname -r

Expected output on an instance launched soon after the image was built (later launches show the updates released since):

pending upgrades: 0 6.8.0-1066-aws

unattended-upgrades is on, so security updates install automatically every day. To update everything immediately, run:

sudo apt-get update && sudo apt-get -y dist-upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

Package installs work normally with /tmp mounted noexec. The image points apt's template extraction at /var/cache/apt/extract-tmp, so package configuration scripts still run.

sudo aa-status --enabled && echo "apparmor: enabled"
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|clientaliveinterval) ' cat /etc/issue.net

Expected output:

apparmor: enabled root L 10/14/2026 0 99999 7 -1 maxauthtries 4 clientaliveinterval 300 permitrootlogin no pubkeyauthentication yes passwordauthentication no Authorized users only. All activity may be monitored and reported.

• L means the root password is locked.
• maxauthtries 4 and clientaliveinterval 300 come from the CIS profile. SSH allows four authentication attempts per connection and checks idle sessions every five minutes.
• The banner text is shown before login.

EC2 Serial Console and recovery. No account on this image has a password, so the serial console cannot log in until you set one. For serial console access, set a password for your own user on your running instance. The password is yours and is not on the image:

sudo passwd ubuntu

sudo vgs ubuntu-vg df -h / /var /var/log
sudo grep -E "cc_growpart.py.*(SKIPPED|resized|NOCHANGE)" /var/log/cloud-init.log | tail -1 | cut -c1-140 swapon --noheadings --show | wc -l sudo ls -l /etc/cron.daily/aide

Expected output with the default 12 GiB root volume:

VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 7 0 wz--n- 10.80g 820.00m Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-root 3.9G 1.3G 2.4G 36% / /dev/mapper/ubuntu--vg-var 1.5G 597M 786M 44% /var /dev/mapper/ubuntu--vg-var_log 974M 18M 889M 2% /var/log 2026-10-18 22:48:44,533 - cc_growpart.py[DEBUG]: '/' SKIPPED: Resizing mapped device (/dev/mapper/ubuntu--vg-root) skipped as it is not encr 0 -rwxr-xr-x 1 root root 34194 Dec 30 2021 /etc/cron.daily/aide

cloud-init does not grow LVM volumes. On a plain Ubuntu image, cloud-init grows the root filesystem to the volume size on first boot. On this image the root filesystem is a logical volume, so cloud-init skips it (the SKIPPED line above). This is deliberate, because you decide which volume gets the space. When you launch with a bigger root volume, or grow the EBS volume later with aws ec2 modify-volume, add the space in three steps on the instance:

• Grow partition 4 (the LVM physical volume) to the end of the disk, and tell LVM:

sudo growpart /dev/nvme0n1 4
sudo pvresize /dev/nvme0n1p4

• Give space to the volumes that need it. --resizefs grows the filesystem in the same step, online, with no reboot:

sudo lvextend --resizefs -L +4G /dev/ubuntu-vg/root
sudo lvextend --resizefs -L +2G /dev/ubuntu-vg/var

• Check the result:

sudo vgs ubuntu-vg df -h / /var

Example output after launching with a 20 GiB root volume and running the commands above:

CHANGED: partition=4 start=2510848 old: size=22654943 end=25165791 new: size=39432159 end=41943007 Physical volume "/dev/nvme0n1p4" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized Size of logical volume ubuntu-vg/root changed from 4.00 GiB (1024 extents) to 8.00 GiB (2048 extents). Logical volume ubuntu-vg/root successfully resized. resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/mapper/ubuntu--vg-root is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/mapper/ubuntu--vg-root is now 2097152 (4k) blocks long. Size of logical volume ubuntu-vg/var changed from 1.50 GiB (384 extents) to 3.50 GiB (896 extents). Logical volume ubuntu-vg/var successfully resized. resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/mapper/ubuntu--vg-var is mounted on /var; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/mapper/ubuntu--vg-var is now 917504 (4k) blocks long. VG #PV #LV #SN Attr VSize VFree ubuntu-vg 1 7 0 wz--n- 18.80g 2.80g Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-root 7.8G 1.3G 6.2G 18% / /dev/mapper/ubuntu--vg-var 3.5G 532M 2.8G 17% /var

To give a volume all the remaining free space instead, use -l +100%FREE, for example sudo lvextend --resizefs -l +100%FREE /dev/ubuntu-vg/var_log. Leaving some space unallocated is useful, because you can grow whichever volume fills first without touching EBS. Volumes can grow online but cannot shrink online, so add space in steps.

• Swap. The image has no swap. If your workload needs swap, create a logical volume for it (for example sudo lvcreate -L 2G -n swap ubuntu-vg, then mkswap and an /etc/fstab entry), or use a swap file on / or /var.
• AIDE. The file integrity database is built from the image's own files, and a daily check runs from /etc/cron.daily/aide.

The instance uses the standard Ubuntu archives. Run:

sudo apt-get update -qq apt-cache policy nginx | sed -n '1,3p'

Expected output (the version changes over time):

nginx: Installed: (none) Candidate: 1.18.0-6ubuntu14.21

Install and start software in the usual way, for example sudo apt-get install -y nginx then sudo systemctl enable --now nginx. Open its port in the security group and ufw (Step 8). Application data under /var (databases in /var/lib, web roots in /var/www) lands on the var logical volume, so grow that volume (Step 12) before you load large data sets.

Scripts in /tmp. Because /tmp and /var/tmp are noexec, you cannot run a downloaded installer saved there as ./installer.sh. Run it through its interpreter instead, or save it in your home directory or /opt first:

printf '#!/bin/sh\necho hello from /tmp\n' > /tmp/noexec-test.sh && chmod +x /tmp/noexec-test.sh /tmp/noexec-test.sh || echo "exit code $? (noexec)" bash /tmp/noexec-test.sh rm -f /tmp/noexec-test.sh

Expected output:

bash: /tmp/noexec-test.sh: Permission denied exit code 126 (noexec) hello from /tmp

To add another administrator, create the account, add it to the sudo group and give it an SSH key:

sudo adduser --disabled-password --gecos "" alice
sudo usermod -aG sudo alice
sudo install -d -m 700 -o alice -g alice /home/alice/.ssh echo "ssh-ed25519 AAAA... alice@laptop" | sudo tee /home/alice/.ssh/authorized_keys
sudo chown alice:alice /home/alice/.ssh/authorized_keys && sudo chmod 600 /home/alice/.ssh/authorized_keys

Because SSH is key-only, a new account needs its key in authorized_keys. The new account has no password, so sudo cannot authenticate it until you give it one with sudo passwd alice. SSH stays key-only, and sudo uses the password. Only ubuntu, which cloud-init creates, has password-free sudo.