RHEL root password automatic change
 

To comply with standards I need to change the root pw every so often. However, I really don't have a need to know the root password; as the only thing using root, is for ssh authenticating via ssh keys.

What I want to do is automate the root password change monthly via a cron job, to a random value.

Is there a way to do this without knowing the previous password?

I'm asking because I'm having trouble getting to my rhel vm today to test.
Thanks!

My reaction is that you do NOT want to do this. First, how would you be informed of the new password with creating a security hole?

To whose standards are you referring? (I assume your employer and/or the person in charge of the computer you are using.) If they have such a rule, I bet you a truckload of cookies that they will not allow changing any password automatically.

What problem are you trying to solve?

We have similar requirement given by the auditors. Management decided to purchase those commercial privilege password management software to address this requirement.

As for your question: I think you can write a script that generates random passwd md5 hash and use sed to replace the line in /etc/shadow.

Corporate standards yes.
The meat of the issue is to be in compliance, passwords have to change every xx days. Since pub key authentication does not fall into policy as "password" we don't have to change the public key. however, if you ssh via keys with an expired password, you can't login.
We have no need to login as root for any other purpose, so knowing the root password, or propagating it is an non-issue.

will something like this work in a cron job?

echo "$new_password" | passwd --stdin root

assuming $new_password is generated previously?
I'm asking to bide my time while waiting for a system to test on.

Since you are dealing with a corporate requirement, I suspect that what you are proposing would be in violation of their rules. LQ cannot be involved in helping you circumvent the rules of your environment.

Even if it does not violate the rules, what you are proposing is still a very bad idea.

Since you're interested in compliance, it would be a good idea to check with your security staff to ensure that implementing this actually gets you there. (It may be that they're less than thrilled with the idea, which would make this all a moot point.)

On top of that, are you sure you don't want anyone to have root's password? That sounds like a recipe for trouble, sooner or later (probably sooner). Do you have multiple full sudoers on the system or something?

As for implementing this, it's fairly trivial. As you noted, some versions of passwd(8) will happily read from stdin. You might adapt something like this to actual produce the "random" password. Ensuring that your generated passwords meet your organizations policies is another matter.

Tread carefully with this one.

Corporate rules are all in the wording; what I am proposing is already approved. I'm not trying to circumvent anything, I'm trying to build compliance.

I have seen other corporations in a similar situation call tokens like this a passphrase instead of a password, because their security policies were worded specifically for passwords. If they called it a passphrase they didn't have to change it.

root is already limited to a single use between two systems both via firewall rules, and sshd rules. Since the only way someone could potentially log in from a console as root is by single user mode anyways, I am very comfortable having the root password not be known.

Even if you're happy not to have the root password, it really should be known. I can guarantee that at some point in the future you'll want it. However, that doesn't mean you can't do what you want.

For instance, you could automatically generate a new random password on the server (using e.g. a pipe into 'passwd' as already mentioned), use gpg to encrypt it with a public key, then have it emailed or copied to somewhere safe. If you ever need it (and I'm sure you will), just decrypt it with the private key (stored somewhere safe (like a usb token in a safe). This way you only need to keep the private key safe, you can pass around the encrypted password as much as you want.

Just make sure that the password never ends up on the disk in cleartext.

Hopefully you'd never need to use the password, but if you do you'll be glad to have it.


Hope that helps.

That assumes SMTP is an allowed flow, and that public keys are setup, which could also be an issue in a production GA appliance. All I need is an admin/service account with sudo priv. My preference would be to not allow root at all, however due to circumstances out of my control here I am asking for this kludge to try and harden the system, without breaking function and being as much in compliance as possible

I feel your pain. I've worked at big banks before, and have swam through those 'compliance' waters. Best advice I can give you, is to deny root login from anything but the console (since you're in a big shop, the console is/should be, in a locked room, controlled access etc.). Only allow SSH connections in, disable VNC connections and remote X. Use the AllowUsers/DenyUsers in sshd.conf to lock the admins (like yourself), to a particular workstation IP address (if possible). That way, YOU can only log in from YOUR desk. Root is absolutely needed at times...SUDO can't do everything.

I'd keep the root password to myself and the other admins. Let NO ONE else have it, even compliance, since they themselves, are security holes. After all, you can't have non-technical users have admin rights, when you can't track them and know how they keep the root password secure, right?? :)

I see what you mean, but the email thing was just an example. Once the password is encrypted it can be stored anywhere. You could leave it in a directory on the server, print it out, or whatever you want. It's safe as long as your private key is safe.

As for the key infrastructure problems, it'd take five minutes (probably less) to generate a set of keys. Afterall, this key is only for emergencies with the private key stored in a secure environment (and hopefully never used). A secure usb crypto token locked in a safe would surely be compliant with your protocols.

Fundamentally though it's important for SOMEONE to have access to the root password. There will be times when you need it. Perhaps (just an example) your filesystem gets corrupted and messes up your sudoers file or prevents user logins. You won't be able to fix it without the root password.

Also, bear in mind that sudo doesn't in itself provide any more security, it depends how you use it. For instance, you're saying that you need an admin account with full sudo privileges. That account then becomes the defacto root account. Because you're logging in with this account to do things, you might have actually reduced the overall security (afterall, the admin account(s) would probably have passwords you can remember, or at least type in a reasonable time). If you're relying on just using public keys and ssh, what happens if the network goes down? As pointed out previously, you could limit root logons to the console, but if the network's down, (and your network has e.g. domain or ldap based logins), you're stuck.

I'm not trying to argue, just pointing out a few things. Also, I feel your pain regarding security practices that come 'from on high', but just trying to blindly implement something because you're told is certainly not the best policy.

Good luck.

I agree, a sudo user with a full admin, is not much more than a more audit able root user, though that's compliant.

Since there are no use cases where console access is going to be required, or even authorized, in a catastrophic event such as file system corruption, either that system will be replaced, or single user mode can be used to recover.

Storing the password on the system, or even routing it to a USB key(usb is disabled) would be also non-compliant.

I'm just proposing the best choices I can for the system given the interpretations of the rules I have.

Certainly trying to pick apart a design without sharing the policy and the design makes it unfair to discourse back and forth!

Yes, it is a difficult thing to address. Only you really have all the answers to your environment, and have to make the decision.

To that end, Perl has some crypt modules that I've used before. Specifically, the authen::PAM module:
http://search.cpan.org/~nikip/Authen-PAM-0.16/d/PAM.pm

Or you can try this:
Try that. :)

Oh em gee
 

Why is everyone on here telling him what he does or does not want to do and telling them "lq wont help you because of x y or z" if you dont want to help then dont reply. [MODERATED]

@Bricker: From the LQ Rules:Reported.