Managing a local users password with puppet on EL7

[jmp242]

I'm not sure what's going on, but when I try and log in to XFCE using 
the local user account, I just get "Something went wrong". I've 
verified the password - but I wonder if I'm misunderstanding the puppet 
docs on the hashing, because it's obvious the password I have isn't working.

My line creating the password is

password => Sensitive(str2saltedsha512($password)),



On the plus side, the Sensitive() function works, but I wonder if the 
str2saltedsha512() is not the right form / function? Under Windows we 
always just used a string in puppet, but the docs imply under RHEL it 
wants that salted sha512 ...

The relevant part seems to be:
password
(Property: This attribute represents concrete state on the target system.)

The user’s password, in whatever encrypted format the local system 
requires. Consult your operating system’s documentation for acceptable 
password encryption formats and requirements.

Mac OS X 10.5 and 10.6, and some older Linux distributions, use salted 
SHA1 hashes. You can use Puppet’s built-in sha1 function to generate a 
salted SHA1 hash from a password.

Mac OS X 10.7 (Lion), and many recent Linux distributions, use salted 
SHA512 hashes. The Puppet Labs stdlib module contains a str2saltedsha512 
function which can generate password hashes for these operating systems.

This post (re RHEL6.3 though) implies the puppet documentation is just 
wrong, or we have old modules?
https://stackoverflow.com/questions/19114328/managing-a-user-password-for-linux-in-puppet

I then tried:
password => pw_hash('password', 'SHA-512', 'mysalt'),



Which also doesn't seem to work. What am I missing here?

[jmp242]

Sorry, the second one is also wrapped with Sensitive()

Sensitive(pw_hash('$password', 'SHA-512', 'oursalt')),

[Bart-Jan Vrielink]

Hello,

I doubt str2saltedsha512 can be used to generate encrypted passwords, as the resulting string does not contain the id nor salt.

pw_hash should work, although in the brief test I just did, it looks like a lower case 'sha-512' should be used.

I think you should debug this issue a little more on the client system.

Can you check the output (don't post it!) of 'getent shadow username'? It should consist of 9 colon separated fields, where the first one is the username and the second one the encrypted password. This encrypted password should start with $6$, the salt you've chosen, a third $ and finally the password hash.

If this string looks OK, then you should check the system journal (which you can read with 'journalctl -e') for any errors during the login (attempt).

Just to make sure the problem is not Puppet related, try to manually set a password for this user.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9ef3af13-aecc-44b0-afa5-55dc0aeeb53e%40googlegroups.com.

[jmp242]

So, I set the password manually with passwd and got an entirely different hash than when I use the pw_hash function. The salt is obviously different as well, but the rest of /etc/shadow entry is the same. ssh user@localhost works with the password when I set manually with passwd, and does not work with pw_hash - not surprisingly.

 

I tried lowercase sha-512, and got the same hash as with uppercase SHA-512. Both methods (working manual passwd, and non working pw_hash) start with $6$ which implies a sha-512 hash from the docs, so I think pw_hash is just broken for EL7. Which means the user resource is broken.

I guess temporarily, I'll just set the hash as a string and generate it with passwd, and see if that works - but it's obviously not ideal.

[Bart-Jan Vrielink]

Hello,

I'm still puzzled by why this is not working on your system. The following works for me on a Centos7 machine:

user { 'testuser':
  ensure             => 'present',

  password           => pw_hash('password', 'SHA-512', 'mysalt'),
}

-----Original message-----
From: jmp242 <jp1...@gmail.com>
Sent: Friday 15th November 2019 14:41
To: Puppet Users <puppet...@googlegroups.com>

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/64419ef7-6d5b-4028-8548-194ea8fae8c7%40googlegroups.com.

[jmp242]

I figured it out. Thanks for the help. It's because I wasn't doing I

 password           => pw_hash('password', 'SHA-512', 'mysalt'),

 I was doing

Sensitive(pw_hash('$password', 'SHA-512', 'oursalt')),

And because I used single quotes, it wasn't actually getting the parameter / variable, but the literal $password. Remove the quotes entirely because it's just a variable, and it works!

And this is why you can't always just copy -> paste -> edit your stuff in!.

On Friday, November 15, 2019 at 8:55:57 AM UTC-5, Bart-Jan Vrielink wrote:

Hello,

I'm still puzzled by why this is not working on your system. The following works for me on a Centos7 machine:

user { 'testuser':
  ensure             => 'present',
  password           => pw_hash('password', 'SHA-512', 'mysalt'),
}

-----Original message-----
From: jmp242 <jp1...@gmail.com>
Sent: Friday 15th November 2019 14:41
To: Puppet Users <puppet...@googlegroups.com>
Subject: Re: [Puppet Users] Managing a local users password with puppet on EL7

So, I set the password manually with passwd and got an entirely different hash than when I use the pw_hash function. The salt is obviously different as well, but the rest of /etc/shadow entry is the same. ssh user@localhost works with the password when I set manually with passwd, and does not work with pw_hash - not surprisingly.

 

I tried lowercase sha-512, and got the same hash as with uppercase SHA-512. Both methods (working manual passwd, and non working pw_hash) start with $6$ which implies a sha-512 hash from the docs, so I think pw_hash is just broken for EL7. Which means the user resource is broken.

I guess temporarily, I'll just set the hash as a string and generate it with passwd, and see if that works - but it's obviously not ideal.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet...@googlegroups.com.

[Bart-Jan Vrielink]

Hello,

Glad to hear that you got it to work.

Before you put this into production, please make sure you don't re-use the same salt value. Try to randomize it. Something like seeded_rand_string(16,strftime("%s%L")) may work.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/609eade7-8f51-4881-a7a5-9aaeda2571c3%40googlegroups.com.

[Bart-Jan Vrielink]

Of course this is not idempotent. Mmm, security is difficult.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/zarafa.5dcec1b6.0474.3c55f75b3c65528f%40anjie.dontpanic.nl.

[A Manzer]

It's probably ok to reuse the same salt; it's just to defeat pre-computation attacks.

But if you really don't want to, you could:

• Use the username as the salt.  That'll be static, so idempotent, and different for every user.  Not as great as random salt, but better than no salt.
• Use a secrets server like Vault, and use the Hiera-Vault plugin to retrieve a password.  (Just make sure you test first.  I tested this about a year ago, and at the time the Hiera Vault plugin had a bug that eventually exhausted all the connections into Vault.)
  
• Don't actually use Puppet to set a password.  If this is your own user, just manage your password yourself with the `passwd` command.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/609eade7-8f51-4881-a7a5-9aaeda2571c3%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/zarafa.5dcec1b6.0474.3c55f75b3c65528f%40anjie.dontpanic.nl.