Rocky Linux 10.2

Option A: Azure Portal

• Navigate to the Azure Marketplace and search for "Rocky Linux 10.2 SecureAnyCloud"
• Select the image and click Create
• Configure the basics:
• Subscription: Select your Azure subscription
• Resource Group: Create new or select existing
• Virtual Machine Name: Enter a name for your VM
• Region: Select your preferred Azure region
• Size: Standard_B2s recommended
• Under Administrator Account, select SSH public key and enter your key
• Under Inbound Port Rules, allow SSH (port 22)
• Click Review + Create, then Create

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:rocky-10-2:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-rocky-10-2-vm \
  --image sac1647283583153:rocky-10-2:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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-rocky-10-2-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.

First check that the machine is the point release you procured.

cat /etc/rocky-release

Rocky Linux release 10.2 (Red Quartz)

The os-release fields carry the same information in a machine-readable form, which is what configuration management tools read:

grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID)=' /etc/os-release

NAME="Rocky Linux" VERSION="10.2 (Red Quartz)" ID="rocky" VERSION_ID="10.2" PLATFORM_ID="platform:el10"

VERSION_ID is 10.2, not 10. That is the field an inventory or compliance tool keys on, and it is the reason this listing exists as a separate product.

The RHEL compatibility lineage is asserted by the distribution itself:

cat /etc/redhat-release

Rocky Linux release 10.2 (Red Quartz)

And the kernel:

uname -srm

Linux 6.12.0-211.37.1.el10_2.x86_64 x86_64

Every update available in the 10.2 stream was applied when this image was built. dnf check-update exits 100 when updates are pending and 0 when none are:

dnf -q check-update >/dev/null 2>&1; echo "exit=$?"

exit=0

Nothing is waiting on a reboot either:

dnf needs-restarting -r

No core libraries or services have been updated since boot-up. Reboot should not be necessary.

Your update path is intact. Three repositories are enabled:

dnf repolist --enabled

repo id repo name appstream Rocky Linux 10 - AppStream baseos Rocky Linux 10 - BaseOS extras Rocky Linux 10 - Extras

CRB (CodeReady Builder) and the Devel repository ship configured but disabled, which is the Rocky default. Enable CRB only if you are building software that needs its development headers:

sudo dnf config-manager --set-enabled crb

Automatic security updates

Unlike a stock Rocky Linux cloud image, this machine keeps patching itself. dnf-automatic is installed and its timer is enabled, so the machine applies security updates on its own schedule:

systemctl is-enabled dnf-automatic.timer

enabled

systemctl list-timers dnf-automatic.timer

NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2026-07-27 06:52:34 UTC 4h 17min - - dnf-automatic.timer dnf-automatic.service

The policy is deliberately conservative: security updates only, and never an automatic reboot. A kernel update waits for a window you choose rather than restarting a production machine without warning:

grep -E '^(apply_updates|upgrade_type|reboot|random_sleep)' /etc/dnf/automatic.conf

upgrade_type = security random_sleep = 300 apply_updates = yes reboot = never

Because reboot = never, check periodically whether a restart is owed after a kernel update, using the needs-restarting -r command above. To opt out entirely, run sudo systemctl disable --now dnf-automatic.timer.

Confirm SELinux is enforcing:

getenforce

Enforcing

Confirm the root account is locked. The L in the second field means locked:

passwd -S root

root L 2009-12-22 -1 -1 -1 -1

Confirm no account on the machine has a usable password. This prints nothing on a clean image:

sudo awk -F: '($2 !~ /^[!*]/) && ($2 != "") {print $1}' /etc/shadow

Read the SSH daemon's effective policy rather than the config file, since the running daemon is what a client actually meets:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

permitrootlogin without-password pubkeyauthentication yes passwordauthentication no

There is no swap on the operating system disk. Azure manages swap on the ephemeral resource disk if you want it, and a swap file baked into a Marketplace image is not permitted, so this prints nothing:

swapon --show

Confirm the Cockpit web console is closed and that sshd is the only thing listening:

systemctl is-enabled cockpit.socket ss -tlnH | awk '{print $1, $4}'

