Deploy IOanyT Hardened Ubuntu 24.04
From subscribing on AWS Marketplace to a running, secured instance — plus day-2 operations. Guide updated October 8, 2026
Operating system
Ubuntu 24.04 LTS
SSH user
ubuntu
Architectures
x86_64 and arm64 (Graviton)
Ports
22
| Operating system | SSH user | Ports | Architectures |
|---|---|---|---|
| Ubuntu 24.04 LTS | ubuntu | 22 (SSH) | x86_64, arm64 (Graviton) |
This guide takes you from an AWS Marketplace subscription to a running, hardened server. There is no manual setup: each instance finishes its own first-boot setup automatically.
Prerequisites
- An AWS account with permission to subscribe in AWS Marketplace and launch EC2 instances
- An EC2 key pair for SSH
- A network path to port 22 from your own network (same VPC, VPN or bastion host)
Step 1 — Subscribe and launch
Using the AWS console
- Open the listing for your architecture in AWS Marketplace, either IOanyT Hardened Ubuntu 24.04 - CIS Level 1 (x86_64) or IOanyT Hardened Ubuntu 24.04 - CIS Level 1 (Arm64/Graviton), and choose Continue to Subscribe.
- Accept the terms, then choose Continue to Configuration.
- Pick the latest version and your Region, then choose Continue to Launch.
- Choose Launch through EC2, then pick an instance type from the table below, your VPC and subnet, and your key pair.
- Create or pick a security group as described in Step 2, then launch.
| Architecture | Instance types | Recommended |
|---|---|---|
| x86_64 | t3.medium to t3.2xlarge; m7i, c7i, r7i large to 4xlarge | m7i.large |
| arm64 (Graviton) | t4g.medium to t4g.2xlarge; m7g, c7g, r7g large to 4xlarge | m7g.large |
Using the AWS CLI
aws ec2 run-instances \
--image-id <AMI_ID_FROM_MARKETPLACE> \
--instance-type m7i.large \
--key-name <YOUR_KEY_PAIR> \
--security-group-ids <YOUR_SECURITY_GROUP> \
--subnet-id <YOUR_SUBNET> \
--metadata-options HttpTokens=required \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=hardened-ubuntu}]'
Use --instance-type m7g.large with the AMI from the Graviton (arm64) edition.
Step 2 — Open the right port
| Port | Protocol | Purpose | Allow from |
|---|---|---|---|
| 22 | TCP | SSH administration | Your own network, admin IP or bastion host only |
Never open port 22 to 0.0.0.0/0. The image has no host firewall; your security group is the network control.
Step 3 — Connect over SSH
ssh -i "your-key.pem" ubuntu@<INSTANCE_IP>
If you get a permission error on the key file, run chmod 400 your-key.pem. Only the ubuntu user can log in over SSH.
Check that first-boot setup has finished:
systemctl status ioanyt-firstboot --no-pager
When setup has finished, the service shows active (exited). Confirm administration works:
sudo -n true && echo ok
Use sudo for administration. The root account is locked.
Step 4 — File-integrity (AIDE) baseline
About 5 minutes after boot, the instance builds its own AIDE baseline. It is finished when this file exists:
test -f /var/lib/ioanyt/aide-init.done && echo "AIDE baseline ready"
Then run a check:
sudo aide --config /etc/aide/aide.conf --check
Right after the baseline, expect reports only for frequently changing locations such as /var/log, /var/lib, /var/cache and /run. A change anywhere else deserves a look.
Step 5 — Keep it patched
Security updates install automatically (unattended-upgrades). Apply all other updates in your own maintenance window, then reboot if the kernel was updated:
sudo apt update && sudo apt upgrade
The upgrade runs without configuration-file prompts. One packaged file, /etc/pam.d/sshd, is changed on purpose by CIS control 1.6.1 (the dynamic message of the day is switched off) and stays as hardened after upgrades.
Day-2 operations
Hardening you should know about
- SSH users: only
ubuntumay log in over SSH, with a key. Password login is disabled. - Disabled filesystem modules: some unused filesystem modules (NFS/EFS, FUSE, Docker overlay) are disabled by CIS hardening. To re-enable them, delete
/etc/modprobe.d/ioanyt-cis-unused-fs.confand reboot. - /tmp is mounted with
noexec: programs can’t run from it. - Root is locked. Use
sudofrom theubuntuaccount.
Sending logs to your own server
Remote journal upload is not configured because the target is your own log server. systemd-journal-remote is installed: configure /etc/systemd/journal-upload.conf and enable systemd-journal-upload.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| SSH connection times out | Security group or network path | Allow port 22 from your network (Step 2), and check routing or VPN. |
SSH Permission denied | Key file permissions, or wrong user | Run chmod 400 your-key.pem and log in as ubuntu. |
ioanyt-firstboot is not active (exited) yet | Setup still running | Wait a few minutes and check again. Then run sudo journalctl -u ioanyt-firstboot. |
| AIDE check reports no baseline | The baseline is built about 5 minutes after boot | Wait, then look for /var/lib/ioanyt/aide-init.done (Step 4). |
| EFS/NFS mount or Docker fails | Filesystem modules disabled by CIS hardening | See “Hardening you should know about”. |
Program won’t run from /tmp | /tmp is mounted noexec | Run it from another directory, such as your home directory. |
Support
Email aws-marketplace-support@ioanyt.com. We reply within 1 business day. Include your instance ID and Region.