Fedora Linux 44 Cloud Edition on Azure User Guide

Overview

This guide covers deploying and operating Fedora Linux 44 Cloud Edition on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Fedora® Linux is the community distribution sponsored by Red Hat, and it is where a great deal of enterprise Linux technology appears first. This image is built from the official Fedora Cloud Edition base image published by the Fedora Project, brought fully up to date at build time, hardened for server use, and configured to keep patching itself once it is yours. No application is preinstalled: the operating system itself is the product, ready for you to build your own services on.

Read this before you deploy: Fedora Linux has a short support life. Each Fedora Linux release is maintained for roughly 13 months, not for years. Fedora Linux 44 reaches end of life on 2 June 2027. After that date it stops receiving security updates entirely, so you must plan to upgrade to a newer Fedora Linux release, or migrate to a long term supported distribution, before then. Choose this image when you want current packages and a fast moving toolchain; choose an enterprise distribution such as Rocky Linux, AlmaLinux or Red Hat Enterprise Linux when you need a multi year support window. Step 8 covers the upgrade path.

What's included:

• Fedora Linux 44 Cloud Edition, x86_64, built from the official Fedora Project cloud image
• Brought fully up to date at build time, with zero pending updates at capture
• Automatic security updates armed so your VM keeps patching itself from first boot
• Secure by default: SELinux in enforcing mode, key only SSH, password authentication disabled, root login locked
• No baked in credentials and no baked in SSH host keys, so no two VMs ever share a secret
• No swap baked into the image, per Azure image guidance
• Azure Linux Agent (waagent) and cloud-init for Azure integration, chronyd for time synchronisation
• Gen2 Hyper V virtual machine support, 30 GB btrfs root
• 24/7 cloudimg support

Platform: Microsoft Azure (Gen2 Hyper V) Default user: azureuser (created from the SSH key you supply at deploy time)

Prerequisites

Before deploying this image, ensure you have:

1. An active Microsoft Azure subscription
2. Access to the Azure Portal or Azure CLI
3. An SSH key pair for Linux VM access
4. Familiarity with Azure VM management

Recommended VM size: Standard_B2s (2 vCPU, 4 GB RAM) or larger. Fedora Linux 44 runs comfortably across the B, D and E series; scale to suit your workload.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. In the Azure Marketplace, search for "Fedora Linux 44 cloudimg"
2. Select the image and click Create
3. Configure the basics:
4. Subscription: your Azure subscription
5. Resource Group: create new or select existing
6. Virtual Machine Name: a name for your VM
7. Region: your preferred Azure region
8. Size: Standard_B2s recommended
9. Under Administrator Account, select SSH public key and paste your public key. This key becomes the azureuser login; the image ships no password and no pre installed key.
10. Under Inbound Port Rules, allow SSH (port 22)
11. Click Review + Create, then Create

Option B: Azure CLI

az vm create \
  --resource-group myResourceGroup \
  --name my-fedora-vm \
  --image cloudimg:fedora-server:fedora44:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

Restrict inbound SSH to your own network rather than leaving it open to the internet.

Step 2: Connect to the Virtual Machine

Connect with the private key matching the public key you supplied at deploy time:

ssh azureuser@<vm-ip>

There is no password to type and no default credential to change, because the image ships neither. The azureuser account is created by Azure at provision time from the key you chose, and it has passwordless sudo.

Step 3: Verify the Operating System Release

Confirm the VM is running the Fedora Linux release you expect:

cat /etc/fedora-release
grep -E 'PRETTY_NAME|VERSION_ID' /etc/os-release
uname -r

Expected output:

Fedora release 44 (Forty Four)
VERSION_ID=44
PRETTY_NAME="Fedora Linux 44 (Cloud Edition)"
7.1.4-204.fc44.x86_64

The kernel version will be at or newer than the one shown above, because the image keeps patching itself after you deploy it.

Step 4: Confirm the Image Is Fully Patched

This image is built to a hard gate: it is not captured until dnf reports zero pending updates and no pending reboot. Verify it yourself:

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

An exit code of 0 means fully patched. An exit code of 100 means updates are pending, which is normal and expected on any VM that has been running for a while, because Fedora Linux publishes updates continuously.