disabled LISTEN 0.0.0.0:22 LISTEN [::]:22

Re-enabling the Cockpit web console

Cockpit is a browser-based server manager. It is installed but switched off. To use it, open port 9090 in your Azure Network Security Group, then run:

sudo systemctl enable --now cockpit.socket

Cockpit authenticates against local system accounts. Since this image ships no account with a password, create one for yourself before you rely on Cockpit for access, and restrict port 9090 to your own address range in the NSG rather than opening it to the internet.

By default this machine behaves like any other Rocky Linux 10 system: sudo dnf update moves it forward within the Rocky 10 series, including across future point releases. That is the right behaviour for most workloads, and it is how you receive security fixes.

If your change control genuinely requires a fleet to stay on the 10.2 package set, Rocky's mechanism is the releasever variable:

echo "10.2" | sudo tee /etc/dnf/vars/releasever

Read this before you do it. Rocky serves a pinned minor release from its vault, and a vault is only populated once that release has been superseded. At the time of writing, 10.2 is the current release and https://dl.rockylinux.org/vault/rocky/10.2/ returns 404, so pinning today would point dnf at a location that does not exist yet. More importantly, once a vault is frozen it stops receiving new security backports, so pinning trades security currency for version stability.

Pin only if a compliance obligation requires it. Revisit the decision on a schedule, and never pin a machine that is exposed to the internet without compensating controls.

For most people the correct answer is to leave the repositories alone, let the automatic security updates run, and use this listing for what it is: a guarantee about the release you procured.

The Azure Linux Agent handles provisioning, extensions and the portal's serial console:

systemctl is-active waagent rpm -q WALinuxAgent cloud-init

active WALinuxAgent-2.14.0.1-3.el10.noarch cloud-init-24.4-7.el10_2.1.rocky.0.1.noarch

Cloud-init should report done, which means provisioning finished cleanly:

cloud-init status

status: done

The kernel puts a console on ttyS0, which is what makes boot diagnostics and the portal's serial console work when you cannot reach the machine over SSH:

grep -o 'console=ttyS0[^ ]*' /proc/cmdline

Time synchronisation runs through chronyd against the Azure host clock:

chronyc -n sources | head -3

MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 2 3 377 4 +20us[ +24us] +/- 5212ns

Azure attaches an ephemeral resource disk, which waagent formats and mounts at /mnt. It is fast, local and erased whenever the machine is deallocated or moved, so use it for scratch and caches, never for data you need to keep:

df -h / /mnt

Filesystem Size Used Avail Use% Mounted on /dev/sdb4 8.4G 1.2G 7.2G 15% / /dev/sda1 7.8G 28K 7.4G 1% /mnt

The Azure Network Security Group is the control plane for inbound and outbound traffic, and it is the first and usually the only place you need to open a port.

This image is a minimal build, so firewalld is not installed:

rpm -q firewalld || echo "(firewalld absent - the Azure NSG is your only firewall)"

package firewalld is not installed (firewalld absent - the Azure NSG is your only firewall)

That is deliberate: with no host firewall in the way, your NSG rules take effect exactly as written, with no second layer to keep in sync. Confirm what is listening before you open anything:

ss -tlnp

If your policy requires a host firewall as well, install and enable it yourself:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-port=443/tcp sudo firewall-cmd --reload

Once firewalld is running, a port must be open in both the Azure NSG and firewalld before traffic reaches your service.

AppStream carries the application packages. Search it, then install what you need:

dnf search nginx

Install a package and enable it in the usual way, for example sudo dnf install -y nginx followed by sudo systemctl enable --now nginx.

Note that modularity is deprecated in Rocky Linux 10. The dnf module streams that shaped package selection on Rocky 8 are on their way out, and DNF will warn you if you use them. On Rocky 10 you generally install the single version AppStream carries, and reach for a vendor repository or a container when you need a different one.

To add another administrator, create the account with sudo adduser <name>, add it to the wheel group with sudo usermod -aG wheel <name>, then copy your public key into /home/<name>/.ssh/authorized_keys with mode 600 and the .ssh directory mode 700, owned by that user. The image ships with no human accounts at all, so azureuser is the only login until you add one:

