Microsoft Azure International Account Resetting Root Password on Azure Linux VM

So You Forgot the Root Password (Classic)

Let’s begin with the universal truth: passwords are like socks. You think you’ve got plenty, you store them carefully, and then one day you can’t find the one you need. Resetting the root password on an Azure Linux VM is one of those tasks that sounds dramatic until you actually do it—and then you realize it’s more “careful plumbing” than “wizardry.”

This guide is designed for humans with real jobs. The goal is simple: regain access to your Azure Linux Virtual Machine when the root password is unknown or lost. We’ll focus on a reliable, commonly used rescue approach: attaching the VM’s OS disk to a temporary recovery machine, correcting the credential, and booting the original VM again.

Along the way, we’ll cover alternatives, warnings, and the kinds of mistakes that turn a small fix into a long weekend of “why won’t it boot?”

What “Reset Root Password” Actually Means

On Linux, “root password reset” can mean different things depending on how your VM is configured:

• Changing the root account password (account: root).
• Resetting the wrong account because the “real” admin user is not root (common on modern distros).
• Unlocking account access if the account is locked or expired.

In many cloud images, you log in via a non-root user (like azureuser) with sudo. Root might be disabled, set to require a password you don’t know, or even blocked by configuration. So before we go hacking at passwords like we’re defusing a bomb, take a breath and confirm what access you actually need.

Before You Touch Anything: Check If You Actually Need Root

Many Azure Linux VMs are configured to allow SSH with a specific admin user and an SSH key. If your problem is only that you can’t log in because of the root password, but you still have SSH key access to your admin user, you might not need a root reset at all.

If you can log in as an admin user (example: azureuser), you can switch to root with:

sudo -i

Then set whatever root password you like (or better: set up your workflow so you rarely need root login).

If you cannot log in at all, carry on. We’re about to do the “disk rescue” method that usually works when passwords are forgotten.

Safety First: Permissions, Snapshots, and Minimal Chaos

Password resets aren’t inherently dangerous, but careless disk handling can be. Here are a few practical safety steps:

• Keep track of disk attachment points: the OS disk is not always the only disk.
• Don’t overwrite anything: we’ll mount the disk read-write only for the duration we need.
• Plan for SELinux (some distros): fixing credentials can be enough, but you may need to restore contexts if you do more than change password files.
• Be careful with chroot: it’s powerful and also very easy to do wrong in subtle ways.

If you’re feeling nervous (reasonable), create a snapshot of the OS disk first. Azure can do this quickly, and it saves you from the “oops, I changed the wrong partition” horror movie.

The Usual Rescue Path: Attach OS Disk to a Temporary VM

Azure doesn’t provide a single universal “reset root password” button for every Linux image the way some managed systems do. The reliable and widely applicable approach is:

1. Microsoft Azure International Account Identify the original VM’s OS disk.
2. Detach or reattach it in a recovery-friendly way (best: detach and attach to a temporary VM).
3. Boot the temporary recovery VM.
4. Mount the original OS disk filesystem.
5. Microsoft Azure International Account chroot into it.
6. Reset the root password (and optionally account lock state).
7. Exit, unmount, detach, and boot the original VM.

Yes, it’s a few steps. But it’s also predictable. And predictability is the secret sauce of sanity.

Prerequisites: What You Need Access To

To follow this guide, you should have:

• Azure portal or Azure CLI access.
• Permissions to manage VM disks (read/write).
• A subscription where you can create a temporary recovery VM (or use an existing one).
• Basic familiarity with SSH and Linux commands.

If you’re doing this in a production environment, double-check that your change window and approval process allow it. Password resets are changes, even when you’re just trying to undo your own forgetfulness.

Step 1: Stop the Original VM (Yes, Really)

Before messing with disk attachments, stop the original VM. You’ll usually want to use Azure’s “Stop” action, which preserves the disk.

Why stop?

• Microsoft Azure International Account If the VM is running, the OS disk may be actively used.
• Detaching an attached disk while the VM is running is a recipe for filesystem sadness.

In the Azure portal, locate the VM, click Stop. Wait for it to power off.

Step 2: Identify the OS Disk and Its Device Name

Now we identify which disk holds your Linux system.

Commonly, the OS disk is labeled as the “OS disk” in the VM settings. In many cases, it’s not called something obvious like “/dev/sda,” because cloud naming loves bureaucracy. The actual Linux device name depends on how the recovery VM presents the attached disk.

Still, in Azure you typically do:

• Open the original VM.
• Go to Disks.
• Find the disk marked as OS.

