Azure VM Configuration with cloud-init and Key-Based SSH

cloud-init is the industry-standard bootstrap system baked into every major cloud Linux image. The file must start with the literal header #cloud-config on line one, without it the VM treats the content as inert data and nothing happens. The directives below are deliberately minimal: refresh package metadata, install nginx, then enable and start it. Because this is declarative, re-running the lab produces an identically configured server every time.

# cloud-init.yaml
#cloud-config
package_update: true
packages: [nginx]
runcmd:
  - systemctl enable --now nginx

Expected output:

$ cloud-init schema --config-file cloud-init.yaml
Valid cloud-config: cloud-init.yaml

package_update: true runs the equivalent of apt-get update so the package index is fresh; packages is a list of APT packages to install; runcmd executes arbitrary commands late in the boot, after packages are in place. The -now flag both enables nginx at boot and starts it immediately.

cloud-init can do far more than install packages, and the same file format scales to real hardening work: a write_files block can drop a tuned sshd_config or nginx site config in place, a users block can create additional accounts with their own keys, and setting ssh_pwauth: false makes the key-only posture explicit in the file itself rather than relying on Azure's default. For this lab the three directives above are enough, add complexity only when the simple version works.

One behavior to internalize early: custom data runs once, on first boot. Editing the file on your laptop does nothing to an existing VM, and re-attaching it does not re-trigger the run. The supported way to iterate is to wipe cloud-init's state on the VM (sudo cloud-init clean --logs), reboot, and let it treat the next boot as the first, or simply delete the VM and redeploy, which in this lab takes about two minutes.

Common mistake: broken YAML. cloud-init files are whitespace-sensitive, a tab character or misaligned list item makes the run fail silently. Validate locally before deploying with cloud-init schema --config-file cloud-init.yaml if you have cloud-init installed locally, or at minimum paste it through a YAML linter.

What this teaches: cloud-init turns a generic marketplace image into a configured server during first boot; everything after depends on this file being right.

One command creates the VM, attaches it to your existing web subnet, injects your public key for the taki user, and passes the cloud-init file as custom data. Passing -ssh-key-values (instead of -admin-password) is what disables password authentication in sshd, Azure configures the image for key-only auth automatically when a key is supplied. Each flag earns its place: -image Ubuntu2204 selects the LTS image alias, -vnet-name/-subnet place the NIC inside your own network rather than a throwaway one, and -custom-data wires in the bootstrap file from step 01.

On size: without a -size flag Azure picks a default for the image (typically a D-series general-purpose VM). For a lab, a burstable B-series is dramatically cheaper and perfectly adequate, add -size Standard_B2s if your subscription quota allows it. Size never affects the security posture, only the bill and the speed of the package install.

Note on the admin username: Azure reserves names like root, admin, and administrator and will reject them outright. Using a personal, non-obvious username such as taki also shaves a little noise off the constant background hum of bots trying root against every open port 22 on the internet.

Two useful variations on the same command: -ssh-key-values accepts several public keys separated by spaces if more than one person needs access, and swapping -image for another alias (such as Debian11 or a full URN) changes the operating system without touching anything else, cloud-init's package and runcmd model is the same across Debian-family images.

The command blocks for a minute or two while Azure provisions the resources (VM, NIC, public IP, managed OS disk, and an auto-created NSG named web01NSG), then returns a large JSON document. The two fields worth noting are the provisioning state and the public IP:

That single command actually created five separate billable resources in tyf-rg. Listing them is a good sanity check, and it also shows you exactly what to clean up later:

How to verify: "provisioningState": "Succeeded" only means the VM resource exists, it says nothing about cloud-init, which typically still needs another 1-3 minutes to finish installing packages. Do not panic if nginx is not answering the second the command returns; step 05 shows how to wait properly.

Common mistake: omitting -vnet-name/-subnet. Without them, Azure silently creates a new VNet for the VM, and it will not be in the segmented network you built in the VNet lab. If that happened, delete the VM and redeploy, you cannot move a VM's NIC between VNets in place.

Expected output:

{
  "name": "tyf-vm01",
  "provisioningState": "Succeeded",
  "publicIpAddress": "20.42.17.9"
}

What this teaches: Key-based auth removes passwords from the equation; the private key never leaves your machine.

az vm open-port adds an inbound allow rule for port 22 to the VM's NSG, but its default source is *, the whole internet. Leaving SSH open to the world invites password-spraying and key-scanning bots within minutes, so the second half of the command rewrites that rule's source to the single /32 address you recorded during setup. Priority 100 places the rule ahead of the lower-priority default rules so it takes effect deterministically.

NSGs evaluate rules in priority order, lowest number first, and stop at the first match. Below your new priority-100 allow sit Azure's default rules: AllowVnetInBound (priority 65000) permits traffic inside the VNet, and DenyAllInBound (priority 65500) refuses everything else. The practical result is exactly what you want, your IP reaches SSH, other VNet resources can still talk to the VM, and the rest of the internet is dropped without you writing a single deny rule.