getent group wheel

Option A: AWS Marketplace console

• Open the SecureAnyCloud Rocky Linux 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 Rocky Linux 10.2 - 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 11 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/sda1:

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=rocky-linux-10-2}]'

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

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

ssh -i ~/.ssh/my-key-pair.pem rocky@<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 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/rocky-release grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID|PRETTY_NAME)=' /etc/os-release uname -srm

Expected output:

Rocky Linux release 10.2 (Red Quartz) NAME="Rocky Linux" VERSION="10.2 (Red Quartz)" ID="rocky" VERSION_ID="10.2" PLATFORM_ID="platform:el10" PRETTY_NAME="Rocky Linux 10.2 (Red Quartz)" Linux 6.12.0-211.66.1.el10_2.x86_64 x86_64

Your kernel version may be newer if updates have installed since this image was built.

This version is named for, and built from, Rocky Linux 10.2. The listing also carries Rocky Linux 10 versions (for example Rocky Linux 10 Minimal) that are rebuilt from whichever Rocky Linux 10 point release is current. Choose this one when your build sheet, compliance baseline or vendor support matrix names 10.2 and you need the image you launch to say so.

At the time of this build, 10.2 is the newest Rocky Linux 10 point release, and the image has every 10.2 update published up to its build date. The instance uses the standard Rocky Linux 10 repositories:

rpm -q rocky-release dnf -q repolist

Expected output:

rocky-release-10.2-1.2.el10.noarch repo id repo name appstream Rocky Linux 10 - AppStream baseos Rocky Linux 10 - BaseOS extras Rocky Linux 10 - Extras

How updates behave. Rocky Linux maintains only the newest point release of each major version. The repositories above follow it:

• While 10.2 is current (as it is at the time of writing), sudo dnf upgrade and the automatic security updates (Step 10) install 10.2 updates, and the instance stays on 10.2.
• When Rocky Linux releases 10.3, the same repositories start serving 10.3. The next sudo dnf upgrade moves the instance to 10.3, and the automatic security updates install 10.3 packages. This is the normal Rocky Linux behaviour, and it is how the instance keeps receiving security fixes. Rocky Linux does not publish further updates for 10.2 after 10.3 is out: it moves 10.2 to its archive (the vault at dl.rockylinux.org/vault/rocky/10.2/), frozen as it was on that day.

In short, the image is a fixed 10.2 starting point. A running instance follows Rocky Linux 10 forward unless you hold it.

Holding an instance at 10.2. If your change control requires the 10.2 package set, set the releasever variable on your instance:

echo "10.2" | sudo tee /etc/dnf/vars/releasever

Today, with 10.2 still current, that resolves to the live 10.2 repositories (sudo dnf -q --releasever=10.2 repolist lists Rocky Linux 10.2 - BaseOS and the others). Read this before you rely on it:

• Once 10.3 is released, a host held at 10.2 gets no more security updates: the 10.2 content is frozen in the vault.
• At that point the default mirror list may stop serving 10.2. To keep installing packages from the frozen 10.2 set, point each repository in /etc/yum.repos.d/rocky.repo at the vault (baseurl=https://dl.rockylinux.org/vault/rocky/$releasever/BaseOS/$basearch/os/, and the same for AppStream and Extras) and comment out its mirrorlist= line.
• Holding trades security fixes for version stability. Hold only when a compliance obligation requires it, review the decision on a schedule, and do not hold an internet-facing instance without compensating controls. To return to normal updates, remove /etc/dnf/vars/releasever (and any vault baseurl you added).

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 32M -rw-r--r--. 1 root root 29M Oct 20 03:40 cis-l1-arf.xml -rw-r--r--. 1 root root 2.4M Oct 20 03:40 cis-l1-report.html -rw-r--r--. 1 root root 1.3K Oct 20 03:40 cis-l1-summary.json -rw-r--r--. 1 root root 1.8K Oct 20 03:40 cis-l1-tailoring.xml -rw-r--r--. 1 root root 2.9K Oct 20 03:40 cis-l1-waivers.txt -rw-r--r--. 1 root root 1.6K Oct 20 03:36 scap-security-guide-LICENSE.txt profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 286 pass: 284 fail: 2 rate: 99.3% waived: 7 not applicable: 31 evaluated at: 2026-10-20T03:40:55Z

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

The seven 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] ensure_root_password_configured [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] service_systemd-journal-upload_enabled [log-remote-destination]

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 and root passwords: a GRUB or root 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.
• Remote journal upload: the benchmark enables systemd-journal-upload, which sends the journal to a remote log server. An image cannot know your log server, and with no destination the upload service fails at every boot. systemd-journal-remote is installed and the upload service is left disabled: set URL= in /etc/systemd/journal-upload.conf and run sudo systemctl enable --now systemd-journal-upload to send the journal to your own collector.

