Reset admin password on JunOS SPACE VM

Picture this: Bob, your JunOS SPACE administrator, left the company. IT diligently wiped his laptop. Bob was the only one who had the admin password (for ssh / CLI access) to your JunOS SPACE installation.

After vowing to do better in future and storing all infrastructure passwords in some form of centralized, encrypted, backed-up password safe, you are left with the task of restoring access.

If you are running your JunOS SPACE instance on an appliance, all you need is a USB stick and Juniper’s instructions. (Note: That may not be entirely true – see discussion of how /etc/shadow behaves in 14.1R2 of SPACE, below)

If you are running your JunOS SPACE instance in a VM, read on.

You’ll need vSphere-level access to the VMWare host JunOS SPACE runs on. Make friends with the VMWare admin.

You’ll need an ISO of a Linux rescue disk.

Power down the SPACE VM and change its boot properties to force boot into BIOS, and delay by 10,000ms for good measure, like so:

Screenshot 2015-07-16 10.44.33

Power on the SPACE VM, and open a Console. You’ll find yourself in the BIOS shortly. Connect the virtual CD drive to the ISO you downloaded (that’s the CD-with-wrench icon in the Console) and change the BIOS to boot from CD first, like so:

Screenshot 2015-07-16 10.54.02

Alternatively, you could have left the BIOS alone and hit ESC to get the boot menu during the 10 second boot delay.

Whichever option you choose, make sure the CD has finished connecting (loading the ISO) before you hit F10/Enter. If you are remote to your VMWare host, it may make sense to upload the ISO to the datastore first, and connect the virtual CD to that copy.

Once the VM has booted from the rescue ISO, I chose the “standard with US keymap” boot option for the rescue disk.

Use lvscan to see the device names of the SPACE disks:

 ACTIVE '/dev/jmpvgnocf/lvroot' [25.41 GB] inherit
 ACTIVE '/dev/jmpvgnocf/lvtmp' [17.91 GB] inherit
 ACTIVE '/dev/jmpvgnocf/lvvar' [207.78 GB] inherit
 ACTIVE '/dev/jmpvgnocf/lvlog' [4.88 GB] inherit

Mount the root partition:

mount /dev/jmpvgnocf/lvroot /mnt/custom

Move the shadow- backup file (don’t delete it):

mv /mnt/custom/etc/shadow- /mnt/custom/root

I tried this without moving shadow- and it would revert to the previous admin password after editing shadow.

Juniper’s original instructions for the appliance, based on the now-ancient SPACE 1.2, want you to save an empty password (::) for admin in shadow. When I tried that, I could no longer log in.

Instead, I used passwd on the rescue CD to get the crypt string for the password “abc123”. It is:


With this in hand, I could “vi /mnt/custom/etc/shadow” and insert the string for the new password, which looks like this:

Screenshot 2015-07-16 12.55.28

Save that file using “:x!” in vi and you are ready to “reboot”

Note: Typing that string in the VMWare Console is going to be extremely error-prone. It makes sense to ssh to the rescue Linux instead, so you can copy/paste. Use “ifconfig” to see whether you received a DHCP address. If not, you’ll need to follow the instructions for the rescue image to enable networking – or manually type the password string.

If you changed the BIOS to boot from CDROM first, undo that change when the boot screen comes up.

After reboot, you should be able to log in as admin with the default password and use the option “1” to change the password:

Screenshot 2015-07-16 12.54.59

Now that you’re back in the CLI, you can follow Juniper’s instructions for resetting the password for the ‘super’ user which is used for GUI access and the ‘maintenance’ user which is used for software updates.

With those three accounts restored, you have the access needed to administrate JunOS SPACE again – and set up further GUI authentication for users as desired.

Resolving JunOS Pulse install issue on Windows

On my own Windows 7 machine, I had an odd error when attempting to install JunOS Pulse 5. The installer would start with “copying new files”, then “rolling back action” and would finally tell me that “the wizard was interrupted before JunOS Pulse could be completely installed.”

Usually, when something odd like this happens, the remedy is to uninstall everything Juniper. Which I did. Network Connect, Host Checker, Setup Client, Installer Service, Pulse Collaboration, I got rid of them all. Which didn’t resolve my issue.

Now, this machine has had various versions of Juniper-something installed on it over the years. Even the OAC client at one point. So it was likely that something was lingering that was causing this issue.

I had seen something similar at a customer of mine. They resolved it by re-imagining the machine. I didn’t want to be quite so thorough.

The solution turned out to be to open a command line “as Administrator”, run “pnputil -e > pnplist.txt”, find everything in there that has the name “Juniper” in it, then run “pnputil -d oemXX.inf” for each entry, where “XX” is the actual number of the entry.

This got rid of a lingering driver in the Windows driver store, which was keeping the Pulse driver from being installed. After this little bit of surgery, Pulse installed without complications.

Before reaching for pnputil, be sure that the previous step, uninstalling everything that has to do with Juniper MAG/SA client software, has already been taken. These drivers are components of the client software. Pulling them out from under that client software is not desirable.

I’ve found a forum mention that pnputil helped with a Network Connect install issue where a Juniper driver had gotten orphaned. This remedy is not specific to Pulse alone.


Recover Juniper SRX from failed boot

I have a Juniper SRX240H in the lab. I decided to load a beta version of JunOS, which brought the unit into a state where it did not successfully boot, and where I could not use the loader> prompt to recover from TFTP.

The symptoms were:

  • During boot, the SRX would experience a fault and enter the db> prompt. I believe this to be a debugger, possible gdb. “c” will cause it to reboot again
  • If I enter the loader> , I cannot execute setenv – I get a “stack underflow” error. This means I cannot install JunOS from TFTP

I may have been able to recover this system using a USB key, but I am remote to my lab: All I have is serial console.

I resolved the issue by entering u-boot instead of the loader. u-boot prompts right after boot, and the loader prompt is shown shortly thereafter. The u-boot prompt is “Press SPACE to abort autoboot in 1 seconds”, and the loader prompt is “Hit [Enter] to boot immediately, or space bar for command prompt.”

In u-boot, I issued this command:

=> getenv

This showed me that boot.current=primary

I changed this to the alternate slice, which still held a working copy of JunOS:

=> setenv boot.current alternate
=> boot

The system came up successfully and warned me that I had booted from the alternate slice, and it rebuilt the primary slice:

**                                                                   **
**                                                                   **
**  It is possible that the primary copy of JUNOS failed to boot up  **
**  properly, and so this device has booted from the backup copy.    **
**                                                                   **
**  The primary copy will be recovered by auto-snapshot feature now. **
**                                                                   **

The auto-snapshot feature that was used here needs to be configured (set system auto-snapshot) and supported by the version of JunOS you’re running.

Lastly, I confirmed that the snapshot had been repaired, then rebooted:

root@SRX-Lab-2> show system snapshot media internal
Information for snapshot on       internal (/dev/da0s1a) (primary)
Creation date: Nov 13 12:53:04 2013
JUNOS version on snapshot:
  junos  : 12.1X44-D20.3-domestic
Information for snapshot on       internal (/dev/da0s2a) (backup)
Creation date: Oct 4 17:13:17 2013
JUNOS version on snapshot:
  junos  : 12.1X44-D20.3-domestic
root@SRX-Lab-2> request system reboot