You may see properties like the managed disk name and size. Note the disk identifier. Also note whether you have separate data disks—because those matter if you’re mounting the wrong thing.

Step 3: Create a Temporary Recovery VM

You need a place to boot Linux while the original OS disk is attached. The recovery VM can be small. The goal is just to mount the disk and run commands.

Choose any Linux distribution you’re comfortable with. Ubuntu is often a safe bet because it’s familiar and has common tools. For example, create a VM with:

• Enough CPU and RAM to run basic commands (even a small VM is fine).
• At least one network interface so you can SSH in.
• Storage: typically standard managed disks are fine.

Microsoft Azure International Account Make sure you can SSH into the recovery VM. If you can’t SSH, you’ll be performing your rescue from inside a cage. Let’s avoid that.

Step 4: Attach the Original OS Disk to the Recovery VM

This is the core maneuver. In Azure, you attach the managed OS disk as an additional data disk to the recovery VM.

In practice, you:

1. Go to the recovery VM.
2. Microsoft Azure International Account Open Disks.
3. Add data disk.
4. Select the disk resource corresponding to the original VM’s OS disk.

Be careful: you are attaching the original OS disk to the recovery VM, not creating a copy. That disk will now appear as a new block device on the recovery VM.

Also be mindful of whether Azure requires a specific attachment type. Most managed disks attach cleanly as data disks, but the exact UI labeling can vary.

Step 5: Boot the Recovery VM and Locate the Attached Disk

Once the recovery VM is running and the disk is attached, SSH into it.

Then identify the disk and partitions. Common commands:

lsblk
sudo fdisk -l

You’re looking for a device with partitions. You might see something like:

• /dev/sdc (disk)
• /dev/sdc1 (EFI partition, sometimes)
• /dev/sdc2 (root filesystem)

However, device letters can vary. Linux loves randomness. The important thing is to find the partition that contains your root filesystem—usually the one that has /etc, /bin, /usr, etc.

One quick way to check:

sudo ls /mnt/somewhere

But we need to mount first. Before mounting, confirm partition layouts. You can also use:

sudo blkid

Look for the partition with a filesystem type like ext4 (common for the root partition) and mount it accordingly.

Step 6: Mount the Original OS Filesystem

Create mount points and mount the root partition. For example:

sudo mkdir -p /mnt/original
sudo mount /dev/sdc2 /mnt/original

If your VM uses a separate EFI partition, you might also mount it, but for resetting passwords you often only need the root filesystem. Still, if you plan to do anything fancy, mounting EFI can help. At minimum, mount the partition where /etc lives.

Sanity check:

ls /mnt/original/etc
ls /mnt/original/bin

If you see the expected directories, you found the right filesystem. If you get errors like “No such file or directory,” you mounted the wrong partition. Don’t guess aggressively. Verify calmly.

Step 7: chroot Into the Original Filesystem

Now we “enter” the original OS filesystem so commands like passwd operate on it rather than on the recovery VM.

Typical method:

sudo mount --bind /dev /mnt/original/dev
sudo mount --bind /proc /mnt/original/proc
sudo mount --bind /sys /mnt/original/sys

sudo chroot /mnt/original /bin/bash

After entering chroot, your prompt should reflect the original environment. You can verify by checking:

cat /etc/os-release

Now you’re operating inside the original VM’s filesystem from the recovery VM’s perspective.

Step 8: Reset the Root Password

Once inside chroot, reset the root password. Use passwd for the root account:

passwd root

It will prompt for the new password. Choose something strong enough to survive your future forgetfulness.

If you also suspect the root account may be locked (common on some hardened images), you can check:

sudo passwd -S root

And if it’s locked, unlock it. Depending on the distro, unlocking might be done by:

usermod -U root

or editing account settings. On most systems, passwd root will update the hash and often unlocks or makes it usable, but not always. If the login still fails after resetting, account lock is a prime suspect.

Bonus: If Root Isn’t the Actual Login Account

Sometimes “root password” isn’t used for SSH login. Modern cloud images often use a non-root admin user with sudo privileges. If you need to restore access to the admin account, reset that user’s password instead.

You can list users or check SSH configuration. Typical files:

• /etc/passwd (lists users)
• /etc/ssh/sshd_config (may restrict login)
• /etc/sudoers and /etc/sudoers.d (sudo rules)

For example, if your admin user is azureuser, do:

passwd azureuser

Then, if needed, ensure the user has sudo privileges. But many images already grant them.

Step 9: Handle Any Authentication Quirks

