Ubuntu 24.04 unattended-upgrades dey on by default?

Why automatic security updates dey worth setting up

Server wey no get patches na the easiest target for internet. Most breaches for small servers no dey involve clever tricks; na known bug for old package wey owner never update. Ubuntu get tool wey dey close this gap by itself: unattended-upgrades dey install security updates automatically, according to schedule, without you logging in. Na the cheapest security improvement wey you fit get for VPS, and for Ubuntu, setup na only few minutes.

The tool dey deliberately conservative. By default, e dey apply only security updates, no be every package upgrade, because security patch get low risk and e worth applying without review, while feature upgrade fit change behaviour wey you dey depend on. That default dey correct for most servers, and this guide go keep am while e show the few settings wey worth changing.

Step 1: Install and enable am

For Ubuntu 24.04, the package dey often present but e no always enabled. Install am and switch am on:

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

The dpkg-reconfigure prompt dey ask one yes-or-no question: whether to download and install stable updates automatically. Answer yes. That one go write the file wey switches 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 package list every day; the second dey run unattended upgrade every day. When both set to 1, e mean say machine dey check for and apply security updates every day, with systemd timer, without any further action from you.

Step 2: Decide wetin go apply automatically

The policy dey inside /etc/apt/apt.conf.d/50unattended-upgrades. Open am and check 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 the ones wey matter, and dem enabled by default. Na the conservative policy be that: security updates go enter automatically, while ordinary feature updates remain for you to apply by hand whenever you choose. You fit add the "${distro_id}:${distro_codename}-updates" origin line to apply all updates automatically, but for server wey dey host something wey matter to you, applying only security patches automatically na the safer default. Leave am as e ship unless you get specific reason to change am.

Step 3: Handle reboots

Some updates, like kernel or core library, only go take full effect after reboot. unattended-upgrades no go reboot your server unless you tell am to, which mean say patched kernel fit remain unused until you restart the server. Decide how you want handle this, and set am clearly inside 50unattended-upgrades:

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

That one go reboot the server by 4 in the morning when, and only when, an update require am. For one VPS wey no get cluster to fail over to, short early-morning reboot normally na the correct trade-off for staying current with kernel fixes. If your server dey run something wey must never restart unexpectedly, leave reboot off and make habit of rebooting by yourself after you check /var/run/reboot-required.

Step 4: Prove say e dey work

No wait one day before you find out whether the job dey run. Trigger dry run wey go show exactly wetin go apply, without changing anything:

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

The output dey list the packages wey e consider and the origins wey dem come from, so you fit see the policy as e 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 “my server dey patch itself?” If e show security packages wey dey install according to schedule, the job dey work.

Where this one fit

Automatic updates na one layer of hardened server, no be the whole thing. Dem dey stop known bugs from remaining, but dem no do anything about who fit log in or wetin dey exposed. Join am with key-only SSH hardening so nobody fit brute-force the entry point, default-deny UFW firewall so only the things wey you choose fit reachable, and unprivileged service users so breached app no fit take control of the whole machine. The apps wey you host get their own secrets on top of all this, so if this machine dey run self-hosted password vault, a Vaultwarden hardening pass go protect the admin token and backup file wey no amount of apt patching fit protect. Patching dey close the holes wey you know; 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, na only security updates. The Allowed-Origins block inside /etc/apt/apt.conf.d/50unattended-upgrades dey enable -security origins and leave ordinary feature updates for you to apply by hand. Na deliberate choice: security patches get low risk and worth applying automatically, while feature upgrades fit change behaviour, so most servers suppose keep the conservative default.

Will automatic updates reboot my server?

Only if you tell dem to. Set Unattended-Upgrade::Automatic-Reboot "true" and Automatic-Reboot-Time inside the config, and the server go reboot at that time when update require am, for example after kernel patch. If you leave am off, patched kernel go wait until you reboot by 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 now, without changing anything, and read /var/log/unattended-upgrades/unattended-upgrades.log for record of past runs; every automatic install also dey enter /var/log/apt/history.log. If the log show security packages installed every day according to schedule, the timer dey work. If the dry run print No packages found that can be upgraded unattended, e either mean say everything don 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 be necessary layer. E dey stop known vulnerabilities from remaining unpatched, which dey prevent the commonest type of breach, but e no control access or exposure. Combine am with SSH hardening, default-deny firewall, and least-privilege service users to get server wey genuinely hard to break into.