Changing lots of passwords at once

Here’s the scenario. A group of related servers is managed by a group of system administrators that all have root access. If a system administrator leaves the company (for any reason), they are required to change the root password. The new password needs to be the same on each host, with the same hash string in order for it to pass security auditing. Logging into each server to manually change the password is not an option, and even if it was, it certainly isn’t efficient. (I know kerberos is also an answer, but not for this customer.)

Because all of the servers involved are all subscribed, with provisioning, to the customer’s Red Hat� Network� Satellite server, we can take full advantage of the “Run Remote Command” function. Not only is this a convenient way to schedule the change, but all of the traffic is encrypted. And don’t worry–you should be able to adapt this to any reliable scheduler, not just Satellite.

So what is this supposedly over-looked tool? Actually, it’s part of a toolkit, specifically the “openssl” toolkit. We can use this toolkit to create MD5 hashes, and then use the “chpasswd” command to insert the new hash into /etc/shadow. So now the password is encrypted along with the traffic that carries it. Let’s get to it.

Creating the new password hash

1. First, use the “openssl” command along with the options that allow for MD5-style passwords to create the password hash. You’ll need to have a good password to start.

Note:

For strong passwords that are still easily remembered, I like to start with a movie quote. I take the first letter of each word, plus the punctuation, and transpose some of them to special characters or numbers. For instance, “Aren’t you a little short to be a stormtrooper?” becomes

Ayalstbas?

, then

Ayalstb45?

. You can still remember the quote, but this one will have to be brute forced in order to crack it.

2. Lets use our new password with “openssl” and get our hash string.

[root@server ~]# openssl passwd -1
Password:
Verifying - Password:
$IY0mNugK$k.KaFgFxELiGJUa44QgnX/
[root@server ~]#

As you can see, the password is entered in twice, and the hash is created. And the switch is a “dash one”, not a “dash L”.

Inserting the new hash string

Next, we’ll schedule the password change in Satellite, and run the command.

1. From the Satellite, select the servers that need to be affected from the “Systems” tab, the click on the “Manage” button in the upper right hand corner.

2. From the “Provisioning” section, towards the bottom, select “Run remote commands.”

3. In the contents of the “Script” text block, enter the following:

#!/bin/sh

echo 'root:$IY0mNugK$k.KaFgFxELiGJUa44QgnX/' | chpasswd -e 
&& logger “Successfully changed password from Satellite”

Note:

Be sure to use the single quote, or the shell will attempt to interpret any special characters in the hash. The “-e” switch tells

chpasswd

to expect the password in encrypted form, and then we log the change in /var/log/messages.

4. Make sure the time schedule is acceptable, then click “Schedule Remote Commands”, then “Schedule Commands” to confirm.

Using RPM to redistribute the new password

It is also possible to put this together in an RPM as well. Although, there isn’t space to go over building RPM packages in this article, I have included the important bits.

1. Place the “:” pair in a file as your “source” file. Below, this is referenced as “hash_file”.

2. Have the RPM install the source file in /root, or somewhere safe.

3. Place the “chpasswd” command in the %post section of the spec file.

4. Have the installed source file removed after changing the password, so that the hash is hanging around unnecessarily outside of /etc/shadow.

5. Be sure to sign the package with your GPG signature.

I’ve included snippets from a sample SPEC file below:

[snip]

%install
mkdir -p %{buildroot}/root
install -m 700 %{SOURCE0} %{buildroot}/root/hash_file

[ snip ]

%post
/usr/sbin/chpasswd -e < /root/hash_file && 
logger "Successful Password Change with Version %{version}"
# Remove the file containing the hash string
/bin/rm -f /root/hash_file

[snip]

Note:

Although the customer originally wanted to just have the hash in the RPM spec file, that’s not good either. This would mean that the hash file is still on the system outside of /etc/shadow, and RPM would need to be removed as soon as it was installed. This way, the hash file can be removed, and the entry in the RPM database can serve as an additional record.

The customer just needed a painless method of getting to rescue mode that fit the confines of their environment. I’m sure if we spent enough time and money we could have come up with something big and expensive, but many times its just better to keep it simple. Hopefully this is worthy of your “bag of tricks”.