Debian 13 Minimal

Option A: Azure Portal

• Go to the Azure Marketplace and search for "Debian 13 Minimal SecureAnyCloud".
• Select the image and click Create.
• Configure the basics:
  • Subscription: Select your Azure subscription.
  • Resource group: Create a new group or select an existing one.
  • Virtual machine name: Enter a name for your VM.
  • Region: Select your preferred Azure region.
  • Size: Standard_B2s is 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.
• Click Review + create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:debian-13-minimal:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-debian-minimal-vm \
  --image sac1647283583153:debian-13-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. Nothing further is needed. The root partition and filesystem grow to fill the disk during first boot.

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

az vm show --resource-group myResourceGroup --name my-debian-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.

Check that the machine is the Debian 13 release you expect:

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

Expected output:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" ID=debian 13.7 Linux 6.12.107+deb13-cloud-amd64 x86_64 amd64

The -cloud-amd64 kernel matters. This image keeps Debian's cloud kernel flavour, with the Hyper-V drivers included, which is the same kernel Debian's own Azure images run.

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 /

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

287 Filesystem Size Used Avail Use% Mounted on /dev/sda1 30G 566M 28G 2% /

The count is 287 packages against the standard image's 329. The trim ran as a single guarded, simulated package transaction down to Debian Policy's own base system definition. The provisioning path (cloud-init, the Azure agent, OpenSSH, netplan and the boot chain) is on the guard's protected list, so it cannot be trimmed by construction.

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 -10 /usr/share/sac/debian-13-minimal.manifest

Expected output:

# Debian 13 Minimal — sac shipped manifest
# DERIVED from the dpkg database on this image at 2026-09-12T09:13:03Z (capture time) — never hand-written.
# Baseline: the sac 'Debian 13' (std) image this Minimal is cut from.
#
# WHAT 'MINIMAL' MEANS HERE: Debian publishes no minimal cloud artefact, but
# Debian Policy defines the minimal system — priority classes required +
# important, exactly what debootstrap installs by default. This image keeps
# that Policy-defined base, the Azure provisioning/boot/security lineage
# (cloud-init, the Azure agent, kernel + boot chain, networking, chrony,
# AppArmor, unattended-upgrades), and their dependencies — nothing else.

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

sed -n '/capability notes/,/^#$/p' /usr/share/sac/debian-13-minimal.manifest

Expected output:

# --- capability notes, each DERIVED from a probe on this image --- NFS: this image has NO NFS client (the std Debian azure image ships none either), NFS: so 'mount -t nfs' will not work as shipped. Restore it with:
sudo apt install nfs-common MAN: the man command is installed (man-db is priority important — part of the Policy-defined base). CRON: no classic cron daemon (the std Debian azure image ships none either); systemd CRON: timers provide scheduling. Restore classic cron with:
sudo apt install cron EDITOR: nano and vi (vim-tiny) are installed (both priority important — Policy base); EDITOR: full vim was removed by the trim. Restore with:
sudo apt install vim PROVISIONING: cloud-init 25.1.4 + waagent 2.12.0.2-3 are installed — the full Azure provisioning path is retained. KERNEL: 6.12.107+deb13-cloud-amd64 (Debian's cloud kernel flavour — Hyper-V drivers included, the same kernel the std image runs). UPDATES: unattended-upgrades is installed and armed — security updates auto-apply, exactly as on the std image. GROW: the root filesystem auto-grows to the disk size you deploy (the stock Debian GROW: mechanism — initramfs growroot + x-systemd.growfs + cloud-init — is fully retained). DOCS: the trim is package-level; /usr/share/doc of every RETAINED package 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}'

Expected output shows pending upgrades: 0, no held packages, and exactly one installed cloud kernel:

pending upgrades: 0 linux-image-6.12.107+deb13-cloud-amd64 6.12.107-1

Debian has no phased updates in practice, but the flag is accepted and harmless, and it keeps this check identical across the SecureAnyCloud Debian and Ubuntu families.

This image also arms unattended-upgrades, proven at build time with a real preview run resolving the Debian-Security origin, so security updates keep applying themselves. 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, SSH is key-only and LLMNR is off:

sudo aa-status --enabled && echo "apparmor: enabled"
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) ' resolvectl status 2>/dev/null | awk '/-LLMNR/ && !p {print; p=1}'