The two rules that do not pass

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

Expected output:

ensure_journald_and_rsyslog_not_active_together ensure_redhat_gpgkey_installed

• journald and rsyslog together. The benchmark wants one logging system, not both. Rocky Linux runs journald and rsyslog together by default: journald keeps the structured system journal (persistent, in /var/log/journal), and rsyslog writes the traditional text logs (/var/log/messages, /var/log/secure, /var/log/cron) that many log shippers and audit procedures read. The image keeps both so neither kind of tooling loses its logs. If you standardise on one, for example the journal only, run sudo systemctl disable --now rsyslog on your instance and re-run Step 6.
• The Red Hat release key. In SCAP Security Guide 0.1.82, this rule's check for Rocky Linux 10 looks only for Red Hat's own package signing keys. Rocky Linux packages are signed with the Rocky Linux release key, which is installed, and dnf verifies every package against it. Installing Red Hat's key would not protect anything on a Rocky Linux system, so the image does not, and the rule stays as a reported fail. You can see the installed keys with:

rpm -q gpg-pubkey --qf '%{VERSION}-%{RELEASE} %{SUMMARY}\n'

Expected output:

6fedfc85-682ae1a9 Release Engineering (Rocky Linux 10) <releng@rockylinux.org> public key 2ebba43f-6a7b0932 Release Engineering (Rocky Linux 10) <releng@rockylinux.org> public key 22b7fa33-682ae15f Release Engineering (Rocky Linux 10 Testing) <releng@rockylinux.org> public key

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-rl10-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 (measured on a fresh instance launched from this image):

oscap exit code: 2 (2 = at least one rule did not pass) {'fail': 2, 'notapplicable': 31, 'notselected': 756, 'pass': 284} pass rate: 99.3%

Your own report is at /tmp/cis-check-report.html. The content file is ssg-rl10-ds.xml, the Rocky Linux 10 data stream; the RHEL 10 data stream that the same package carries reports every rule as not applicable on Rocky Linux. 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 firewall-cmd --state sudo firewall-cmd --list-all sudo ss -tlnp systemctl is-enabled cockpit.socket cat /etc/systemd/system-preset/80-sac-cockpit.preset

Expected output:

running public (default, active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: ens5 sources: services: dhcpv6-client ssh ports: protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: 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=1038,fd=7)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1038,fd=8)) disabled
# sac: inbound SSH only. Enable the Cockpit web console yourself (see the user guide). disable cockpit.socket

