Junos Password Recovery: Root Password Reset Guide

Losing the root password on a Juniper device (EX, QFX, MX, SRX) does not mean a factory reset - Junos ships with a password recovery path designed for exactly this situation. There are two practical methods: booting into single-user mode to edit the password database directly, and the newer amnesiac boot option that resets the configuration but preserves the system. This guide covers both, with exact boot-menu interactions and the commands to set a new root password.

What You Need Before You Start

Password recovery is a boot-time, out-of-band procedure. Assemble these before you power-cycle anything:

• Physical or virtual console access. A rollover cable (RJ-45 to DB-9, or a USB serial adapter) into the console port, or a hypervisor console session for a vMX / vSRX / vQFX instance.
• Terminal settings of 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control. Most "the boot menu never appeared" reports are actually wrong serial settings.
• Power access. In the worst case you have no login at all and must press the power button or pull the feed.
• A configuration backup. Not strictly required for method 1, absolutely required if you end up in amnesiac mode.
• Patience at the loader prompt. The window to interrupt autoboot is a few seconds wide.

On a chassis with dual Routing Engines, perform the procedure on the master Routing Engine. The two REs have separate filesystems, and resetting the password on the backup RE does nothing for the login you cannot complete on the master. On a Virtual Chassis or a multi-member stack, run the procedure against the master and remember that each member has its own configuration.

Why Console Access Is Mandatory

Junos gives an administrator with console access the ability to bypass authentication, which is a deliberate design decision: physical possession of the device is treated as sufficient authority. As a direct consequence, there is no SSH or Telnet equivalent. Every route into recovery starts with interrupting the boot process, and the boot process only talks to the console.

That design has one important switch of its own. If the console port has been configured as insecure, root password recovery is not possible at all:

[edit]
user@host# set system ports console insecure

With that statement in place, an attempt to recover by booting into single-user mode prompts for the existing root password, and a boot into CLI recovery mode is simply not allowed. Only somebody who already knows the root password can get in. That is a strong hardening control for a device in a physically accessible location, and a genuine trap for anyone who enables it in a remote site and then forgets the password - decide deliberately which side of that trade-off you want, and write the decision down.

Method 1: Single-User Mode Recovery (Classic)

1. Connect via console and reboot the device: request system reboot
2. At the boot menu, interrupt the autoboot by pressing a key (usually space or any key within 10 seconds).
3. At the loader prompt, boot into single-user mode:
   loader> boot -s
4. The system boots to a single-user shell. Enter full path to shell: /bin/sh
5. Remount the root filesystem read-write:
   mount -u /
6. Edit the password file to remove the root password hash:
   vi /etc/master.passwd
   Delete the hash from the root entry (between the colons).
7. Rebuild the password database:
   pwd_mkdb /etc/master.passwd
8. Reboot: reboot
9. Log in as root with no password and set a new one:
   root@% cli
root@# set system root-authentication plain-text-password

Two notes that matter in practice. First, on modern Junos the single-user prompt is not a plain shell prompt - it reads:

Enter full pathname of shell or 'recovery' for root password recovery or RETURN for /bin/sh:

Typing recovery here is the supported path on current releases and takes you straight to the CLI recovery mode described below, which is cleaner than hand-editing /etc/master.passwd. Second, on devices running Junos OS with upgraded FreeBSD (FreeBSD 10 and later) the password no longer lives in /etc/master.passwd as the authoritative source; the configuration is the recovery surface, so prefer the recovery shell or CLI recovery mode on those platforms. Editing the password database directly remains a useful fallback on older releases and when a filesystem repair is needed anyway. If the filesystem is damaged, drop to /bin/sh and run fsck before you touch any file.

If the vi route is inconvenient, single-user mode also exposes the standard passwd utility - remount, then set the password directly and continue the boot:

$ mount -a
$ passwd root
$ exit

Method 2: Amnesiac Boot (Modern, Cleaner)

Newer Junos versions (12.1+ on most platforms) offer a recovery option from the boot menu:

1. Reboot and interrupt the boot at the loader prompt.
2. Select the kernel entry and append the amnesiac option, or choose the boot menu item "Recover root password" where available.
3. The device boots with an empty configuration (amnesiac) - no root password, no interfaces configured.
4. Set a new root password and rebuild the configuration from your backups.

Amnesiac wipes the active configuration - only use it when you have a config backup or can reconstruct the box.

The amnesiac state is easy to recognise: the login banner names it directly, as in FreeBSD/amd64 (Amnesiac) (ttyu0) login:. A device becomes amnesiac whenever it boots without a usable configuration - a failed boot-time commit, a corrupted configuration file, or a manual boot that bypassed the configuration. If your goal is only to reset the root password while keeping the configuration, this is the wrong tool; use single-user mode or CLI recovery mode instead.

Method 3: Menu-Driven CLI Recovery Mode

On devices running Junos OS with upgraded FreeBSD, the boot menu was replaced by a set of interactive menus that make password recovery a series of keypresses rather than a filesystem edit. Watch the console during boot and press Ctrl+C inside the three-second window to stop the automatic boot sequence and reach the Junos Main Menu:

Choice: Main Menu
  1. Boot [J]unos volume
  2. Boot Junos volume in [S]afe mode
  3. [R]eboot
  4. [B]oot menu
  5. [M]ore options

Press M or 5 to open the Options Menu:

Choice: Options Menu
  1. Recover [J]unos volume
  2. Recovery mode - [C]LI
  3. Check [F]ile system
  4. [B]oot prompt
  5. [M]ain menu

Choose C or 2 - Recovery mode - CLI. The device reboots into CLI recovery mode with no configuration loaded, dropping you at a root> prompt with instructions on screen. From there the procedure is the same as every other method:

root> configure
Entering configuration mode
[edit]
root# set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
root# commit
commit complete
[edit]
root# exit
Exiting configuration mode
root> exit
Reboot the system? [y/n] y

The same Options Menu also exposes a Check File system option, which is the fastest way to get a damaged /config or /var repaired before you attempt a password change. If you need to pick a different configuration file or a different installed Junos package entirely, the Boot Menu underneath it offers single user mode, the previous installed packages, a recovery snapshot, network boot, USB boot and an OAM shell - useful when the password problem is a symptom of a larger boot problem.

Recovering a Lost User Password (When Root Still Works)

Root password recovery is the heavy tool. If an ordinary login account has lost its password but you can still reach the device as root or as another super-user, no console trip is needed:

root@host# set system login user jsmith authentication plain-text-password
New password:
Retype new password:
root@host# commit

To avoid retyping a password on each device, copy the encrypted hash from a device that already has the correct credentials:

root@host> show configuration system login user jsmith | display set

Then paste the encrypted-password value into the target box. This is also the basis of a break-glass account you keep in a vault: a super-user account whose hash is identical across the fleet, used only when the primary authentication path is down. If you are standardising accounts and keys anyway, our guide to Junos user accounts, login classes and SSH keys covers the rest of the model.

Amnesiac, Recovery Mode and Factory Reset Compared

Keep those four distinct in your head: only the last one destroys data. Single-user and CLI recovery mode leave your configuration intact - the change you make is to the root password, and you must commit it for the change to persist.

Prevention: Auto-Recovery Configuration

set system auto-recovery
set system root-authentication encrypted-password "..."

set system auto-recovery makes the device auto-recover (reset root password to the configured value) after a recovery boot - useful for devices without console access in remote sites.

Availability of that statement varies by platform and Junos release, so confirm it is accepted on your hardware before building a remote-site procedure around it. The closely related, widely supported mechanism is the autorecovery state backup, which protects the rescue configuration, licensing and disk-partitioning information on dual-root-partitioned devices:

user@host> request system autorecovery state save

That command does not cover the root password, but it does protect the configuration you would need after an amnesiac boot, and it is worth running on every dual-root device. Pair it with a saved rescue configuration - see Junos rescue configuration: save and recover quickly - so that a device which fails its boot-time commit has something sane to fall back to.

Important Notes

• Both methods require console access - recovery cannot be done over SSH.
• Editing /etc/master.passwd on modern Junos also requires mount -u / and sometimes remounting /var and /config; use mount -a if unsure.
• On SRX with security policies blocking console traffic, disable the security policy or use the amnesiac method.
• After recovery, verify with show system users and re-check show configuration system.
• Recovery is blocked entirely if the console port has been configured as insecure, and it is blocked on any platform where the console cannot be reached - document your out-of-band path.
• Perform the procedure on the master Routing Engine on dual-RE chassis, and on the master member of a Virtual Chassis.
• Virtual machines (vMX, vSRX, vQFX) follow the same procedure through the hypervisor console; there is no physical cable involved but there is also no network shortcut.

After Recovery: Verifying and Hardening

Do not reboot straight into production and hope. A short verification sequence removes most of the ways this procedure can go wrong:

root> show system users
root> show configuration system root-authentication | display set
root> show system uptime

Then confirm that the configuration you expected is still there - show configuration | compare rollback 1 is a quick sanity check that you did not accidentally replace anything - and only then re-enable remote access and re-test SSH from a management host. If you changed the root password while other administrators had sessions open, tell them; a recovery that leaves half the team locked out is a second incident.

Harden the result: give root a strong password, create named super-user accounts instead of sharing root, install SSH keys (see Junos user account and SSH key configuration), keep the credentials in a vault, and store a configuration backup off the device. If you are still standing the unit up, start from Juniper EX initial setup commands; the procedure below mirrors the Cisco equivalent in Cisco IOS password recovery.

Common Problems and Their Causes

The boot menu never appears. Either the interrupt window was missed (power-cycle and watch the console, not the front panel LEDs) or the terminal is misconfigured - 9600 8N1 with no flow control is the only setting that works on the console port.

Single-user mode asks for the root password. The console port has been configured as insecure. There is no workaround from the CLI; recovery is disabled by design, and the only remaining lever is a working login or a factory reset.

You set a password and it reverted after reboot. The change was never committed. Single-user edits to the live password database, and CLI changes in recovery mode, both need an explicit commit before they survive a restart.

Nobody can log in as root any more. Almost always the encrypted-password statement was given a plain-text value, or was committed with empty quotation marks. That writes a hash the system can never match. Redo the recovery and use plain-text-password, letting Junos hash it for you.

The filesystem looks damaged. Use the menu's Check File system option, or boot single-user and run fsck before editing anything. A recovery attempt on a corrupt filesystem produces confusing failures that look like authentication problems.

原文链接：https://kb.juniper.net/InfoCenter/index?page=content&id=KB16451

Additional reference: Recover a Root Password (Junos OS)