Expected output:

apparmor: enabled root L 2009-12-22 -1 -1 -1 -1 permitrootlogin without-password pubkeyauthentication yes passwordauthentication no Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

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, and -LLMNR confirms the legacy multicast name resolution listener is off.

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 the stock Debian growth mechanism. The initramfs extends the root partition during first boot, and systemd grows the filesystem as it mounts. Confirm it:

df -h /

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

Filesystem Size Used Avail Use% Mounted on /dev/sda1 63G 566M 60G 1% /

The proof is in the kernel's own log, which records the ext4 online resize that systemd-growfs performed at mount time:

sudo dmesg | grep 'resized filesystem' grep 'NOCHANGE\|resized' /var/log/cloud-init.log | tail -1

Expected output (block counts vary with your disk size):

[ 8.439276] EXT4-fs (sda1): resized filesystem to 16744443 2026-09-12 08:37:57,592 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/sda, 1)

The NOCHANGE line is correct and expected on Debian. By the time the cloud-init growpart module looks at the disk, the initramfs has already grown the partition, so cloud-init finds nothing left to do. On distributions without the initramfs grow step, the same line reads resized: changed.

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, or use the portal's Disks blade. The root grows 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 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 shows 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 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=986,fd=6)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=432,fd=15)) LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=432,fd=17)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=986,fd=7))

On stock Debian 13 you would also see 0.0.0.0:5355 and [::]:5355, which is the systemd-resolved LLMNR listener. This image disables LLMNR because it is a deprecated spoofing vector and is useless on an Azure VNet. SSH is therefore the only off-box socket.

Debian enables no host firewall by default. nftables is the framework and 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 trim removes nothing from your reach. The machine points at the standard Debian archives (main component), 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'

Expected output:

nginx - small, powerful, scalable web/proxy server nginx-common - small, powerful, scalable web/proxy server - common files nginx-core - nginx web/proxy server (standard version)

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): vim for the full editor, cron for classic cron jobs, nfs-common for NFS mounts, tcpdump for packet capture.

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 with mode 600, and give 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

Option A: AWS Marketplace console

• Open the SecureAnyCloud Debian listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• Once the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for full control), then in Version choose Debian 13 Minimal - YYYY-MM-DD (the date is when the version was added) and your Region.
• Instance type: m5.large is recommended; any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
• Key pair: choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work.
• Security group: allow inbound TCP 22 from your own IP address or network only.
• Storage: the root volume is 8 GiB gp3 by default. Choose a larger size if you need one; cloud-init grows the root partition and filesystem to fill it on first boot.
• Metadata: leave the defaults. 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, and 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=debian-13-minimal}]'

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

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

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

There is no password to enter. If SSH asks for one, or says Too many authentication failures, see Troubleshooting below. The SSH server shows the login banner (/etc/issue.net) before you sign in.

You can also connect without opening port 22 at all 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.

cat /etc/debian_version grep -E '^(PRETTY_NAME|NAME|VERSION_ID|VERSION|VERSION_CODENAME|ID)=' /etc/os-release uname -srm

Expected output:

13.7 PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie ID=debian Linux 6.12.113+deb13-cloud-amd64 x86_64

This version follows Debian 13: it receives every Debian 13 point release (13.7 at build time) through normal apt updates. Your kernel version may be newer if updates have installed since this image was built.

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

cat /usr/share/doc/sac/minimal-manifest.txt dpkg-query -W -f='${db:Status-Abbrev}\n' | grep -c '^ii'

Expected output:

Minimal version: packages 341 -> 292 Removed: awscli vim reportbug apt-listchanges screen tcpdump socat bash-completion man-db manpages bind9-host traceroute ssh-import-id pciutils Kept (a removal would have taken a protected package, or it failed): 339

