Lost your Ubuntu password? Three recovery paths: GRUB recovery mode (local machines, hold Shift at boot), cloud serial console (AWS/GCP/Azure), or detach the disk and chroot on another instance. Each takes 2-5 minutes. The team that has any one of these paths has the recovery; the team that has encrypted the disk AND lost the LUKS passphrase has unrecoverable data.
Table of contents
- Path 1: GRUB recovery mode (local machines)
- Path 2: Cloud serial console
- Path 3: Detach disk and chroot
- When the recovery is impossible
- Prevention: set up sudo for passwordless recovery
- FAQ
Path 1: GRUB recovery mode (local machines)
- Reboot and hold Shift to enter GRUB.
- Select ‘Advanced options for Ubuntu’.
- Select ‘(recovery mode)’.
- Pick ‘root’ from recovery menu.
mount -o remount,rw /passwd <username>reboot
The team that has physical access uses this path. The team that needs remote access uses cloud serial console or chroot.
Path 2: Cloud serial console
Most cloud providers offer serial console access that works without SSH:
- AWS EC2: Settings -> Instances -> Instance ID -> Actions -> Monitor and troubleshoot -> EC2 Serial Console -> Connect.
- GCP: Compute Engine -> VM instance -> Edit -> Enable serial port. Connect via SSH to the serial port.
- Azure: Boot Diagnostics -> Serial Console.
- DigitalOcean: Droplet -> Access -> Launch Recovery Console.
The serial console gives a terminal into the instance as if you had physical access. GRUB menu and recovery mode work the same way.
The team that uses cloud serial console avoids needing SSH access for password recovery. The team that hasn’t enabled serial port access on GCP needs to enable it first (default off).
Path 3: Detach disk and chroot
If neither GRUB nor serial console works:
- Stop the instance.
- Detach the boot disk (EBS volume on AWS, persistent disk on GCP, managed disk on Azure).
- Attach the disk to another working instance.
- Mount the disk:
sudo mount /dev/sdb2 /mnt(or wherever it appears). - Chroot into it:
sudo chroot /mnt. passwd <username>.- Exit chroot, unmount, detach, reattach to original instance.
- Start original instance.
The team that has another Linux instance in the same region/AZ uses this path. The team that doesn’t can spin up a small instance just for the recovery.
When the recovery is impossible
The team that has:
- LUKS full-disk encryption AND lost the LUKS passphrase
- Or no console access AND no second instance AND no LUKS key backup
…has unrecoverable data. The data on the disk is encrypted with a key derived from the passphrase - without the passphrase, the data is inaccessible.
Prevention: store the LUKS passphrase in a password manager. The team that uses LUKS without backing up the passphrase has a single point of failure.
Prevention: set up sudo for passwordless recovery
After recovery, the team that wants to avoid this scenario in the future can:
- Enable cloud serial console in the cloud provider’s settings.
- Create a ‘break glass’ user with a known password stored in a password manager.
- Keep a recovery image/AMI that has known credentials.
- Use SSH keys (not passwords) for remote access, which avoids this entire class of problem.
The team that uses SSH keys exclusively (the modern default) doesn’t have password recovery scenarios - they have SSH key recovery scenarios, which are different.
FAQ
Can I reset Ubuntu password without rebooting?
Not really - you need root shell access to run passwd, and if you’re locked out, you need recovery mode or another path. The team that has sudo access to another user can sudo passwd <username> without rebooting.
What about the root password?
Same path - recovery mode, drop to root shell, passwd root. Most Ubuntu installs have root account locked by default; the recovery shell runs as root regardless.
Is GRUB password protection a thing?
Yes - set GRUB password in /etc/grub.d/40_custom then update-grub. The team that has GRUB password set needs to know it to get into recovery mode (defeating the purpose of recovery if lost).
Will resetting the password delete my files?
No - passwd only changes the password hash, not user data. The team that has the user account on disk has all their files intact after password reset.
Can I unlock the account instead of resetting password?
Yes - passwd -u <username> unlocks a locked account. The team that has account lockout from failed logins uses this. But if you don’t know the password, unlock doesn’t help - you need to set a new one.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: