Fedora Server

Option A: Azure Portal

• In the Azure Marketplace, search for "Fedora Linux 44 SecureAnyCloud".
• Select the image and click Create.
• Configure the basics:
  • Subscription: your Azure subscription.
  • Resource Group: create a new one or select an existing one.
  • Virtual Machine Name: a name for your VM.
  • Region: your preferred Azure region.
  • Size: Standard_B2s is recommended.
• 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 preinstalled key.
• Under Inbound Port Rules, allow SSH (port 22).
• Click Review + Create, then click Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:fedora-server:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-fedora-vm \
  --image sac1647283583153:fedora-server:default: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.

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. Azure creates the azureuser account at provision time from the key you chose, and the account has passwordless sudo.

Confirm that 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

Your kernel version will be the same as or newer than the one shown, because the image keeps patching itself after you deploy it.

This image is not captured until dnf reports zero pending updates and no pending reboot. Check for updates released since the build:

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

An exit code of 0 means the VM is fully patched. An exit code of 100 means updates are pending. This is normal 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 is already installed:

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

An exit code of 0 means no reboot is outstanding.

To apply everything currently available, then reboot on your own schedule, run:

sudo dnf -y upgrade --refresh sudo systemctl reboot

This image is hardened before capture. Verify each control with these commands:

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)

Each line of the output means the following:

• Enforcing: SELinux is active and enforcing policy. This is the Fedora Linux default, and the image deliberately preserves it. 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. The value 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 image disables the Fedora Cloud default of LLMNR name resolution, which listens on every interface on port 5355.

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 this with:

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

If you launch a second VM from the same image, it shows different values.

Fedora Linux moves quickly, so this image arms automatic security updates before capture. Your VM does not silently fall behind. Verify the setup with:

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

This configuration downloads and applies security updates automatically, and it never reboots on its own. Kernel and core library updates 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 and restart the timer. This file overrides the packaged defaults in /usr/share/dnf5/dnf5-plugins/automatic.conf. To apply all updates rather than security updates only, set upgrade_type = default.

To disable automatic updates entirely, run:

sudo systemctl disable --now dnf5-automatic.timer

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 through zram-generator, but the image disables it.

If your workload benefits from swap, the recommended option on Azure is compressed RAM swap. It 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. Set ResourceDisk.EnableSwap=y and ResourceDisk.SwapSizeMB in /etc/waagent.conf, then restart waagent. Never place swap on the OS disk.

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

• Fedora Linux 44: current, shipped by this image. End of life: 2 June 2027.
• Fedora Linux 43: maintained. End of life: 2 December 2026.

Plan your upgrade before the end of life date. After that date, no further security updates are published for the release, and you should treat the VM as 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 SecureAnyCloud image and migrate their workload across. This avoids the risk of an in-place upgrade entirely.

The image is configured for Azure rather than merely running on it. Check the agent and time services:

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

All three should report a healthy state (active, active and 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 the setting with cat /proc/cmdline.
• Ephemeral resource disk: Azure attaches a temporary disk that the agent mounts at /mnt. The disk is not durable, because it is wiped on deallocation and on host maintenance. Use it for scratch data 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.

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

Open the matching port in your Azure network security group, and in any host firewall you choose to add. This image installs no host firewall, because 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

The Cockpit web console from Fedora Server Edition is not preinstalled in this Cloud Edition-based image. To add it, run:

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