I have an OpsWare task, that changes root passwords on a massive number of servers, by replacing the root's password hash in /etc/shadow file.

I need a script of some sort, which preferably runs using, again, OpsWare but I do not want to compare the hashes. I want it to run some sort of an su (or login) command and input the actual password string. The reason I want to do it this way is, in the past, I have had hashes created by someone else, which did not encrypt correctly and denied root login on a large number of servers.

I am looking for ideas that I can implement. expect comes to mind but since it is not a standard utility in our enterprise, it needs to be installed and removed right after testing, which is not a "fast" solution.

Idea suggestions are appreciated.

  • Try to login via ssh and use expect or use some ssh library or connect to your kvm servers/vms and try to login via the serial console (again via expect). – Ulrich Dangel Jul 22 '14 at 18:29
  • You do realise that if you want to do that, your check requires a clear text password. If that's the case you might as well avoid using the hashes in the first place and use the clear text password in your original script to set the root password. echo "my_new_insecure_password" | passwd --stdin root – HBruijn Jul 22 '14 at 18:30
  • In other words, test your OpsWare script on a test server, validate it works and then deploy onto other systems. A past mistake is not valid excuse to engineer an even worse solution. – HBruijn Jul 22 '14 at 18:32
  • @HBruijn: I am not planning to bury the clear text password into the script. It will be placed in a file for the duration of the script run, where and when it will be read from file and assigned to a variable, and be destroyed after test is complete and the temporary file will be removed manually. I know it is not bullet-proof but being in a quite bit fortified security environment, I think I can take that much of risk for a short period of testing time. – MelBurslan Jul 22 '14 at 18:37
  • 1
    @Mel_Burslan thats why you should install expect on one system and use that system to login into the servers either via ssh or serial console – Ulrich Dangel Jul 22 '14 at 18:53

There is a utility called sshpass which allows you to supply a password as an option on the command line. This tool can be scripted so that it runs on multiple hosts, even in parallel. Install sshpass on your jumpbox, then take something like this:

sshpass -p password ssh root@host 'hostname;date;id'

and embed it in a shell loop or other method (such as parallel ssh or clusterssh) that lets you run it on multiple hosts.

People might think this is insecure, but if you run it from the command line, then you just wipe the shell history afterwards, clear your screen, and there will be no trace of the plaintext password.

  • What about people reading the process table via ps for example? – Joseph R. Jul 22 '14 at 19:04
  • 1
    By definition, a "jumpbox" is a host for admins only. in other words, run this script on a box that only you and other admins have access to. It;s a "memory only" operation. If the box is decommissioned or reprovisioned later, there won't be any trace of the plaintext password on the hard drive. – Michael Martinez Jul 22 '14 at 19:07

sshpass -f[filename] parses a file with the password inside - then no need to clear your bash transaction history

From the man page:


The password is the first line of the file filename.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.