Check whether a reboot is needed to activate what has already been installed:

sudo dnf needs-restarting -r; echo "exit=$?"

An exit code of 0 means no reboot is outstanding.

To apply everything currently available and reboot on your own schedule:

sudo dnf -y upgrade --refresh
sudo systemctl reboot

Step 5: Review the Default Security Posture

This image is hardened before capture. Verify each control:

getenforce
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin)'
sudo passwd -S root | awk '{print $1, $2}'
swapon --show; echo "(no output above means no swap)"

Expected output:

Enforcing
permitrootlogin prohibit-password
passwordauthentication no
root L
(no output above means no swap)

What each line means:

• Enforcing — SELinux is active and enforcing policy, which is the Fedora Linux default and is deliberately preserved in this image. Do not set it to permissive unless you are diagnosing a specific denial.
• permitrootlogin prohibit-password — root cannot log in over SSH with a password. This is read from the running daemon with sshd -T, so it reflects what SSH actually does rather than what a config file claims.
• passwordauthentication no — SSH accepts keys only.
• root L — the root password is locked. There is no root password to guess or leak.
• no swap — see Step 7 if you want swap on this VM.

Confirm that nothing beyond SSH is listening on a routable address:

ss -tulnH | awk '{print $1, $5}' | sort -u

Only sshd on port 22 should appear on a non loopback address. The Fedora Cloud default of LLMNR name resolution, which listens on every interface on port 5355, is disabled in this image.

Per VM identity: host keys and machine-id

Every VM launched from this image generates its own SSH host keys and its own /etc/machine-id on first boot. Nothing is inherited from the machine the image was built on, so no two customer VMs share a host key or a systemd identity. Verify:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
cat /etc/machine-id

Launch a second VM from the same image and you will see different values on each.

Step 6: Automatic Security Updates

Because Fedora Linux moves quickly, this image arms automatic security updates before capture so your VM does not silently fall behind. Verify:

systemctl is-enabled dnf5-automatic.timer
grep -E 'upgrade_type|apply_updates|reboot' /etc/dnf/automatic.conf
systemctl list-timers dnf5-automatic.timer --no-pager

Expected output:

enabled
apply_updates = yes
upgrade_type = security
reboot = never

The configuration means: download and apply security updates automatically, and never reboot on its own. Kernel and core library updates therefore install automatically but only take effect when you reboot, so you stay in control of downtime. Check whether a reboot is outstanding with sudo dnf needs-restarting -r.

To change the policy, edit /etc/dnf/automatic.conf (which overrides the packaged defaults in /usr/share/dnf5/dnf5-plugins/automatic.conf) and restart the timer. To apply all updates rather than security only, set upgrade_type = default. To disable automatic updates entirely:

sudo systemctl disable --now dnf5-automatic.timer

Step 7: Swap

This image ships with no swap, which follows Azure guidance that swap should not live on the OS disk. Fedora Linux normally enables a compressed RAM swap device via zram-generator; that is disabled here.

If your workload benefits from swap, the recommended option on Azure is compressed RAM swap, which costs no disk and no cloud storage IOPS:

sudo dnf -y install zram-generator-defaults
printf '[zram0]\nzram-size = min(ram / 2, 4096)\n' | sudo tee /etc/systemd/zram-generator.conf
sudo systemctl daemon-reload
sudo systemctl start systemd-zram-setup@zram0.service

Alternatively, have the Azure Linux Agent place a swap file on the ephemeral resource disk (/mnt) rather than the OS disk, by setting ResourceDisk.EnableSwap=y and ResourceDisk.SwapSizeMB in /etc/waagent.conf and restarting waagent. Never place swap on the OS disk.

Step 8: Fedora Linux Lifecycle and Upgrading

Fedora Linux releases arrive roughly every six months and each release is supported for about 13 months, which is around one month after the release of the second subsequent version.

Release	Status	End of life
Fedora Linux 44	Current, shipped by this image	2 June 2027
Fedora Linux 43	Maintained	2 December 2026

Plan your upgrade before the end of life date. After it passes, no further security updates are published for that release and the VM should be considered unsupported.

To move a running VM to the next Fedora Linux release in place, use the system upgrade plugin. Snapshot the OS disk first, and expect a reboot:

