Debian 12 LVM on AWS User Guide

Overview

This guide covers launching and verifying the Debian 12 LVM AMI from cloudimg on Amazon EC2. It is one version of the cloudimg Debian listing on AWS Marketplace; you pick it as the software version when you subscribe and launch. Every release and variant in the listing is described at /guides/debian-server-aws/.

Debian 12 "bookworm" is the Debian Project's free, community-built operating system. Its regular security support ended in June 2026 and it is now maintained by the Debian LTS team, with security updates until June 2028, delivered through the same bookworm-security archive. This version is built from Debian's own official AMI and adds five things:

• An LVM disk layout. The root filesystem and the six locations the CIS benchmark wants on their own partitions (/home, /tmp, /var, /var/tmp, /var/log and /var/log/audit) are separate logical volumes in the volume group debian-vg, each mounted with the benchmark's options (nodev, nosuid, and noexec where it applies). You can grow any of them online.
• CIS Level 1 Server remediation. The image is remediated with the OpenSCAP CIS Level 1 Server profile from SCAP Security Guide 0.1.82 (the ssg-debian12 content, CIS Debian Linux 12 Benchmark v1.1.0), then rebooted and evaluated. On this build 353 of 359 scored rules pass (98.3%), and a re-run on a freshly launched instance gives the same result. Because the volumes are real, the partition and mount-option rules are applied and scored, not waived. Five rules are waived because they cannot work on an EC2 image, each with its reason. The HTML report, the machine-readable results, the waiver list and a summary ship in /usr/share/doc/cloudimg/.
• Fixes the profile's own remediation leaves undone. nullok is removed from PAM (the content's fix could not apply it), martian-packet logging stays on after ufw starts, and the daily AIDE check runs Debian's aide binary, so the instance boots with no failed services.
• EC2 defaults that keep you in control. Key-only SSH as admin, root locked, no password on any account, AppArmor enforcing, IMDSv2 required, a host firewall (ufw) that allows SSH in and everything out, the AWS Systems Manager agent, and time from the Amazon Time Sync Service.
• Fully patched at build time, with unattended-upgrades installing Debian security updates on your instance.

What is on the image: Debian 12 (the Debian cloud-amd64 kernel), LVM2, cloud-init, OpenSSH, ufw, chrony, AppArmor, the AWS Systems Manager agent, auditd, rsyslog, AIDE file integrity checking, exim4 for local mail only (loopback, no inbound SMTP), unattended-upgrades, OpenSCAP and the pinned SCAP Security Guide content used for the evaluation.

Default user: admin · Architecture: x86_64 · Root volume: 12 GiB gp3, LVM (volume group debian-vg, ext4 logical volumes, 820 MiB left unallocated for you to assign)

These images are remediated with an OpenSCAP profile and ship their own evaluation report. They are not CIS Hardened Images, and CIS has not reviewed or certified them.

Connecting to your instance

Version	SSH user	Root device
Debian 12 LVM	admin	/dev/xvda (12 GiB gp3, LVM)

Security posture

• No known credential. There is no default password and no baked in SSH key. The only key that works is the EC2 key pair you choose at launch, which cloud-init installs for admin on first boot.
• Key-only SSH. PasswordAuthentication no, PermitRootLogin no, keyboard-interactive off. The root account has no password and is locked.
• Per-instance identity. SSH host keys and the machine ID are generated fresh on every instance, so no two instances share a host key.
• IMDSv2 required. The AMI is registered with ImdsSupport v2.0, so instances launched from it refuse token-less (IMDSv1) metadata requests by default.
• Separate, restricted volumes. /tmp, /var/tmp, /var/log and /var/log/audit are mounted noexec,nodev,nosuid; /home and /var are nodev,nosuid. A full log volume cannot fill the root filesystem.
• AppArmor enforcing, with every loaded profile in enforce mode, as Debian ships it.
• Host firewall. ufw denies inbound traffic except SSH and allows all outbound traffic, so the SSM agent, metadata service, DNS, time and package updates keep working.
• Only SSH listens on the network. The DNS stub resolver and the local mail service listen on loopback only.