Resetting a password should normally fix password-based authentication. But let’s talk about the gremlins you might encounter:

Password Authentication Might Be Disabled

SSH can be configured to allow only key-based authentication. In that case, setting root’s password won’t help for SSH login. Instead, you need to restore SSH key auth or enable password auth (which is usually not recommended unless you have a secure reason).

Check:

grep -i -E 'passwordauthentication|pubkeyauthentication' /etc/ssh/sshd_config
sshd -T | grep -i passwordauthentication

If PasswordAuthentication is set to no, you won’t be able to log in with passwords via SSH even if the password is correct.

However, many Azure images allow key auth by default, and your “root password reset” might still be relevant for console login or specific configurations.

SELinux (Fedora/RHEL-based distros)

If SELinux is enforcing, password changes typically still work. But if you end up modifying more system files than needed, you can trigger context issues. Since we’re only changing password hashes using passwd, SELinux usually doesn’t get dramatic.

Initramfs or Boot Issues

We’re not changing boot configuration, so this guide typically won’t break the boot process. But if the original VM already had kernel or disk issues, the recovery mount won’t fix those. You’ll just regain credentials on a system that might still be unhappy.

Step 10: Exit chroot and Clean Up Mounts

Exit chroot:

exit

Now unmount the bound mounts and the original filesystem. In many cases, reverse the bind mounts first:

sudo umount /mnt/original/sys
sudo umount /mnt/original/proc
sudo umount /mnt/original/dev
sudo umount /mnt/original

If unmount fails, check if you have a shell still referencing those directories. Linux is stubborn and doesn’t want to unmount busy filesystems.

Step 11: Detach the Disk from the Recovery VM

Now detach the original OS disk from the recovery VM in Azure.

This restores the disk to a state where you can attach it back to the original VM (or reboot the original VM with it). Azure’s exact flow varies, but conceptually:

• Detach disk from recovery VM.
• Ensure original VM is stopped (usually).
• Microsoft Azure International Account Attach disk back to original VM if needed.

Sometimes, if you truly detached it from the original VM and then attached it to the recovery VM, you’ll need to reattach it to the original VM as its OS disk. If you instead created a different approach using snapshots, the workflow differs. The “attach same disk” flow is the common one.

Step 12: Start the Original VM and Test Login

Start the original VM from Azure. Then attempt to log in using the credentials you reset.

Test smartly:

• Try SSH if SSH is configured.
• If SSH fails due to key-only config, your password reset might still be correct but irrelevant to SSH authentication.
• If you can access a console, try console login.

If login fails, don’t panic. Usually it’s one of:

• Password wasn’t reset on the correct account.
• Account is locked or expired.
• SSH doesn’t allow password auth.
• You mounted the wrong partition and changed the wrong system.

Go back to the verification checks rather than blaming the universe.

Alternative Methods You Might Encounter

Depending on your Azure setup, other access mechanisms may exist. Some options are simpler than the disk rescue method, if your VM is configured to support them.

Azure Serial Console / VM Console Access

If your VM has serial console enabled and boot diagnostics available, you might be able to access a console and log in or reset passwords more directly.

This is configuration-dependent and not guaranteed. If you have it, it can be a lifesaver. If you don’t, the disk rescue method above remains the reliable “works even when consoles are asleep” approach.

Using Azure Recovery / Emergency Access Tools

Some environments use specialized tooling or scripts that can reconfigure access. Azure has features that help with debugging boot or collecting logs, but credential resets are still often handled by mounting disks in a controlled way.

So if you see a “password reset” feature in documentation for one region or image, don’t assume it exists for your case. The disk rescue method is the universal fallback.

Microsoft Azure International Account Common Pitfalls (Where People Accidentally Summon Chaos)

Here are the mistakes that show up again and again, because humans are creatures of habit and curiosity.

Pitfall 1: Mounting the Wrong Partition

This is the #1 “I reset root but nothing changed” problem. If you mounted the wrong partition, passwd changes the password in a filesystem that isn’t the running OS, or it fails entirely.

Fix: verify by checking /etc/os-release inside chroot, and confirm expected directories exist.

Pitfall 2: Forgetting to Bind Mount /dev, /proc, /sys

Many chroot workflows still work without these, but it can break commands that expect system interfaces. Binding them makes the chroot environment more like the real thing.

Fix: bind mount before chroot, and unmount afterward.

Microsoft Azure International Account Pitfall 3: Resetting Root But Logging In as Another User

After you reset root, you might still be logging in as azureuser (or some other account). If you didn’t reset that account, login will still fail.