The trim takes the base image from 341 packages to 292, including the dependencies that left with those 14 (the AWS CLI's Python stack, vim-runtime, the DNS and packet-capture libraries). The CIS remediation then adds the tools it needs (OpenSCAP, AIDE, ufw, chrony, rsyslog and their libraries), which brings the image to 339 installed packages. The standard Debian 13 version of this listing is built the same way without the trim, so it carries the same 339 packages plus the 47 the trim removed (386). The count on your instance moves by a few as kernels and updates install, and by one more if your account runs Amazon Inspector, whose Systems Manager association installs its own inspectorssmplugin package.

The trim never removes a candidate that would take a package the instance needs with it. On this build no candidate had to be kept, so the Kept list is empty.

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

Expected output:

total 22M -rw-r--r-- 1 root root 19M Oct 25 01:28 cis-l1-arf.xml -rw-r--r-- 1 root root 2.6M Oct 25 01:28 cis-l1-report.html -rw-r--r-- 1 root root 1.3K Oct 25 01:28 cis-l1-summary.json -rw-r--r-- 1 root root 1.9K Oct 25 01:28 cis-l1-tailoring.xml -rw-r--r-- 1 root root 2.3K Oct 25 01:28 cis-l1-waivers.txt -rw-r--r-- 1 root root 278 Oct 25 01:21 minimal-manifest.txt -rw-r--r-- 1 root root 1.6K Oct 25 01:22 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 363 pass: 359 fail: 3 rate: 98.9% waived: 6 not applicable: 33 evaluated at: 2026-10-25T01:28:52Z

• 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).
• minimal-manifest.txt is the trim record from Step 4.
• 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 admin@<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

Expected output:

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 full reason for each is the third column of the same file. 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. Root stays locked with no password. Set your own if you need serial console access (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. Accounts that do have a password are still aged.
• 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 four 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:

file_ownerships_var_log journald_forward_to_syslog service_systemd-journal-upload_enabled systemd_journal_upload_url

Three of them fail and one (file_ownerships_var_log) reports error. Each one is the result of a deliberate choice, and each stays in the score rather than being hidden:

Log file ownership (file_ownerships_var_log) reports error, not fail. The check accepts only files owned by root or a syslog account, and Debian has no syslog account. The one file it trips on is /var/log/aide/aide.log, which belongs to the _aide account on purpose: Debian's daily AIDE check (dailyaidecheck.service) runs as _aide and has to rotate its own log. If that file belonged to root, the daily check would fail every day and the instance would report a failed service.

journald forwarding (journald_forward_to_syslog). The profile selects both "forward the journal to syslog" and "do not forward the journal to syslog", so one of the pair always fails. The image keeps the journal as the log store (ForwardToSyslog=no). rsyslog is installed and running if you want to switch: set ForwardToSyslog=yes in /etc/systemd/journald.conf and restart systemd-journald.

• Remote journal upload (service_systemd-journal-upload_enabled, systemd_journal_upload_url). The benchmark wants the journal sent to a remote log server. The image cannot know yours, and with no address the upload service would fail at every boot, so it is installed but disabled. To use it, set URL= to your collector in /etc/systemd/journal-upload.conf, then run sudo systemctl enable --now systemd-journal-upload.

You can 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_single \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian13-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))"

Expected output:

oscap exit code: 2 (2 = at least one rule did not pass) {'error': 1, 'fail': 4, 'notapplicable': 33, 'notchecked': 1, 'notselected': 380, 'pass': 358} pass rate: 98.6%

On a running instance the result is one rule lower than the shipped evaluation (358 of 363 rather than 359). The extra rule is file_permissions_backup_etc_shadow. The Debian 13 content wants /etc/shadow- at mode 0000, and the image ships it that way. On first boot, cloud-init locks the default user's password (passwd -l admin), and the system then re-creates /etc/shadow- as a backup with the same mode as /etc/shadow (0640 root:shadow). Every later password or account change does the same. The backup holds only the previous /etc/shadow, which has the same mode and, on this image, no usable password hash. If you want the rule to pass, run this after account changes:

sudo chmod 0000 /etc/shadow-

Your own report is at /tmp/cis-check-report.html. The content file is ssg-debian13-ds.xml, the Debian 13 data stream from the SCAP Security Guide 0.1.82 release (its sha256 is recorded in cis-l1-summary.json). As you install software and change settings, re-run this 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

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 (process IDs vary):

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) 53 on lo ALLOW IN Anywhere
# systemd-resolved loopback stub 127.0.0.54:53 (lo only) Anywhere (v6) on lo ALLOW IN Anywhere (v6) 22/tcp (v6) ALLOW IN Anywhere (v6) 53 (v6) on lo ALLOW IN Anywhere (v6)
# systemd-resolved loopback stub 127.0.0.54:53 (lo only) 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=810,fd=6)) LISTEN 0 20 127.0.0.1:25 0.0.0.0:* users:(("exim4",pid=1438,fd=5)) LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=325,fd=17)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=325,fd=15)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=810,fd=7)) LISTEN 0 20 [::1]:25 [::]:* users:(("exim4",pid=1438,fd=6))

• Only sshd listens on a network address, on port 22. The DNS stub resolver (systemd-resolved, 127.0.0.53 and 127.0.0.54) and the local mail service (exim4, 127.0.0.1 and ::1 port 25) listen on loopback only. systemd-resolved's LLMNR and multicast DNS responders are switched off.
• The DHCP rule admits only replies from a DHCP server's port 67 to the instance's DHCP client, which is how the instance keeps its address. The port 53 rule applies to the loopback interface only.
• Outbound traffic is allowed, so the SSM agent, the metadata service, DNS, time sync and package updates work.

Opening a port for your own service takes two steps: allow it in the instance's security group, and allow it in ufw. For example, for a web server on 443, run 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 will not arrive.

systemctl is-active chrony amazon-ssm-agent chronyc -n sources

Expected output (the pool servers and timings vary):

active active MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- 172.234.37.140 2 6 37 19 -802us[ -814us] +/- 52ms ^- 23.186.168.123 2 6 133 16 +2266us[+2248us] +/- 56ms ^- 107.141.134.168 1 6 67 17 -120us[ -134us] +/- 13ms ^- 23.186.168.125 2 6 37 19 +2300us[+2289us] +/- 56ms ^* 169.254.169.123 3 4 377 4 +3742ns[ -37us] +/- 428us

The ^* marks the source chrony is using: 169.254.169.123, the Amazon Time Sync Service. It is reachable from every instance without internet access, so time stays correct in a private subnet too. The public Debian pool servers are fallbacks. chrony replaces Debian's default systemd-timesyncd because the CIS profile wants exactly one time service and chrony is the one that can use the Amazon Time Sync Service as its preferred source.

The AWS Systems Manager agent is installed from Amazon's own package at its current release (3.3.5538.0 on this build). It is not in the Debian archive, so apt does not update it; Systems Manager can keep it current for you (the AWS-UpdateSSMAgent document, or the Auto update SSM Agent setting in Fleet Manager).

The image is fully patched at build time. Check what is pending now:

sudo apt-get update -qq apt list --upgradable 2>/dev/null cat /etc/apt/apt.conf.d/20auto-upgrades systemctl is-enabled unattended-upgrades apt-daily-upgrade.timer uname -r

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

Listing... APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; enabled enabled 6.12.113+deb13-cloud-amd64

unattended-upgrades runs daily and installs updates from the Debian and Debian-Security archives automatically. To update everything now, run:

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

Reboot if a new kernel was installed:

sudo systemctl reboot

sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|x11forwarding|maxauthtries|clientaliveinterval|banner) '
sudo aa-status --enabled && echo "AppArmor: enabled" grep -c nullok /etc/pam.d/common-auth || true systemctl is-system-running