Prerequisites

1. An AWS account and permission to launch EC2 instances
2. An EC2 key pair in the Region you launch in
3. A security group that allows TCP 22 from your own address (not from the whole internet)

Recommended instance type: m5.large. The image runs on any current x86_64 instance type.

Step 1: Launch the instance

Option A: AWS Marketplace console

1. Open the cloudimg Debian listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
2. Once the subscription is active, choose Launch your software.
3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for full control), then in Version choose Debian 12 LVM - YYYY-MM-DD (the date is when the version was added) and your Region.
4. Instance type: m5.large is recommended; any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
5. Key pair: choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work.
6. Security group: allow inbound TCP 22 from your own IP address or network only.
7. Storage: the root volume is 12 GiB gp3 by default. You can choose a larger size; the extra space is added to the LVM physical volume when you run the three commands in Step 12 (cloud-init does not grow logical volumes on its own).
8. 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-12-lvm}]'

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

Step 2: Connect via SSH

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.

Step 3: Confirm the release

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

Expected output:

12.15
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
Linux 6.1.0-54-cloud-amd64 x86_64

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

Step 4: See the LVM layout

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

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 
  ├─debian--vg-root             4G lvm  ext4        /
  ├─debian--vg-home             1G lvm  ext4        /home
  ├─debian--vg-tmp              1G lvm  ext4        /tmp
  ├─debian--vg-var            1.5G lvm  ext4        /var
  ├─debian--vg-var_tmp        512M lvm  ext4        /var/tmp
  ├─debian--vg-var_log          1G lvm  ext4        /var/log
  └─debian--vg-var_log_audit    1G lvm  ext4        /var/log/audit
  VG        #PV #LV #SN Attr   VSize  VFree  
  debian-vg   1   7   0 wz--n- 10.80g 820.00m
  LV            LSize   Path                        
  home            1.00g /dev/debian-vg/home         
  root            4.00g /dev/debian-vg/root         
  tmp             1.00g /dev/debian-vg/tmp          
  var             1.50g /dev/debian-vg/var          
  var_log         1.00g /dev/debian-vg/var_log      
  var_log_audit   1.00g /dev/debian-vg/var_log_audit
  var_tmp       512.00m /dev/debian-vg/var_tmp      
TARGET         SOURCE                               OPTIONS
/              /dev/mapper/debian--vg-root          rw,relatime
/tmp           /dev/mapper/debian--vg-tmp           rw,nosuid,nodev,noexec,relatime
/home          /dev/mapper/debian--vg-home          rw,nosuid,nodev,relatime
/var           /dev/mapper/debian--vg-var           rw,nosuid,nodev,relatime
/var/log       /dev/mapper/debian--vg-var_log       rw,nosuid,nodev,noexec,relatime
/var/tmp       /dev/mapper/debian--vg-var_tmp       rw,nosuid,nodev,noexec,relatime
/var/log/audit /dev/mapper/debian--vg-var_log_audit rw,nosuid,nodev,noexec,relatime
/boot          /dev/nvme0n1p3                       rw,nosuid,nodev,relatime

• Partitions. Partition 1 is the BIOS boot partition GRUB uses, partition 2 is the EFI system partition, partition 3 is /boot (ext4, outside LVM so the boot loader can read it simply), and partition 4 is the LVM physical volume.
• Volumes. Each logical volume is an ext4 filesystem. /home and /var are nodev,nosuid; /tmp, /var/tmp, /var/log and /var/log/audit are also noexec, so nothing can be executed from them. /dev/shm is mounted nodev,nosuid,noexec too.
• Free space. 820 MiB of the volume group is deliberately unallocated, so you can grow whichever volume fills first without touching EBS (Step 12).

