I want to password protect my entire site. I am running Debian Squeeze. Say I want my username to be "Jane" and my password to be "V3RySEcRe7".
In my app-nginx.conf:
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/htpasswd;
In my shell script I have this:
printf "Jane:$(openssl passwd -1 V3RySEcRe7)\n" >> /etc/nginx/htpasswd
When I go to my site it is password protected, but the credentials I use don't work. Where am I going wrong here?
I'm sure you'd have fixed this by now, but thought I'd add this for others:
The Nginx documentation is a little cryptic on this, but does mention the "Apache variant of the MD5-based password algorithm (apr1)" should be used to generate the password hash. So using the -apr1 flag instead of -1 will work:
printf "Jane:$(openssl passwd -apr1 V3RySEcRe7)\n" >> /etc/nginx/htpasswd
Related
I need to login into 50 hosts and perform a specific task.
Each host has one of 2 passwords (ex: pass1 and pass2) for a specific user (ex: foo).
I do not know on which host "foo" is set with "pass1" and on which host "foo" is set with "pass2". I have both passwords in a vault file.
Using Ansible, how can I first make a task where I try to login as "foo" with "pass1", then if unsuccessful login with "pass2" and finally setting a fact with the correct vault value (depending on which password worked i.e. "foo" managed to login).
I then want to use that fact to perform additional tasks on that same host.
The developer who created a platform my company uses is no longer working for us and I don't know how I can retrieve the passwords from a custom PHP application
When I look in the PHPmyAdmin the passwords are ecrypted (eg *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19)
How can I change or retrieve these?
If a proper encryption method was used, it's not going to be possible to easily retrieve them.
Just reset them with new passwords.
Edit: The string looks like it is using PASSWORD():
UPDATE user SET password = PASSWORD("newpassword");
How can I decrypt MySQL passwords
You can't really because they are hashed and not encrypted.
Here's the essence of the PASSWORD function that current MySQL uses. You can execute it from the sql terminal:
mysql> SELECT SHA1(UNHEX(SHA1("password")));
+------------------------------------------+
| SHA1(UNHEX(SHA1("password"))) |
+------------------------------------------+
| 2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 |
+------------------------------------------+
1 row in set (0.00 sec)
How can I change or retrieve these?
If you are having trouble logging in on a debian or ubuntu system, first try this (thanks to tohuwawohu at https://askubuntu.com/questions/120718/cant-log-to-mysql):
$ sudo cat /etc/mysql/debian.conf | grep -i password
...
password: QWERTY12345...
Then, log in with the debian maintenance user:
$ mysql -u debian-sys-maint -p
password:
Finally, change the user's password:
mysql> UPDATE mysql.user SET Password=PASSWORD('new password') WHERE User='root';
mysql> FLUSH PRIVILEGES;
mysql> quit;
When I look in the PHPmyAdmin the passwords are encrypted
Related, if you need to dump the user database for the relevant information, try:
mysql> SELECT User,Host,Password FROM mysql.user;
+------------------+-----------+----------------------+
| User | Host | Password |
+------------------+-----------+----------------------+
| root | localhost | *0123456789ABCDEF... |
| root | 127.0.0.1 | *0123456789ABCDEF... |
| root | ::1 | *0123456789ABCDEF... |
| debian-sys-maint | localhost | *ABCDEF0123456789... |
+------------------+-----------+----------------------+
And yes, those passwords are NOT salted. So an attacker can prebuild the tables and apply them to all MySQL installations. In addition, the adversary can learn which users have the same passwords.
Needles to say, the folks at mySQL are not following best practices. John Steven did an excellent paper on Password Storage Best Practice at OWASP's Password Storage Cheat Sheet. In fairness to the MySQL folks, they may be doing it because of pain points in the architecture, design or implementation (I simply don't know).
If you use the PASSWORD and UPDATE commands and the change does not work, then see http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html. Even though the page is named "resetting permissions", its really about how to change a password. (Its befuddling the MySQL password change procedure is so broken that you have to jump through the hoops, but it is what it is).
Hashing is a one-way process but using a password-list you can regenerate the hashes and compare to the stored hash to 'crack' the password.
This site https://crackstation.net/ attempts to do this for you - run through passwords lists and tell you the cleartext password based on your hash.
With luck, if the original developer was any good, you will not be able to get the plain text out. I say "luck" otherwise you probably have an insecure system.
For the admin passwords, as you have the code, you should be able to create hashed passwords from a known plain text such that you can take control of the application. Follow the algorithm used by the original developer.
If they were not salted and hashed, then make sure you do apply this as 'best practice'
just change them to password('yourpassword')
You can't decrypt MySQL passwords, because the are hashed by using MD5 hash algorithm, which is not an encryption algorithm.
Simply best way from linux server
sudo mysql --defaults-file=/etc/mysql/debian.cnf -e 'use mysql;UPDATE user SET password=PASSWORD("snippetbucket-technologies") WHERE user="root";FLUSH PRIVILEGES;'
This way work for any linux server, I had 100% sure on Debian and Ubuntu you win.
Okay, hopefully I can explain this correctly as I have no idea what's causing this or how to resolve this.
For some reason bash commands (on a CentOS 6.x server) are displaying more information than "normally" and that causes issues with certain scripts. I have no clue if there is a name for this, but hopefully someone knows a solution for this.
First example.
Correct / good server:
[root#goodserver ~]# vzctl enter 3567
entered into CT 3567
[root#example /]#
(this is the correct behaviour)
Incorrect / bad server:
[root#badserver /]# vzctl enter 3127
Entering CT
entered into CT 3127
Open /dev/pts/0
[root#example /]#
With the "bad" server it will display more information as usual, like:
Entering CT
Open /dev/pts/0
It's like it parsing extra information on what it's doing.
Ofcourse the above is purely something cosmetic, however with several bash scripts we use, these issues are really issues.
A part of the script we use, uses the following command (there are more, but this is mainly a example of what's wrong):
DOMAIN=`vzctl exec $VEID 'hostname -d'`
The result of the above information is parsed in /etc/named.conf.
On the GOOD server it would be added in the named.conf like this:
zone "example.com" {
type master;
file "example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
The above is correct.
On the BAD server it would be added in the named.conf like this:
zone "Executing command: hostname -d
example.com" {
type master;
file "Executing command: hostname -d
example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
So it's add stuff of the action it does, in this example "Executing command: hostname -d"
Another example here when I run the command on a good server and on the bad server.
Bad server:
[root#bad-server /]# DOMAIN=`vzctl exec 3333 'hostname -d'`
[root#bad-server /]# echo $DOMAIN
Executing command: hostname -d example.com
Good server:
[root#good-server ~]# DOMAIN=`vzctl exec 4444 'hostname -d'`
[root#good-server ~]# echo $DOMAIN
example.com
My knowledge is limited, but I have tried several things checking rsyslog and the grub.conf, but nothing seems out of the ordinary.
I have no clue why it's displaying the extra information.
Probably it's something simple / stupid, but I have been trying to solve this for hours now and I really have no clue...
So any help is really appreciated.
Added information:
Both servers use: kernel.printk = 7 4 1 7
(I don't know if that's useful)
Well (thanks to Aaron for pointing me in the right direction) I finally found the little culprit which was causing all the issues I experienced with this script (which worked for every other server, so no need to change that obviously).
The issues were caused by the VERBOSE leven set in vz.conf (located in /etc/vz/ directory). There is an option in there called "VERBOSE" and in my case it was set to 3.
According to OpenVZ's website it does the following:
Increments logging level up from the default. Can be used multiple times.
Default value is set to the value of VERBOSE parameter in the global
configuration file vz.conf(5), or to 0 if not set by VERBOSE parameter.
After I changed VERBOSE=3 to VERBOSE=0 my script worked fine once again (as it did for every other server). :-)
So a big shoutout to Aaron for pointing me in the right direction. The answer is easy when you know where to look!
Sorry to say, but I am kinda disappointed by ndim's reaction. This is the 2nd time he was very unhelpful and rude in his response after that. He clearly didn't read the issue I posted correctly. Oh well.
I would make sure to properly parse the output of the command. In this case, we are only interested in lines of the form
entered into CT 12345
One way of doing this would be to pipe everything through sed and having sed print only the number when the line looks as above (untested, and I always forget which braces/brackets/parens need a backslash in front of them):
whateverthecommand | sed -n 's/^entered into CT ([0-9]{1,})$/\1/p'
I am using Chef with kitchen (1.5.0) and vagrant (1.8.1) to manage a user consistently with a new server. My user recipe looks like this:
include_recipe "users"
group 'sudo'
password_secret = Chef::EncryptedDataBagItem.load_secret(node['enterprise_sp']['secret_file'])
jays_password = Chef::EncryptedDataBagItem.load('user_secrets','jgodse', password_secret)['password']
shadow_password = `openssl passwd -1 -salt xyz #{jays_password}`.strip
user 'jgodse' do
action :create
group 'sudo'
system true
shell '/bin/bash'
home '/home/jgodse'
manage_home true
password shadow_password #added to /etc/shadow when chef runs
end
The unencrypted data bag was where I configured my password in the clear. I then encrypted the data bag with a knife command.
This works, but this seems like a really dirty way around the problem of setting my password. I had to do that because the password directive of the user block only takes the shadow password, and that can only be generated by shelling out to an openssl command.
Is there a cleaner way of getting the shadow password without shelling out to an openssl command which generates the password?
You should not be storing the password at all, just hash it beforehand and put the hash in the data bag in the first place. Also using encrypted data bags like this is scary-level unsafe, please take some time to familiarize yourself with the threat model of Chef's encryption tools, this ain't it.
At least pre-calculate the password hash and put that into the data bag.
See https://github.com/chef-cookbooks/users for inspiration.
I've two text files one with list of server name's, another file with their root password (Unique password)
I have to check all server root password by logging to individual servers. but the issue is, by default ssh root login is disabled. Hence i have to login via my normal user(Test) and switch as root and try the root password which is mentioned in the text file.
is there any way i can get this automated ? highly appreciate if anyone can help me out.
Linux passwords are stored in /etc/shadow files.
They're just hashed plain-text, no magic.
Take a look at python's crypt.crypt() function.
# change 'root' password to 'secret' (demo only)
$ echo root:secret | chpasswd
Password for 'root' changed
# get 'root' hashed password
$ grep root /etc/shadow
root:$6$YvK0oNOm$k.zELztgUM2LajbVGsqtp5I3mGP3clC6vL7rNdVCNfg2FUtLOnfb94Bn6acfCp4cQpXxSAZ1Zt55K8rAgQ3nT0:16673:0:::::
# verify hashed password is correct
$ python -c 'import crypt; print crypt.crypt("secret", "$6$YvK0oNOm$") == "$6$YvK0oNOm$k.zELztgUM2LajbVGsqtp5I3mGP3clC6vL7rNdVCNfg2FUtLOnfb94Bn6acfCp4cQpXxSAZ1Zt55K8rAgQ3nT0"'
True
You can collect shadow files from all servers, and verify them locally.
WARNING: Shadow files are very sensitive.
This is a simple solution.
input.csv
192.168.1.1,secret,$6$YvK0oNOm$k.zELztgUM2LajbVGsqtp5I3mGP3clC6vL7rNdVCNfg2FUtLOnfb94Bn6acfCp4cQpXxSAZ1Zt55K8rAgQ3nT0
192.168.1.2,pAssWd,$6$AbcdeFgh$1234fsXXXXXXXXXXXsqtp5I3mGP3clC6vL7rNdVCNfg2FUtLOnfb94Bn6acfCp4cQpXxSAZ1Zt55K8rAgQ3nT0
192.168.1.3,123456,$6$efsjdsix$8787sdfsdsdfsd232sqtp5I3mGP3clC6vL7rNdVCNfg2FUtLOnfb94Bn6acfCp4cQpXxSAZ1Zt55K8rAgQ3nT0
check.py
import csv, crypt
for i, j, k in csv.reader(open('input.csv')):
if crypt.crypt(j, k) != k:
print i
result
$ python check.py
192.168.1.2
192.168.1.3