Ubuntu 24.04 unattended-upgrades on by default?

Why automatic security updates worth setting up

Server wey no get patch na easy target for internet. Most small server breach no be because hackers sabi magic; na just known bug for old package wey owner no update. Ubuntu carry tool wey go fix that problem for you: unattended-upgrades dey install security updates automatically, on a schedule, without you need to log in. Na cheap security win for VPS, and for Ubuntu, e only take few minutes to setup.

The tool dey act very careful. By default, e only dey apply security updates, no be every package upgrade, because security patch low-risk and e worth to take without review, while feature upgrade fit change how things dey work wey you dey rely on. That default na the right one for most servers, and this guide go keep am while e show you the few settings wey worth to change.

Step 1: Install and enable it

On Ubuntu 24.4, the package dey often dey there but e no always enabled. Install am and turn am on:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

The dpkg-reconfigure prompt go ask one yes-or-no question, if e should download and install stable updates automatically. Answer yes. That go write the file wey go switch the daily job on:

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

The first line dey refresh the package list daily; the second one dey run the unattended upgrade daily. Both set to 1 means the machine go check and apply security updates every day, on a systemd timer, without you need to do anything.

Step 2: Decide what gets applied automatically

The policy dey inside /etc/apt/apt.conf.d/50unattended-upgrades. Open am and look at the Allowed-Origins block near the top:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

The -security lines na dem be the ones wey matter, and dem dey enabled by default. Na that conservative policy: security updates dey come in, but ordinary feature updates dey stay for you to apply by hand when you choose. You fit add the "${distro_id}:${distro_codename}-updates" origin line to auto-apply all updates, but for server wey dey host something wey you care about, to take only security patches automatically na the safer default. Leave am as e dey come unless you get specific reason to change am.

Step 3: Handle reboots

Some updates, like kernel or core library, only dey work fully after reboot. unattended-upgrades no go reboot your server unless you tell am to, which means patched kernel fit sit dey unused until you decide to restart. Decide how you want handle that, and set am clearly for 50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

That one go reboot the server at four in the morning when, and only when, update need am. For single VPS wey no get cluster to fail over to, small early-morning reboot na the right trade to stay current with kernel fixes. If your server dey run something wey must never restart unexpectedly, leave the reboot off and make habit to reboot yourself after you check /var/run/reboot-required.

Step 4: Prove it works

No wait one day to find out if the job dey run. Trigger a dry run wey go show exactly wetin go apply, without change anything:

sudo unattended-upgrade --dry-run --debug

The output go list the packages wey e dey consider and where dem dey come from, so you fit see the policy dey work. After the real job don run at least once, the record dey here:

cat /var/log/unattended-upgrades/unattended-upgrades.log

That log na the answer to "is my server actually patching itself." If e show security packages dey install on a schedule, the job dey work.

Where this fits

Automatic updates na one layer for hardened server, no be the whole thing. Dem dey keep known bugs from staying too long, but dem no dey do anything about who fit log in or wetin dey exposed. Pair dem with key-only SSH hardening so dem no fit brute-force the front door, a default-deny UFW firewall so only wetin you choose fit reach, and unprivileged service users so compromised app no fit take over the whole box. Patching dey close the holes wey you know about; the other layers dey limit damage from the ones wey you no know.

FAQ

Does unattended-upgrades apply every update or only security ones?

By default, only security updates. The Allowed-Origins block for /etc/apt/apt.conf.d/50unattended-upgrades dey enable the -security origins and dey leave ordinary feature updates for you to apply by hand. Na deliberate thing: security patches low-risk and worth to take automatically, while feature upgrades fit change how things work, so most servers should keep the conservative default.

Will automatic updates reboot my server?

Only if you tell dem to. Set Unattended-Upgrade::Automatic-Reboot "true" and an Automatic-Reboot-Time for the config, and the server go reboot at that time when update need am, for example after kernel patch. If you leave am off, patched kernel go wait until you reboot yourself; check /var/run/reboot-required to know when one dey pending.

How do I check that automatic updates are actually running?

Run sudo unattended-upgrade --dry-run --debug to see wetin go apply right now, without change anything, and read /var/log/unattended-upgrades/unattended-upgrades.log for the record of past runs; every automatic install dey land for /var/log/apt/history.log too. If the log show security packages dey install on a daily schedule, the timer dey work. If the dry run print No packages found that can be upgraded unattended, e mean say everything already current or your allowed origins too narrow to match the security repository.

Is unattended-upgrades enough to keep my server secure?

No, but e na necessary layer. E dey keep known vulnerabilities from staying unpatched, wey dey stop the most common kind of breach, but e no dey control access or exposure. Combine am with SSH hardening, a default-deny firewall, and least-privilege service users for server wey truly hard to break into.