O2
Operating Systems Azure

OpenWrt 25.12 on Azure User Guide

| Product: OpenWrt 25.12 on Azure

Overview

This guide covers deploying OpenWrt 25.12 on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

OpenWrt is a free, open source (GPL 2.0) Linux distribution for routers and network appliances. It is not a general purpose server OS: it is built from BusyBox, procd, netifd, uci and dropbear, and it is managed either from the command line over SSH or from the LuCI web interface. This image is the official OpenWrt x86 64 build, adapted by cloudimg to run as a first class Azure virtual machine.

Because OpenWrt is an agentless system (no cloud-init, no Azure Linux Agent, no systemd), cloudimg adds one small first boot service so the image behaves like any other Azure VM: it reads the SSH key you supply at deploy time from the Azure Instance Metadata Service and installs it, and it reports provisioning success to the Azure fabric so the VM comes up cleanly.

What's included:

  • OpenWrt 25.12, the current stable release, official x86 64 build
  • Agentless Azure integration: your SSH key is injected at first boot from the Instance Metadata Service, with no baked in credential
  • eth0 configured for DHCP so the VM gets its Azure address and routes automatically
  • Firewall open only for SSH (22) and the LuCI web UI (443); everything else is rejected
  • LuCI web administration interface on HTTPS (443), self signed
  • Per machine identity: dropbear regenerates its SSH host keys on first boot, and the hostname is taken from Azure
  • Gen2 Hyper V (UEFI) virtual machine support
  • 24/7 cloudimg support

Platform: Microsoft Azure (Gen2 Hyper V / UEFI) Default user: root (key only; no password)

Security posture

This image ships with no known credential. There is no default password and no baked in SSH key:

  • The root account has no password and password authentication is disabled in dropbear (PasswordAuth and RootPasswordAuth are both off), so every login is by key.
  • The only key that works is the public key you supply when you create the virtual machine. OpenWrt has no Azure agent, so cloudimg's first boot service reads that key from the Instance Metadata Service and installs it into dropbear. No two machines you launch ever share a secret.
  • No SSH host keys are baked into the image. dropbear generates its own on first boot, so two machines built from this image never share a host identity.
  • The firewall rejects all inbound traffic on the Azure interface except SSH (22) and LuCI HTTPS (443). Your Azure Network Security Group is the outer boundary and should be scoped to your management address.

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 VM access
  4. Familiarity with Azure VM management

Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger.

Step 1: Deploy the Virtual Machine

Deploy from the Azure Marketplace listing, supplying your own SSH public key. The key is injected at first boot from the Instance Metadata Service.

az vm create \
  --resource-group my-rg \
  --name my-openwrt \
  --image <cloudimg-openwrt-marketplace-image> \
  --size Standard_B2s \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

Scope the Network Security Group so that inbound 22 (and 443 if you want LuCI) is reachable only from your management address.

Step 2: Connect over SSH

OpenWrt's default (and only) administrative user is root. Connect with the private key that matches the public key you supplied:

ssh -i ~/.ssh/id_rsa root@<vm-public-ip>

There is no password prompt: password authentication is disabled, so only your key works.

Step 3: Verify the image on the VM

Once connected, confirm the release and that the cloudimg first boot service injected your key and reported provisioning to Azure:

cat /etc/openwrt_release
logread | grep cloudimg-imds

Confirm your SSH key is installed and password authentication is disabled (no baked credential):

cat /etc/dropbear/authorized_keys
uci get dropbear.@dropbear[0].PasswordAuth

Step 4: Verify networking and the firewall

eth0 is configured for DHCP so the VM takes its Azure address automatically. The firewall opens only SSH and LuCI:

uci show network.wan
ip -4 addr show eth0 | grep inet
netstat -ltn | grep -E ':22|:443'
uci show firewall | grep Azure

Step 5: The LuCI web interface

LuCI, the OpenWrt web administration interface, listens on HTTPS port 443 with a self signed certificate. If your Network Security Group allows inbound 443 from your address, browse to:

https://<vm-public-ip>/

Because OpenWrt root has no password, set one before you rely on LuCI's web login (this also enables password login at the LuCI console; SSH remains key only unless you re enable it deliberately):

passwd

Step 6: Updating the image

OpenWrt does not ship an unattended update daemon. There is no dnf-automatic or unattended-upgrades equivalent, and this is by design for an appliance OS. OpenWrt 25.12 uses the apk package manager (apk-tools 3.x, which replaced opkg in the 25.x series). You update in one of two honest ways:

  • Package updates with apk: refresh the package index and add available updates for individual packages.
apk list --installed | wc -l
  • Whole system upgrade with sysupgrade: OpenWrt point and feature releases are applied by flashing a newer image with sysupgrade, which preserves your /etc/config settings. For a cloud VM the simplest path to a new OpenWrt release is to deploy a newer cloudimg image and migrate your uci configuration.

Plan your update cadence accordingly: subscribe to OpenWrt security advisories and apply opkg updates or re deploy on a schedule that suits your risk posture.

Support

This image is supported 24/7 by cloudimg. For assistance, contact support through the Azure Marketplace listing.