Ubuntu 22.04 Minimal

Option A: Azure Portal

• Go to the Azure Marketplace and search for "Ubuntu 22.04 LTS Minimal SecureAnyCloud".
• Select the image and choose Create.
• On the basics tab, set Subscription to your Azure subscription and Resource Group to a new or existing group.
• Enter a Virtual Machine Name, select your preferred Region, and 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. The root filesystem fills it automatically at first boot.
• Choose Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:ubuntu-22-04-minimal:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-ubuntu-minimal-vm \
  --image sac1647283583153:ubuntu-22-04-minimal: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. Unlike an LVM layout, nothing more is needed. cloud-init grows the partition and the filesystem to fill the disk during first boot.

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-minimal-vm --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, your client is not offering the key 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

The output looks like this:

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

The -azure kernel matters. This image keeps the Azure kernel flavour of the standard image, with the Hyper-V drivers built in. Canonical uses the same arrangement for its own Azure images.

Now confirm the defining property of this image, the Minimal package profile:

dpkg-query -Wf '${Package}\n' | sed 's/:.*$//' | sort -u | wc -l df -h /

On a fresh VM deployed with the default 30 GiB disk, the output looks like this:

435 Filesystem Size Used Avail Use% Mounted on /dev/root 29G 1.5G 28G 5% /

This image has 435 packages, against 629 on the standard image. The trim ran as a single guarded first package transaction, simulated first, against Canonical's published Minimal manifest. The provisioning path (cloud-init, the Azure agent, OpenSSH, netplan, the boot chain) is on the guard's protected list, so the trim cannot remove it.

The image states what it is. The manifest is generated from the package database at capture and is never written by hand, so it cannot disagree with the machine you are on:

head -8 /usr/share/sac/ubuntu-22-04-minimal.manifest

The output looks like this:

# Ubuntu 22.04 LTS Minimal — sac shipped manifest
# DERIVED from the dpkg database on this image at 2026-09-12T02:41:39Z (capture time) — never hand-written.
# Baseline: the sac 'Ubuntu Server 22.04 LTS' (std) image this Minimal is cut from.
#
# Measured trim delta vs the std baseline: 629 -> 435 packages (-194), dpkg payload -443 MiB.
# Trim target: Canonical's published Ubuntu 22.04 Minimal cloud-image package seed (manifest sha256 58a9ea8c5fdea393...). # Guard refusals (candidates KEPT because their removal would cascade a keeper): hwdata libdw1 libip4tc2 libip6tc2 libnetfilter-conntrack3 libnfnetlink0 libnftnl11 libnuma1 libpci3 libpython3.10 libslang2 libtraceevent1 libunwind8 pci.ids usb.ids # Installed now: 435 packages, dpkg payload 871 MiB, rootfs used 2092 MiB.

The capability notes further down the file say what is not on the image and how to restore each piece:

sed -n '/capability notes/,/^#$/p' /usr/share/sac/ubuntu-22-04-minimal.manifest

The output looks like this:

# --- 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.8.0-1065-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. Use it for compliance snapshots and drift comparisons.

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}'

The output shows pending upgrades: 0, no held packages, and exactly one 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, 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

Confirm that AppArmor is enforcing, that root is locked, and that SSH accepts keys only:

sudo aa-status --enabled && echo "apparmor: enabled"
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

The output looks like this:

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 from passwd -S means that the root account is locked.

If you deployed onto a disk larger than 30 GiB, as in the Step 1 CLI example, you do not need to do anything. 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)"

On a 64 GiB disk, this image produces the output below. On 22.04, the root partition is sda1 and /boot lives on the root filesystem. There is no separate boot partition:

