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:
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:
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:
$6$MsjX3IGJ$KVp.m.rQDK5PG1ELcjNajJUbBttXZZzXY/mtQhmNG4PmqSyuVYXgcOjuwjksXkz1rf5DM.laraWKpNf9.T/mp0
With this in hand, I could “vi /mnt/custom/etc/shadow” and insert the string for the new password, which looks like this:
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:
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.
Thorsten on (mostly) Tech 