I need to change the password on a user for over a hundred system. I want to do this with ansible. Which is easy. However the user module on ansible requires a hashed password. I am concerned because there are a few older hosts which may not support newer types of hashing. I want to be able to programmatically identify what password hashing algorithms are available, and use the appropriate password hash to change. Or is there perhaps a better way to handle this whole sale.
I have considered the following:
echo username:password | chpasswd
and run that using the command module. That should use whatever the default algorithm is. Is there any cause for concern with this method?
In my mind, the ideal way would be to figure the supported hashes for each machine and then generate the proper hash for each machine.
The approach you list should work Just make sure you at "no_log: yes" to your task to ensure the password doesn't end up in the log file.
With either approach you're going to need have a way of getting the password(s) into ansible to use with the user module. Not sure if the passwords will be in a CSV file, yaml file or some other format. You could consider using vault to lock things down a bit more.
Related
I have been looking into Ansible vault but want to check something incase I have missed a crucial point.
Do you have to run the playbook and provide the password. Encrypting the data seems a great idea but if I share the playbook the person running it will require the password. If they have the password then they can decrypt the file and see the data.
I would like to use it to set passwords for files but would like non admins to be able to run the playbook.
Have I missed something. I am struggling to see its worth if this is the case.
Thanks
The purpose of the vault is to keep secrets encrypted "at rest" (eg, in your source control repo, on-disk), so that someone can't learn the secrets by getting ahold of the content. As others have mentioned, if you want to delegate use of the secrets without divulging them, you'll need an intermediary like Tower.
In your case you need something that will be brokering ansible execution. Because like you've said an encryption would be useless if you share the password.
Like it's mentioned in the comment you can use Ansible Tower, or you can try and set a simple http endpoint that will be trigerring ansible based on specified parameters.
I'm using Passwd::Keyring::Auto for Perl on Windows. I noticed that the keyring is not persistent.
Can I force it to be persistent on Windows?
http://search.cpan.org/~mekk/Passwd-Keyring-Auto-0.2703/lib/Passwd/Keyring/Auto.pm
Ex.
use Passwd::Keyring::Auto;
my $keyring = get_keyring(app=>"Test", group=>"Windows");
my $username = "someuser";
my $password = $keyring->set_password($username, $password, "mylostspace.com");
When my program ends, I'd like to get whatever passwords I had in the keyring like below:
$password = $keyring->get_password($username, "sometest.com");
However, the $keyring->is_persistent() always returns 0. I tried forcing the option PERSISTENT => 1 when I create the keyring, but that didn't work.
Thanks in advance
I simply haven't developed windows backend yet, as I do not own windows machine at the moment. Writing module like Passwd::Keyring::WindowsVault (or similar) should not be hard (especially considering one can consult python keyring library source for inspiration), but requires some programmer with Windows development environment. In case you are (or anybody else is) interested in writing one, I would be glad to help, but I am simply unable to test such a module or even to prepare binary distribution for CPAN.
Once such module exists, integrating it into Passwd::Keyring::Auto would be trivial
Pointers:
(what should Passwd::Keyring backend implement)
https://metacpan.org/pod/distribution/Passwd-Keyring-Auto/lib/Passwd/Keyring/Auto/KeyringAPI.pm
(APIs used by pythonic library)
https://bitbucket.org/kang/python-keyring-lib/src/8aadf61db38c70a5fe76fbe013df25fa62c03a8d/keyring/backends/Windows.py?at=default
(in perl it should be replaced with some XS as I do not know about anything like ctypes, module code structure would likely be similar to that of https://bitbucket.org/Mekk/perl-keyring-gnome/src )
And one more note: with some effort it should be possible to use Passwd::Keyring::PwSafe3 backend on Windows, to keep passwords persistent. You will still need to provide opening password for this storage (no open thanks to OS authorization) on every run but in case you have multiple passwords or want to manage them from GUI too it may make sense. You can try setting environment variable PASSWD_KEYRING_AUTO_PREFER to PwSafe3 to use this keyring (of course install the module beforehand).
I wrote a helper script in Ruby to handle my file synchronization through some servers. It was used only in my intranet and authentication was made by SSH keys. But now I want to use it where I can't use SSH keys and I want to store the passwords in a config file.
I know, there are some encryption libraries like bcrypt or OpenSSL, but I have a problem with that:
I start my script and enter my passphrase and it is stored in a variable to decrypt my passwords.
My code is open source.
So everybody, who has access with my user to my computer (which would be the first barrier, which I'd like to extend) and looks into the memory (where my passphrase is stored) can decrypt my password file. How is that handled in applications which are relevant to security?
Edith says as a reply to DevDude (but here, because I want to keep my specifications in my question):
But then this configuration file would be plain text and not encrypted. And when I encrypt this file there are two more issues in my opinion:
The super_secret_pwd would be stored in a variable, so when I would search in the memory of the computer, I would find it, wouldnt I?
The master password for encryption would be in the memory as plain text, too.
So the big question is: Is it possible to read plain text variables from the memory? As I know it is possible in C and a big security issue.
What you are looking for is to use a YAML file with the password/API keys. and never check this file into your repo.
Then you can reference this file on your initializers, and maybe make the password a global variable or x, use configatron, etc.
This is basically how production applications work, they read their important settings from a YAML file stored on the server itself.
This is what I use:
#c = configatron
# Per environment settings
app_settings = YAML.load_file('config/secret_stuff.yml')
#c.password = app_settings['super_secret_pwd']
Do not use ENVIRONMENT variables because they have all sort of security issues. They are an antipattern.
I am learning to use maven password encryption capabilities and I would like to know how to choose the parameter <password>. There are two things that I don't understand:
1) mvn --encrypt-master-password foobar will always give a different encrypted master password.
Since the encrypted master password is always different, I see only two possibilities:
A local property is stored somewhere so that it can be used to decrypt the encrypted master password to get the master password. That means that our encrypted server passwords can only be used locally.
Nothing is stored and the master password is useless and doesn't matter at all.
So, my questions here are:
What is stored locally? Will my master password remain safe? Is there a third possibility I didn't think of?
2) On the maven website, it is written:
Also note that the encrypted passwords can be decrypted by someone that has the master password and settings security file. Keep this file secure (or stored separately) if you expect the possibility that the settings.xml file may be retrieved.
If the settings security file is the thing to protect, why should I bother choosing a strong master password? Can't I just use foobar and keep my settings security file safe?
Also, it looks like someone with the two files (settings security file and settings file) would not need the master password to connect to the maven servers. He could use our identity without knowing the passwords. The master password is "only" needed to decrypt the servers passwords (to get them plain text). But then again, protecting the settings security file should be the way to go and the master password would remain useless.
My questions:
How important is the master password? Have I got to remember it? Can I use a long random phrase and forget it forever?
PS: I couldn't find my answer here.
First password is used to generated the master password only, then you can forget it. It is generated using encryption mechanisms and pseudo-random component. As a consequence of that, it should not be possible to decipher it. There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again.
This master password is used to cipher and decipher passwords in your settings file. It has the same value as an user-introduced password, but it is almost impossible to deduce it.
Then:
There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again. All the safety resides in the safety of the security-settings file.
The master password is not really important and you can forget immediately. You can use whatever you want.
I don't like this approach to protect my password and I would like having a real password cyphering mechanism with a real master password not stored. Public-private key with password strategies seems to be better.
I want to share my babushka deps in much the same way as The Conversation do: https://github.com/conversation/babushka-deps
However, I manage SSL certificates and SSH keys using chef. Right now those files are directly in my chef config, but as I'd like to share my babushka config I can't put them there.
Is there a good way in babushka to deal with secure, outside-of-repo files?
This is something I'm working on at the moment. There's no built-in way, but it can be accomplished with a little bit of scripting.
If you're running the deps on a remote system, say from a shell script, then I'd add a command to the script to first rsync the private data into place:
rsync -taP private/ user#host:~/private/
ssh user#host 'babushka "server configured"'
That's the simplest case, but it quickly gets messy. Instead, I'm doing this sort of thing with babushka itself, in order to describe the whole process in terms of deps.
I have a dep with a couple of small helper methods for installing babushka on a remote machine, and then running arbitrary deps on it. This allows you to write local deps that depend on the results of remote runs, effectively nesting babushka within itself.
It's not quite general enough to be merged into core yet (and it's in need of a refactor), but it works well. Here it is if you'd like to give it a go in the meantime:
https://github.com/conversation/babushka-deps/blob/master/provision.rb#L123-131
Using this method, you can pass arguments to each remote run. That makes it easy to supply private data, e.g. your private key, or an SSL cert for setting up your webserver, etc.
(Note though that argument values are logged to ~/.babushka/logs/dep-name on the local and remote boxes, so 'private' assumes that the relevant user accounts on both are trusted.)