It happens to every team eventually: a lab EX switch, a decommissioning SRX, or a branch MX whose root password existed only in the head of an engineer who left. The forum threads ("Resetting Juniper SRX with a password-protected config", "Password recovery SRX100") all converge on the same official procedure. It requires physical console access — which is exactly why it is safe to publish.
What You Need
- Physical access to the device and a console cable (RJ-45-to-DB9 or mini-USB on many models).
- A terminal emulator at 9600 baud, 8 data bits, no parity, 1 stop bit.
- About five minutes of reboot time. The running configuration is preserved — you only reset the root password.
The Procedure
Step 1: Interrupt the Boot
Reboot the device (power cycle, or request system reboot if you still have non-root access). Watch the console. At the message:
Hit [Enter] to boot immediately, or space bar for command prompt
press the space bar. You land at the loader prompt. If you miss it, let it boot and try again — timing is the only skill required.
Step 2: Boot Single-User
boot -s
The system boots into single-user mode and asks for the shell:
Enter full pathname of shell or 'recovery' for root password recovery, or RETURN for /bin/sh:
Type recovery and press Enter. This is the official answer — it mounts the filesystem read/write and drops you into the CLI as root with a recovery banner.
Step 3: Set the New Password and Commit
After the system messages, you get a standard CLI prompt. Enter configuration mode and set a new root password:
configure
set system root-authentication plain-text-password
New password: ********
retype password: ********
commit
request system reboot
The reboot reloads normally, and your new password works for both console and SSH root login (if set system services ssh root-login allow is configured).
When the Loader Prompt Never Appears
On some platforms and with some boot orders, the space-bar window is short or the device boots straight through. The fallback is USB media installation: write a Junos install media image to a USB stick, boot from it, and install Junos to the internal disk. Note this wipes the filesystem on some platforms — a genuine last resort. On dual-RE systems (MX with two Routing Engines), repeat the recovery on both REs or they will hold different root passwords after failover.
Chassis Cluster Note
On an SRX chassis cluster, recover both nodes — the secondary node keeps its old password otherwise, and a failover will lock you out again exactly when you least need it.
Security Implications
This procedure is why physical access to network gear must be controlled: console servers should require authentication, racks need locks, and decommissioned gear must be sanitized. There is no Junos setting that disables recovery — by design, because the alternative is bricked hardware.
After Recovery
Log in, change any other credentials that may have been forgotten along the way, and review show log messages for the timeline. If your problem was administrative rather than forgotten — someone else holds the configuration — the configuration database lock guide is the fix you need. To re-learn the commit model you just exercised, see the Junos CLI crash course, and if you are recovering a lab device to study, our JNCIA study plan gives the recovered box a purpose.
Related Reading
- BGP session flap field method
- complete OSPF on MX working example
- SRX zone-based firewall, policies, screens and NAT explained
- EVPN-VXLAN multi-vendor interop guide
Discussion (0)