How to verify: list the rules and confirm exactly one inbound allow exists for port 22 with your /32 as the source:

For the authoritative view of what the VM's NIC will actually permit, which matters once subnet-level NSGs enter the picture in the next lab, ask the NIC for its effective rules, which merges every NSG applied to it:

Common mistake: scoping the rule to an IP that later changes. Home connections usually sit behind dynamic DHCP addresses; if SSH suddenly stops working next week, re-run curl -s https://ifconfig.me and update the rule with the new address before assuming the VM is broken.

Expected output:

{
  "name": "allow-ssh-home",
  "properties": {
    "access": "Allow",
    "destinationPortRange": "22",
    "priority": 100,
    "provisioningState": "Succeeded"
  }
}

What this teaches: An NSG rule for your IP is allowlisting at the network edge; it shrinks the audience for SSH from the internet to one address.

Rather than copying the public IP out of the portal, query it directly from Azure and feed it straight to the SSH client. The $() substitution runs az vm show -d (the -d shows runtime details including the public IP) and prints just the address as plain text. The private key in the default location is offered automatically, so no password prompt should ever appear.

On first connection the client asks you to trust the server's host key, this is normal exactly once per host:

If the connection fails, add -v (or -vvv for maximum detail) to the SSH command, the verbose output shows exactly which keys the client offered and what the server rejected, which turns "permission denied" mysteries into ten-second diagnoses.

If you will manage this box regularly, save yourself the substitution dance with an entry in your SSH config. After this, ssh web01 is the whole command:

# ~/.ssh/config
Host web01
  HostName 20.151.42.17
  User taki
  IdentityFile ~/.ssh/id_ed25519

Expected output:

The authenticity of host '20.42.17.9' can't be established.
ED25519 key fingerprint is SHA256:EXAMPLEfingerprint.
Are you sure you want to continue connecting (yes/no)? yes
taki@tyf-vm01:~$

How to verify: you land at a shell prompt on web01 without ever being asked for a password. If you are prompted for a password at any point, key authentication is not in play, see the Troubleshooting section before typing anything.

Common mistake: a REMOTE HOST IDENTIFICATION HAS CHANGED warning on a later rebuild. Deleting and recreating the VM gives the same IP a new host key; remove the stale entry with ssh-keygen -R 20.151.42.17 and reconnect.

What this teaches: The first SSH connection verifies the whole chain at once: network path, key auth, and a running SSH daemon.

Never assume the bootstrap ran, check it. cloud-init status --wait blocks until the run completes and then reports the outcome, which makes it perfect for scripts and for the few minutes right after provisioning. A done status with exit code 0 means every directive in your file executed without error.

cloud-init runs in stages, network configuration first, then module stages for packages and config, and runcmd near the end, which is why a VM can accept SSH connections while the bootstrap is still mid-flight. Connecting early is harmless; just do not judge the result until the status reads done. If you are curious where the time went, cloud-init analyze show prints a per-module timing breakdown:

If anything failed, the human-readable log of everything your directives printed lives in /var/log/cloud-init-output.log; the structured module-by-module trace is in /var/log/cloud-init.log, and cloud-init's own state (including the data source it detected and per-module results) is kept under /var/lib/cloud/:

Common mistake: reading status: done as proof the service works. cloud-init reports on its own run, not on the health of what it installed, a package can install fine and still fail to start. The next step closes that gap.

Expected output:

$ cloud-init status --wait
status: done

What this teaches: cloud-init logs are the ground truth for boot customization; read them before guessing.

Two final checks turn "the VM exists" into "the lab worked". First, confirm nginx is actually running and answering on the VM itself, testing locally on the box sidesteps the NSG, which currently only allows port 22:

A listening-socket check confirms exactly which ports the box exposes, which should be 22 (sshd) and 80 (nginx) and nothing unexpected:

Second, prove the security posture rather than trusting it. Ask the running sshd for its effective configuration and confirm password authentication is off, this is the check that validates the key-only decision made back in step 02:

sshd -T dumps the effective config after all includes and defaults are resolved, so it cannot be fooled by a commented-out line or an unexpected file in sshd_config.d/ the way a plain grep over the config file can. While you are here, note that Ubuntu's unattended-upgrades is enabled on this image by default, so security patches apply themselves, one less thing to schedule. You can confirm with systemctl is-enabled unattended-upgrades, which should print enabled.

How to verify: active, the nginx welcome HTML, and passwordauthentication no together mean the server is bootstrapped, serving, and unreachable by password guessing. If you later want to browse to nginx from your own machine, open port 80 the same scoped way as step 03: az vm open-port -n web01 --port 80 --priority 110 and then update the rule's source to your /32.

Expected output:

$ curl -s -o /dev/null -w "%{http_code}" http://localhost/
200
$ ss -tlnp | grep :22
LISTEN 0 128 0.0.0.0:22

What this teaches: Verification has two halves: prove the service works, and prove the attack surface is as small as you intended.