Fix: confirm which username your SSH client or Azure portal expects.

Pitfall 4: SSH Is Key-Only

If password authentication is disabled, resetting root password won’t help. You might need to restore SSH keys or enable password authentication (carefully).

Fix: check /etc/ssh/sshd_config inside chroot and confirm PasswordAuthentication.

Pitfall 5: Not Creating a Snapshot When You’re Unsure

If you’re not confident about partition selection, snapshotting the disk is cheap insurance. Without it, you might end up repeating the entire process while also questioning your life choices.

Fix: snapshot first when unsure.

Verification: How to Confirm the Password Actually Changed

After resetting, you can verify in chroot by checking password hash-related files. On many distros, the password hash is stored in:

• /etc/shadow

You can inspect the entry for root:

grep '^root:' /etc/shadow

If the password hash field is updated and not locked (e.g., not starting with ! or * depending on distro), then the reset likely succeeded.

Note: hashes will look like random characters. That’s normal. The important part is that it changed from locked/empty/unset to a real hash and isn’t marked as disabled.

Hardening Tips After You Regain Access

Now that you’re back in, please don’t immediately repeat the cycle. Here are a few pragmatic ways to avoid the next “where is the password” emergency:

• Use SSH keys instead of passwords where possible.
• Store credentials in a password manager (yes, you know you should).
• Enable an admin user workflow with sudo so you don’t depend on root login.
• Set up alerts or documentation for VM access parameters (who owns it, which user, which auth method).

Also, consider that resetting root password is sometimes a sign your operational process needs a small tune-up. Your future self will thank you, even if your current self groans.

A Concrete Walkthrough Example (A Reasonable Default)

Let’s put the steps into a narrative example. Imagine you have an Azure Linux VM called prod-web-01. You lost the root password and cannot SSH.

You do the following:

1. Stop prod-web-01 in Azure.
2. In the VM’s Disks tab, identify the OS disk (managed disk).
3. Create a small temporary VM called rescue-vm-01.
4. Attach the original OS managed disk to rescue-vm-01 as a data disk.
5. SSH into rescue-vm-01 and run lsblk to find the attached disk partition that contains /etc.
6. Mount it at /mnt/original.
7. Bind mount /dev, /proc, /sys, then chroot into /mnt/original.
8. Run passwd root to set a new root password.
9. Exit chroot, unmount, detach the disk from rescue-vm-01.
10. Reattach/start the original VM and test SSH login.

That’s it. The key is accuracy: mount the right partition, chroot properly, reset the right account, and keep Azure disk attachment consistent.

Frequently Asked Questions

Will this work for any Azure Linux VM?

It’s broadly compatible for most Linux distributions because it modifies the filesystem directly. The main exceptions are cases where the disk layout is unusual, encrypted (LUKS), or the OS uses access methods that don’t rely on traditional password authentication.

If your disk is encrypted, you’ll need the encryption keys or a different recovery workflow.

What if the disk is encrypted?

If the OS disk uses full-disk encryption (such as LUKS or BitLocker-equivalent approaches for Linux), you can’t easily access /etc/shadow without unlocking the encryption. The recovery process will require the correct keys or Azure encryption integration features.

If you suspect encryption, check the VM’s encryption settings in Azure and your disk encryption approach before attempting mounts.

Do I need to reset the root password or the sudo user password?

That depends on what your login method uses. Many images prefer non-root admin users. If SSH is configured for a specific user, reset that user’s password. Resetting root is still valid if root login is allowed or if you plan to switch users after logging in.

Can I avoid creating a recovery VM?

You can sometimes use an existing temporary VM as a recovery host. The workflow is the same: attach the disk, mount partitions, chroot, reset. Creating a new one is just the simplest “clean slate” option.

How long does it take?

Typically, 20 to 60 minutes depending on Azure operations, VM provisioning speed, and how complicated the partition layout is. The waiting part is usually the longest part. Linux commands themselves are fast.

Final Thoughts: You’re Not Locked Out Forever

Forgetting a root password feels like you’ve been permanently evicted from your own server. But with Azure VMs, you generally have the advantage of managed disks. Managed disks can be attached, mounted, and repaired—like digital Lego blocks that you can still put back together even after someone stepped on them.

If you follow the disk rescue approach carefully—stop the VM, identify the OS disk, mount the correct partition, chroot correctly, run passwd, and then reboot—you’ll regain access. And then you can do the responsible thing: document the credentials, switch to SSH keys, and add a little operational “future-proofing” so you don’t have to write the same story again next month.

Good luck, and may your mounts be correct on the first try.