Filesystem Size Used Avail Use% Mounted on /dev/root 62G 1.5G 61G 3% / NAME SIZE TYPE MOUNTPOINT sda 64G disk |-sda1 63.9G part / |-sda14 4M part `-sda15 106M part /boot/efi

cloud-init's own log records the automatic grow:

grep 'resized' /var/log/cloud-init.log | tail -1

The output looks like this. Byte counts vary with your disk size:

2026-09-12 02:52:49,862 - cc_growpart.py[INFO]: '/' resized: changed (/dev/disk/by-partuuid/ce587b22-55bb-4ef3-a3db-64be7e36f126) from 32096894464 to 68603067904

Growing an existing VM later. Enlarge the OS disk. Deallocate the VM, run az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, and start the VM. You can also use the portal's Disks blade. cloud-init grows the root again on the next boot. This layout never needs manual partitioning.

The Azure Network Security Group controls inbound and outbound traffic. It is the first, and usually the only, place where you open a port. The image exposes a single inbound port, SSH on 22. Confirm what is listening:

sudo ss -tlnp

The output shows sshd on port 22 (IPv4 and IPv6) and systemd-resolved on the loopback-only stub address:

State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=607,fd=3)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=416,fd=14)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=607,fd=4))

ufw is not installed on this image, because 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 also requires a host firewall, install and enable one. Add the SSH rule first so that 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 is present on the image, and the Azure agent uses it to protect the platform metadata endpoint.

The trim does not put any software out of your reach. The machine points at the standard Ubuntu archives, so 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 shipped manifest (Step 4) lists the everyday absences and their one-line restores: man-db for manual pages, nano or vim for an editor, iputils-ping for ping, cron for classic cron jobs, and 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 on the file and mode 700 on the .ssh directory, both owned by that user. The image ships with no human accounts, so azureuser is the only login until you add one:

getent group sudo

The output looks like this:

sudo:x:27:azureuser

Option A: AWS Marketplace console

• Open the SecureAnyCloud Ubuntu listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for full control. In Version, choose Ubuntu 22.04 LTS Minimal - YYYY-MM-DD, where the date is when the version was added. Then choose your Region.
• Pick an instance type and your key pair. m5.large is recommended, and any current x86_64 type works.
• Set the security group to allow SSH (TCP 22) from your own IP address or network only.
• Set the root volume size you want (8 GiB minimum). The root filesystem grows to fill it on first boot.
• Leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the key pair, security group and subnet with your own:

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/sda1,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ubuntu-2204-minimal}]'

You do not need --metadata-options. The AMI already requires IMDSv2.

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

The output looks like this:

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 flavour 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.

The image lists exactly what was removed. Anything that a removal would have taken with it is kept and listed instead:

cat /usr/share/doc/sac/minimal-manifest.txt dpkg-query -W -f='${Package}\n' | wc -l

The output looks like this:

Minimal version: packages 608 -> 549 Removed: landscape-common ubuntu-release-upgrader-core apport apport-symptoms friendly-recovery ntfs-3g open-iscsi multipath-tools plymouth fwupd-signed bolt usb-modeswitch pollinate byobu motd-news-config lxd-agent-loader sosreport telnet ftp Kept (a removal would have taken a protected package, or it failed): 566

The trim takes the package count from 608 to 549, including the dependencies that left with those 19 packages. Nothing had to be kept back. The CIS remediation then adds the tools it needs (OpenSCAP, AIDE and their libraries), which is why the installed count is a little higher. The count on your instance changes by a few packages as kernels and updates install.

Anything removed is one sudo apt-get install away from the standard Ubuntu archives.

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

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'])"

The output looks like this:

total 20M -rw-r--r-- 1 root root 17M Oct 19 07:53 cis-l1-arf.xml -rw-r--r-- 1 root root 2.6M Oct 19 07:53 cis-l1-report.html -rw-r--r-- 1 root root 1.4K Oct 19 07:53 cis-l1-summary.json -rw-r--r-- 1 root root 2.1K Oct 19 07:53 cis-l1-tailoring.xml -rw-r--r-- 1 root root 2.3K Oct 19 07:53 cis-l1-waivers.txt -rw-r--r-- 1 root root 388 Oct 19 07:48 minimal-manifest.txt -rw-r--r-- 1 root root 1.6K Oct 19 07:48 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 342 pass: 337 fail: 5 rate: 98.5% waived: 6 not applicable: 50 evaluated at: 2026-10-19T07:53:56Z

• 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 on the workstation:

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

The six waived rules

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

The output looks like this:

partition_for_tmp [single-volume-partitions] 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 third column of the same file gives the full reason for each rule. In short:

• Separate /tmp partition: this version boots from one EBS root volume. The LVM versions of this listing provide separate volumes for /tmp, /var, /var/log, /var/log/audit, /var/tmp and /home.
• Boot loader passwords: a GRUB password would have to be baked into the image, giving every instance the same secret. Set your own if you need one (see Step 11).
• Password ageing defaults: the accounts cloud-init creates are key-only. An ageing limit would expire them and lock the SSH key out.
• SSH AllowUsers/AllowGroups: a list fixed at build time would refuse accounts you create later. Your security group restricts who can reach port 22.

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']]"

The output looks like this:

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 version of this check passes only when root has a password hash. A root password on the image would be the same secret on every instance, so root has no password and is locked instead (sudo passwd -S root shows L, Step 11). Nobody can log in as root. Administrators use sudo.
• service_nftables_enabled, set_nftables_loopback_traffic and set_nftables_table: these check for the nftables service and a hand-written nftables configuration. The firewall on this image is ufw, and nftables.service is masked so that it can never start and flush ufw's rules at boot. The benchmark itself warns against running two firewall front ends at once.
• 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.

You can repeat the evaluation at any time with the same content and tailoring. It takes less than a minute:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/sac/cis-l1-tailoring.xml \
  --profile xccdf_co.sac_profile_cis-l1_ec2_single \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.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))"

On a freshly launched instance, the output looks like this:

oscap exit code: 2 (2 = at least one rule did not pass) {'fail': 5, 'notapplicable': 50, 'notselected': 247, 'pass': 337} pass rate: 98.5%

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.

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

The output looks like this. 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

The output looks like this:

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=1128,fd=13)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=606,fd=3)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=371,fd=14)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=606,fd=4)) LISTEN 0 100 [::1]:25 [::]:* users:(("master",pid=1128,fd=14))

Only sshd listens on the network. The DNS stub resolver (53 on lo) and the local mail relay (25, for system mail) listen on loopback only. The 68/udp rule admits only the replies of the VPC's DHCP server to the instance's own DHCP client, which keeps the instance's private 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 other way round, the traffic does not arrive.

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

The output looks like this. The pool servers and timings vary:

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 169.254.169.123 3 4 37 6 -156us[ -350us] +/- 973us ^- 185.125.190.58 2 6 17 23 +2689us[+2491us] +/- 44ms ^- 91.189.91.157 2 6 17 22 +842us[ +649us] +/- 29ms ^- 185.125.190.56 2 6 17 22 +4335us[+4141us] +/- 46ms ^- 185.125.190.57 2 6 17 23 +5232us[+5034us] +/- 46ms ^- 143.42.229.154 2 6 17 24 -259us[ -457us] +/- 30ms ^- 72.30.35.88 2 6 17 23 +45us[ -152us] +/- 7505us ^- 172.233.155.39 5 6 17 23 +62us[ -136us] +/- 62ms ^- 23.25.68.225 1 6 17 23 +1905us[+1707us] +/- 12ms ^? 132.163.96.4 1 6 1 30 -354us[-1062ms] +/- 20ms ^? 129.6.15.28 1 6 1 29 +212us[-1061ms] +/- 5945us ^? 129.6.15.29 1 6 1 31 +325us[-1061ms] +/- 6005us ^? 129.6.15.30 1 6 1 30 +287us[-1061ms] +/- 5997us snapd: not installed

The ^* marks the source that chrony is using: 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. A ^? marks a server that chrony has only just started polling.

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

The image is fully patched at build time. Check what is 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

On an instance launched soon after the image was built, the output looks like this. 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 now, run:

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

Reboot if a new kernel was installed:

sudo systemctl reboot

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

The output looks like this:

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 account 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. To use the serial console, set a password for your own user on your running instance. The password is yours and is not on the image:

sudo passwd ubuntu

df -h /
sudo awk '/cc_growpart/ && /(resized|NOCHANGE)/' /var/log/cloud-init.log | tail -1 swapon --noheadings --show | wc -l sudo ls -l /etc/cron.daily/aide

With the default 8 GiB root volume, the output looks like this. On a larger volume, Size is larger and the cloud-init line says resized:

Filesystem Size Used Avail Use% Mounted on /dev/root 7.6G 1.4G 6.3G 18% / 2026-10-19 08:10:55,566 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/nvme0n1, 1) 0 -rwxr-xr-x 1 root root 34194 Dec 30 2021 /etc/cron.daily/aide

• Disk growth. cloud-init grows the root partition and filesystem to the volume size on first boot. To grow later, increase the EBS volume size in the console or with aws ec2 modify-volume, then reboot (or run sudo growpart /dev/nvme0n1 1 && sudo resize2fs /dev/nvme0n1p1).

• Swap. The image has no swap. Add a swap file yourself if your workload needs one.

• AIDE. The file integrity database is built from the image's own files, and Ubuntu 22.04's AIDE package runs its daily check from /etc/cron.daily/aide.

The instance uses the standard Ubuntu archives:

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

The output looks like this. 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).

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.