Step 5: Read the compliance evidence

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

ls -lh /usr/share/doc/cloudimg/
python3 -c "import json; s=json.load(open('/usr/share/doc/cloudimg/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 24M
-rw-r--r-- 1 root root  21M Oct 20 19:28 cis-l1-arf.xml
-rw-r--r-- 1 root root 3.4M Oct 20 19:28 cis-l1-report.html
-rw-r--r-- 1 root root 1.4K Oct 20 19:28 cis-l1-summary.json
-rw-r--r-- 1 root root 1.9K Oct 20 19:28 cis-l1-tailoring.xml
-rw-r--r-- 1 root root 2.0K Oct 20 19:28 cis-l1-waivers.txt
-rw-r--r-- 1 root root 1.6K Oct 20 19:21 scap-security-guide-LICENSE.txt
profile:       CIS Level 1 Server (SCAP Security Guide 0.1.82)
scored rules:  359  pass: 353  fail: 6  rate: 98.3%
waived:        5  not applicable: 35
evaluated at:  2026-10-20T19:28:40Z

• 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 admin@<public-ip>:/usr/share/doc/cloudimg/cis-l1-report.html .

The five waived rules

grep -v '^#' /usr/share/doc/cloudimg/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, 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.

Unlike the single-volume Debian 12 version, no partition rule is waived here: the separate volumes for /tmp, /var, /var/tmp, /var/log, /var/log/audit and /home and their mount options are all scored, and pass.

The six rules that do not pass

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

Expected output:

journald_forward_to_syslog
package_iptables-persistent_installed
package_ufw_removed
permissions_local_var_log
service_systemd-journal-upload_enabled
systemd_journal_upload_url

Each one fails on purpose, and each stays in the score rather than being hidden:

• ufw against the nftables and iptables package rules (package_ufw_removed, package_iptables-persistent_installed). The Debian 12 content checks for the nftables and iptables firewall branches whatever firewall you select. ufw is the image's single host firewall, so these two always fail; adding iptables-persistent would load a second, conflicting ruleset at boot.
• Login accounting files (permissions_local_var_log). The Debian 12 check flags every file in /var/log wider than 0640 with no exceptions, which catches wtmp and lastlog (0664) and btmp (0660). Those are the modes login accounting needs, systemd restores them at every boot, and the CIS benchmark itself exempts them. Every other log file is 0640 or stricter.
• 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.

Step 6: Re-run the evaluation yourself

You can repeat the evaluation at any time with the same content and tailoring. It takes about two minutes:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/cloudimg/cis-l1-tailoring.xml \
  --profile xccdf_co.cloudimg_profile_cis-l1_ec2_lvm \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian12-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 on a freshly launched instance:

oscap exit code: 2 (2 = at least one rule did not pass)
{'fail': 6, 'notapplicable': 35, 'notchecked': 4, 'notselected': 489, 'pass': 353}
pass rate: 98.3%

Your own report is at /tmp/cis-check-report.html. The content file is ssg-debian12-ds.xml, the Debian 12 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.

Some rules are checked by small shell scripts that OpenSCAP unpacks into /tmp. Because /tmp is noexec on this version, the image includes /usr/local/bin/oscap-run-sce-script, a one-line helper that OpenSCAP calls to run those scripts through bash. Leave it in place, or those rules report error instead of pass or fail.

Step 7: Confirm IMDSv2 is required

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.

Step 8: The host firewall and listening ports

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      4096   127.0.0.53%lo:53        0.0.0.0:*    users:(("systemd-resolve",pid=475,fd=14))
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=623,fd=3))
LISTEN 0      4096      127.0.0.54:53        0.0.0.0:*    users:(("systemd-resolve",pid=475,fd=16))
LISTEN 0      20         127.0.0.1:25        0.0.0.0:*    users:(("exim4",pid=1249,fd=4))
LISTEN 0      20             [::1]:25           [::]:*    users:(("exim4",pid=1249,fd=5))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=623,fd=4))

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

