Forgotten and expired root password on AWS

So we have scaled back some of our servers as a project left active development, maintaining only production machines to keep the product running. This meant that the staging servers had been in a stopped state, and unused for many months. Today harkened the day where I needed to turn one back on and get it ready to be used again, so no problems right? I logged into the AWS console and started it up, logged into the jump box and

[kevin@jump]  [~] $ ssh staging
Your account has expired; please contact your system administrator
Connection closed by XX.XX.XX.XX
-----------------------------

No problems I have the root key kicking around here, I'll just use that

[kevin@jump]  [~] $ ssh -i stagingroot.key root@staging
Enter passphrase for key 'stagingroot.key':
You are required to change your password immediately (root enforced)
Changing password for root.
(current) UNIX password: 
Connection to staging closed.

Yikes, it turns out in my usually wonderful documentation there was a typo, or a failure to update in the last system-wide password update. This isn't good! Thankfully it's fairly easy to fix.

1. Stop the instance in question
2. Remove the root EBS Volume attached to that instance
3. Attach the EBS Volume to an existing, or new instance that you retain access for
4. Mount the EBS Volume in the new instance (I used /mnt/fix for this

5. sudo vi /mnt/fix/etc/shadow

   
   Here we want to look for your user account (or the root user account line), these lines are stored as follows separated by a :
   • Username, up to 8 characters. Case-sensitive, usually all lowercase. A direct match to the username in the /etc/passwd file.
   • Password, 13 character encrypted. A blank entry (eg. ::) indicates a password is not required to log in (usually a bad idea), and a ``*'' entry (eg. :*:) indicates the account has been disabled.
   • The number of days (since January 1, 1970) since the password was last changed.
   • The number of days before password may be changed (0 indicates it may be changed at any time)
   • The number of days after which password must be changed (99999 indicates user can keep his or her password unchanged for many, many years)
   • The number of days to warn user of an expiring password (7 for a full week)
   • The number of days after password expires that account is disabled
   • The number of days since January 1, 1970 that an account has been disabled
   • A reserved field for possible future use

We want to edit the third field for our user in question. To get the unix time we need to run the command

echo `date -d '2013-07-29' +%s` / 86400|bc

and put that number in the field.

save the file

umount the EBS volume

detach the EBS volume from the server you were repairing it on

reattach the EBS volume to /dev/sda1 of the instance we were repairing

start the instance

login and profit

After a short panic attack, this should get you back up and running. However the moral of this story, is make sure when you're doing your 3 month password maintenance, you start instances/servers that are sitting idle, and when you change the passwords make sure (double and triple check) you record them properly in your documentation, or wherever you're keeping track of these things.

• Tweet
• Share
• Share
• Share
• Share

Sign up here with your email