sudo dnf -y upgrade --refresh
sudo dnf -y install dnf5-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=45
sudo dnf system-upgrade reboot

Many teams prefer to deploy a fresh VM from the newer cloudimg image and migrate their workload across, which avoids in place upgrade risk entirely.

Step 9: Azure Platform Integration

The image is configured for Azure rather than merely running on it:

systemctl is-active waagent
systemctl is-active chronyd
cloud-init status

All three should report a healthy state (active, active, status: done).

• Provisioning — the Azure Linux Agent and cloud-init create your azureuser account, inject your SSH public key, and set the hostname you chose in the portal. This is exercised on every boot from this image.
• Serial console — the kernel is configured with console=ttyS0, so the Azure serial console and boot diagnostics work when you need to recover a VM that will not accept SSH. Confirm with cat /proc/cmdline.
• Ephemeral resource disk — Azure attaches a temporary disk that the agent mounts at /mnt. It is not durable: it is wiped on deallocation and on host maintenance. Use it for scratch and caches only, never for data you need to keep.
• VM extensions — the agent is present and enabled, so Azure extensions such as the Custom Script Extension, Azure Monitor Agent and backup extensions install normally.

Step 10: Installing Software

The standard Fedora repositories are enabled, so the full Fedora Linux package set is available:

dnf repolist --enabled

sudo dnf -y install nginx
sudo systemctl enable --now nginx

Remember to open the matching port in your Azure network security group as well as any host firewall you choose to add. This image installs no host firewall, on the basis that the Azure network security group is the primary control; install and configure firewalld if you want defence in depth:

sudo dnf -y install firewalld
sudo systemctl enable --now firewalld

Fedora Server Edition's Cockpit web console is not preinstalled in this Cloud Edition based image, but it is one command away if you want it:

sudo dnf -y install cockpit
sudo systemctl enable --now cockpit.socket

Troubleshooting

Cannot SSH in. Check the Azure network security group allows port 22 from your address, that you are using the private key matching the public key supplied at deploy time, and that the user is azureuser. There is no password login: PasswordAuthentication is no, so a password prompt means your key was not offered.

A service will not start and the logs mention permission denied. SELinux is enforcing. Check for denials with sudo ausearch -m avc -ts recent or sudo journalctl -t setroubleshoot. The correct fix is almost always a policy adjustment or a file context correction with sudo restorecon -Rv <path>, not disabling SELinux.

dnf reports pending updates. That is expected on a running VM; Fedora Linux publishes updates continuously. Automatic security updates install them; run sudo dnf -y upgrade --refresh to apply everything, and reboot if sudo dnf needs-restarting -r says so.

A reboot never seems to clear needs-restarting. Some updates install after your last reboot. Run the upgrade, then reboot, then re-check.

Out of memory on a small VM. This image ships no swap by design. Either move to a larger VM size or enable compressed RAM swap as shown in Step 7.

Disk is full. The root filesystem is btrfs. Check usage with df -h / and sudo btrfs filesystem usage /. You can grow the OS disk in the Azure portal and then extend the filesystem with sudo btrfs filesystem resize max /.

Support

cloudimg provides 24/7 support for this image, covering deployment, Azure integration and image specific questions. Support for the Fedora Linux operating system itself is community based; see the Fedora Project for documentation, forums and mailing lists.

Licence and Trademarks

Fedora Linux is free and open source software. It is not distributed under a single licence: it is a collection of many thousands of packages under a wide range of predominantly free and open source licences, including the GPL, LGPL, MIT, BSD and Apache licences. The licence that applies to any individual package is the licence of that package; you can inspect it with rpm -qi <package> or in /usr/share/licenses/. There is no subscription or paid entitlement required to use Fedora Linux.

This image contains Fedora software obtained from the official Fedora Project repositories. It is provided by cloudimg and is not provided, endorsed or supported by the Fedora Project or Red Hat, Inc. Official, unmodified Fedora software is available from the Fedora Project at https://fedoraproject.org/.

Fedora and the Infinity design logo are trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. cloudimg is not affiliated with, sponsored by or endorsed by Red Hat, Inc. or the Fedora Project.