Step 9: Time sync and the Systems Manager agent

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
===============================================================================
^- 149.28.61.105                 2   6   177     5   -137us[ -137us] +/- 7203us
^- 23.150.41.122                 2   6   177     3   -742us[ -742us] +/-   24ms
^- 198.137.202.32                2   6   177     3   +659us[ +659us] +/-   33ms
^- 23.172.120.58                 2   6   177     3   -260us[ -260us] +/-   54ms
^* 169.254.169.123               3   4   377    19   -123us[ -135us] +/-  575us

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.5390.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).

Step 10: Patch level and automatic updates

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.1.0-54-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

Kernel updates rebuild the initramfs with the LVM tools included, so the instance keeps booting from its logical volumes.

Step 11: Security settings on the instance

sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|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-18 0 99999 7 -1
maxauthtries 4
clientaliveinterval 300
permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
banner /etc/issue.net
AppArmor: enabled
0
running

• 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.
• AppArmor is enabled, with every loaded profile in enforce mode.
• 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

Step 12: Growing a volume, swap and file integrity

sudo vgs debian-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
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 12 GiB root volume:

  VG        #PV #LV #SN Attr   VSize  VFree  
  debian-vg   1   7   0 wz--n- 10.80g 820.00m
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/debian--vg-root     3.9G 1018M  2.7G  28% /
/dev/mapper/debian--vg-var      1.5G  257M  1.1G  19% /var
/dev/mapper/debian--vg-var_log  974M   17M  890M   2% /var/log
2026-10-20 19:47:05,229 - cc_growpart.py[DEBUG]: '/' SKIPPED: Resizing mapped device (/dev/mapper/debian--vg-root) skipped as it is not encr
0
enabled
ExecStart=/usr/bin/aide --config /etc/aide/aide.conf --check
SuccessExitStatus=1 2 3 4 5 6 7

cloud-init does not grow LVM volumes. On the single-volume Debian 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). That is deliberate: 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:

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

1. 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/debian-vg/root
sudo lvextend --resizefs -L +2G /dev/debian-vg/var

1. Check the result:

sudo vgs debian-vg
df -h / /var

Example output after growing a 12 GiB volume to 20 GiB and running the commands above:

CHANGED: partition=4 start=2510848 old: size=22654943 end=25165790 new: size=39432159 end=41943006
  Physical volume "/dev/xvda4" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
  Size of logical volume debian-vg/root changed from 4.00 GiB (1024 extents) to 8.00 GiB (2048 extents).
  Logical volume debian-vg/root successfully resized.
  Size of logical volume debian-vg/var changed from 1.50 GiB (384 extents) to 3.50 GiB (896 extents).
  Logical volume debian-vg/var successfully resized.
  VG        #PV #LV #SN Attr   VSize  VFree
  debian-vg   1   7   0 wz--n- 18.80g 2.80g
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/debian--vg-root  7.8G 1019M  6.5G  14% /
/dev/mapper/debian--vg-var   3.5G  257M  3.0G   8% /var

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

• Swap. The image has no swap. If your workload needs it, create a logical volume for it (for example sudo lvcreate -L 2G -n swap debian-vg, then sudo mkswap /dev/debian-vg/swap and an /etc/fstab entry), or a swap file on / or /var.
• 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). After you grow a volume, AIDE also reports the new LVM metadata backups in /etc/lvm.

Step 13: Install software and add users

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

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

Expected output (the version changes over time):

nginx:
  Installed: (none)
  Candidate: 1.22.1-9+deb12u10

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). The AWS CLI is not on the image; install the current version from AWS (the AWS CLI install guide) if you need it. Put application data on a volume that suits it: /var for services that keep state under /var/lib, or a new logical volume of your own (sudo lvcreate -L 2G -n data debian-vg) if you leave space unallocated for it.

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