Expected output:

root L 2026-10-21 0 99999 7 -1 maxauthtries 4 clientaliveinterval 300 permitrootlogin no pubkeyauthentication yes passwordauthentication no kbdinteractiveauthentication no x11forwarding no banner /etc/issue.net AppArmor: enabled 0 running

• L means the root account is locked.
• sshd -T prints the settings the SSH server actually uses, after every configuration file is read. The key-only settings and X11Forwarding no are pinned in /etc/ssh/sshd_config.d/00-ec2-key-only.conf, the first drop-in file the server reads, so a later file cannot turn them back on.
• maxauthtries 4 and clientaliveinterval 300 come from the CIS profile: SSH allows four authentication attempts per connection and checks idle sessions every five minutes.
• AppArmor is enabled with Debian's default policy, as Debian ships it. On this build sudo aa-status reports 103 profiles loaded: 4 in enforce mode (chronyd among them), 23 in complain mode and 76 unconfined. The one confined running service is chronyd, in enforce mode. Profiles in complain mode log what they would block without blocking it.
• 0 means PAM no longer accepts an empty password (nullok removed from pam_unix).
• running means no service failed during boot.

EC2 Serial Console and recovery. No account on this image has a password, so the serial console cannot log in until you set one. If you want 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 admin

df -hT /
sudo grep -E 'cc_growpart.*(resized|NOCHANGE)' /var/log/cloud-init.log | tail -1 sudo swapon --noheadings --show | wc -l systemctl is-enabled aidecheck.timer grep -E '^(ExecStart|SuccessExitStatus)=' /etc/systemd/system/aidecheck.service

Expected output with the default 8 GiB root volume (on a larger volume, Size is larger and the cloud-init line says resized):

Filesystem Type Size Used Avail Use% Mounted on /dev/nvme0n1p1 ext4 7.7G 888M 6.4G 12% / 2026-10-25 01:42:03,833 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/nvme0n1, 1) 0 enabled ExecStart=/usr/bin/aide --config /etc/aide/aide.conf --check SuccessExitStatus=1 2 3 4 5 6 7

• Disk layout. The root filesystem is ext4 on partition 1 of the root volume; /boot/efi is a separate small partition.
• 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 run sudo growpart /dev/nvme0n1 1 && sudo resize2fs /dev/nvme0n1p1 (or reboot).
• 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. The CIS profile runs aide --check at boot and daily at 05:00 (aidecheck.timer); differences are reported in the journal (journalctl -u aidecheck), and a real AIDE error marks the unit failed. On a new instance a check may report files cloud-init creates for that instance (such as its hostname); after you have reviewed the report, refresh the database with sudo aide --config /etc/aide/aide.conf --init and move the new database into place (sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db). Debian's own daily check (dailyaidecheck.timer) also runs, as the _aide account, and writes /var/log/aide/aide.log; that is why the AIDE log files belong to _aide.

The instance uses Debian's own archive (trixie, trixie-updates, trixie-backports and trixie-security, through the mirror list Debian's cloud images ship in /etc/apt/mirrors/):

apt-cache policy nginx | sed -n 1,3p apt-cache policy awscli | sed -n 1,3p

Expected output (the versions change over time):

nginx: Installed: (none) Candidate: 1.26.3-3+deb13u9 awscli: Installed: (none) Candidate: 2.23.6-1

Install and start software in the usual way, for example sudo apt-get -y install nginx then sudo systemctl enable --now nginx, and open its port in the security group and ufw (Step 8).

Anything the trim removed comes back the same way, for example sudo apt-get -y install vim man-db manpages tcpdump. The AWS CLI is not on this image: install Debian's package with sudo apt-get -y install awscli, or the current version from AWS (the AWS CLI install guide).

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

sudo useradd -m -s /bin/bash -G 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; the password is used by sudo. (Password-free sudo is granted only to admin, created by cloud-init, and to ssm-user, the account Session Manager creates for its sessions.)