• Only sshd listens, on port 22. Nothing else on the image opens a TCP port.
• The public zone allows ssh and dhcpv6-client (replies to the instance's IPv6 DHCP client, which is how an instance in an IPv6-enabled subnet gets its address). The Rocky Linux default cockpit service is removed from the zone.
• The loopback interface sits in firewalld's trusted zone, with rules that drop traffic claiming a loopback source from anywhere else (a CIS requirement).
• The network interface name (ens5 here) depends on the instance type.

Opening a port for your own service takes two steps: allow it in the instance's security group, and allow it in firewalld. For example, for a web server on 443, run on the instance:

sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload

If a port is open in the security group but not in firewalld (or the other way round), the traffic will not arrive.

Turning on the Cockpit web console. Cockpit (cockpit-ws, cockpit-system, cockpit-bridge) is installed as in a standard Rocky Linux system, but its socket is disabled, and the preset file shown above stops the Rocky Linux default (enable cockpit.socket) from switching it back on. If you want the console, run on the instance:

sudo systemctl enable --now cockpit.socket
sudo firewall-cmd --permanent --add-service=cockpit sudo firewall-cmd --reload

Then allow TCP 9090 from your own address in the security group and browse to https://<public-ip>:9090. Cockpit signs in with a local account's password, so give your user one first (sudo passwd rocky); SSH stays key-only. Cockpit uses a self-signed certificate until you install your own. Prefer an SSH tunnel (ssh -L 9090:localhost:9090 ...) to opening 9090 to the internet.

systemctl is-active chronyd 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 =============================================================================== ^- 216.250.115.174 2 6 17 53 +2391us[+2502us] +/- 114ms ^- 69.89.207.199 1 6 17 53 +436us[ +547us] +/- 19ms ^- 38.28.93.135 1 6 17 52 +3208us[+3319us] +/- 27ms ^- 199.68.201.234 2 6 17 53 +9623us[+9732us] +/- 55ms ^* 169.254.169.123 3 4 177 21 -72us[ -22us] +/- 502us

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 Rocky Linux pool servers are fallbacks.

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 Rocky Linux repositories, so dnf 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 dnf -q check-update --refresh echo "dnf check-update exit code: $? (0 = nothing to update, 100 = updates available)" grep -E '^(upgrade_type|apply_updates)' /etc/dnf/automatic.conf systemctl is-enabled dnf-automatic.timer uname -r

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

dnf check-update exit code: 0 (0 = nothing to update, 100 = updates available) upgrade_type = security apply_updates = yes enabled 6.12.0-211.66.1.el10_2.x86_64

dnf-automatic runs daily (06:00, with a random delay of up to an hour) and installs security updates automatically from the repositories described in Step 4. To update everything now, run:

sudo dnf -y upgrade

Reboot if a new kernel was installed:

sudo systemctl reboot

getenforce
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|clientaliveinterval|banner) ' cat /etc/issue.net

Expected output:

Enforcing root L 2026-06-24 0 99999 7 -1 maxauthtries 4 clientaliveinterval 300 permitrootlogin no pubkeyauthentication yes passwordauthentication no banner /etc/issue.net Authorized users only. All activity may be monitored and reported.

• Enforcing means SELinux is on and enforcing the targeted policy. Keep it on; if your own software is denied, check sudo ausearch -m avc -ts recent rather than disabling SELinux.
• L in the second field 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. 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 rocky

df -hT /
sudo grep -E 'cc_growpart.*(resized|NOCHANGE)' /var/log/cloud-init.log | tail -1 swapon --noheadings --show | wc -l sudo grep -h aide /etc/crontab

Expected output with the default 11 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/nvme0n1p4 xfs 9.4G 1.7G 7.8G 18% / 2026-10-20 04:03:50,516 - cc_growpart.py[DEBUG]: '/' NOCHANGE: no change necessary (/dev/nvme0n1, 4) 0 05 4 * * * root /usr/sbin/aide --check

• Disk layout. The root filesystem is XFS on partition 4 of the root volume; /boot (XFS) and /boot/efi are separate small partitions.
• 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 4 && sudo xfs_growfs / (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, and the CIS profile schedules aide --check daily at 04:05 from /etc/crontab.

The instance uses the standard Rocky Linux 10 repositories (BaseOS, AppStream and Extras):

sudo dnf -q list --available nginx

Expected output (the version changes over time):

Available Packages nginx.x86_64 2:1.26.3-6.el10_2.7 appstream

Install and start software in the usual way, for example sudo dnf -y install nginx then sudo systemctl enable --now nginx, and open its port in the security group and firewalld (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.

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

sudo useradd -m -G wheel 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
sudo restorecon -R /home/alice/.ssh

Because SSH is key-only, a new account needs its key in authorized_keys (and restorecon gives the file the SELinux label sshd expects). 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 rocky, created by cloud-init, and to ssm-user, which the Systems Manager agent creates the first time you open a Session Manager session.)