Common use cases

• Workloads that must show CIS Level 1 alignment on Debian including the partitioning rules, with the evaluation report already on the machine
• Servers whose logs, temporary files or application data must not be able to fill the root filesystem
• Hosts that need to grow one area (logs, /var/lib, home directories) without resizing everything
• Fleets managed through Systems Manager, with IMDSv2 required from the first boot
• A starting point for your own golden image: add your software, re-run Step 6, and keep the report with your build

Troubleshooting

SSH says "Too many authentication failures"

The SSH server allows four authentication attempts per connection. If your SSH agent holds several keys, it can use them up before it offers the right one. Tell SSH to offer only the key you name:

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

Cannot connect via SSH

1. Check the instance is running and has passed its status checks.
2. Check the security group allows TCP 22 from your current public address.
3. Use the user name admin (not debian, ec2-user or root) and the key pair chosen at launch. Password login is disabled, so a wrong key never falls back to a password prompt.
4. If you changed ufw, make sure 22/tcp is still allowed (sudo ufw allow 22/tcp). Session Manager (Step 2) still works if SSH is blocked, provided the instance has a Systems Manager instance profile.

I launched with a bigger volume but df shows the same size

That is expected on this image: cloud-init does not grow logical volumes. Follow Step 12 to grow the physical volume and then the logical volumes you choose.

A volume is full

Check which one with df -h. If the volume group has free space (sudo vgs), grow the full volume with lvextend --resizefs (Step 12). If not, grow the EBS volume first with aws ec2 modify-volume or the console, then run the three steps in Step 12.

"Permission denied" running a script or binary

/tmp, /var/tmp, /var/log and /var/log/audit are mounted noexec. Run scripts through their interpreter (bash script.sh) or move them to your home directory or /opt.

My service is running but not reachable

Allow the port in both the security group and ufw (Step 8). sudo ufw status verbose shows the ufw rules; sudo ss -tlnp shows whether the service listens on all addresses or only on loopback.

A tool that uses instance metadata fails

The image requires IMDSv2. Old scripts that call http://169.254.169.254/ without a token get HTTP 401. Update them to request a token first (Step 7), or use the AWS CLI or a current SDK.

Package manager issues

Refresh the package lists first:

sudo apt-get update -qq && echo "package lists refreshed"

If the archive is unreachable, check that the instance has outbound internet access (a public IP or a NAT gateway) and that DNS resolves:

getent hosts deb.debian.org

Important notes

Debian is free and open source software. It is a distribution of thousands of packages, each under its own licence (GPL, LGPL, MIT, BSD, Apache 2.0 and others); /usr/share/doc/<package>/copyright shows each package's licence. No subscription or licence key is needed to run this image. The compliance tooling is OpenSCAP (LGPL 2.1 or later) and SCAP Security Guide content (BSD 3-Clause, licence text in /usr/share/doc/cloudimg/scap-security-guide-LICENSE.txt).

Debian 12 left regular security support in June 2026 and receives security updates from Debian LTS until June 2028, through the same bookworm-security archive this image already uses. This version tracks the Debian 12 release stream, so new point releases arrive as ordinary updates.

The CIS Level 1 Server profile used here is the OpenSCAP profile published in SCAP Security Guide. These images are not CIS Hardened Images and are not certified by the Center for Internet Security. A pass rate measures this image as built; your own changes affect it, which is why the evaluation can be re-run (Step 6).

Debian is a registered trademark of Software in the Public Interest, Inc. CIS is a trademark of the Center for Internet Security. These names are used only to identify the software and the profile. cloudimg is not affiliated with or endorsed by the Debian Project, Software in the Public Interest or the Center for Internet Security.

Support

For help with this image, contact cloudimg support:

• Website: www.cloudimg.co.uk
• User Guides: www.cloudimg.co.uk/guides
• Debian on AWS hub: www.cloudimg.co.uk/guides/debian-server-aws