I cannot find answer on google on that anywhere (because of SEO and nature of english language I cannot ask correct question as I am not native)
I'll try to explain as simple as I can:
I connected to mysql as root
Did use mysql;
Did select user,host,password from mysql.user;
I got in response:
+---------+-----------+-------------------------------------------+
| User | Host | Password |
+---------+-----------+-------------------------------------------+
| root | localhost | *5298BA3BC4092F7B664B1A71FE173FBA4F8C6BA1 |
| mysql | localhost | invalid |
Is this normal? After my server was hacked, I rebuild it from scratch, reinstalled mariadb with the same settings as before but I don't remember if this is normal.
MariaDB version is:
mysql Ver 15.1 Distrib 10.4.11-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
I have very large database (over 4GB) and cannot do a single query on it because error 2013 (i.e. "Lost connection to MySQL server during query") so I am trying to narrow the cause of malfunction. Struggling with the problem for 5 days and I am out of options so just curious if this may have something to do with it.
It's not very clear in their documentation, but it appears to be the normal initial string for a user's password:
https://mariadb.com/kb/en/authentication-from-mariadb-104/
... an invalid password is initially set, so in order to authenticate this way, a password must be set with SET PASSWORD.
Later in the same page:
... the old authentication method — conventional MariaDB password — is still available. By default it is disabled (“invalid” is not a valid password hash), but one can set the password with a usual SET PASSWORD statement.
The string "invalid" is used instead of a legitimate hash string, because there's no way any password you type could be hashed and result in the string "invalid." That string isn't even the right length to be the result of a hash. Also, it contains characters that are not valid hexadecimal digits.
Practically any other word or phrase could be stored in place of the word "invalid," this is just what the developer chose to use.
Note this trick of storing a non-hash string in the field intended for a password hash doesn't work in MySQL 5.7. I've seen this trick used before in MySQL 5.6, but when we upgraded to MySQL 5.7, it wouldn't accept a string in that place unless it was a valid hash string.
The short answer:
Nothing is wrong with your user credentials, and unless you don't have a good reason for there is no need to change the password.
The long answer:
Since MariaDB 10.4.3 the default authentication method for connections using the unix socket (connecting to localhost without specifying a TCP port) is the unix_socket authentication. Unix socket authentication doesn't require a password anymore:
When the client opens a connection to the server, the server checks the uid of the process which opened the socket connection and retrieves the user name associated to the uid.
A major advantage of this authentication method is that no additional plug-in is required on the client side, so all database driver will support this authentication method out of the box.
Related
I'm using the mysql 8.0.15. i know there is one same question, but in the recent version mysql 8.0.11, PASSWORD function is removed. I'm trying to get back my root user password, i have got the encrypted string caching_sha2_passIBjIZxTzot5bM9bujMxG9orfl6Ctt.w2SDLZUzAsrxD0 how can i decrpyt it? Also i try to follow solutions from this to reset password, but without the password function, almost cannot proceed.
Passwords for authentication are stored in a way that's irrecoverable, it's a one-way hashing function that's applied. In this case it's SHA2.
There's no way to "unhash" this by design. The database entry contains just enough information to validate any given password, but not enough to tell you what the password is.
You can reset the password by disabling password checks and set a new password.
I have a wildcard cert issued from rapidssl, using CN=*.mydomain.com. I have a web server and a mysql db server. The certs are working fine for web site access. Now I want to enable ssl for my app to mysql. I've enabled ssl in the mysql server without issue:
+---------------+---------------------------------+
| Variable_name | Value |
+---------------+---------------------------------+
| have_openssl | YES |
| have_ssl | YES |
However, when I try to connect using the client/ssl, I get:
ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)
This appears to be documented here:
http://dev.mysql.com/doc/refman/5.5/en/creating-ssl-certs.html
It says I can't use the same CN for the certs. I don't understand how a wildcard cert can be used then. Does that mean I also have to purchase host specific certs just for the mysql connection?
I don't work with SSL very much so I'm finding it difficult figuring out how this is supposed to be set up. Any pointers, even obvious ones, will likely help at this stage.
Running:
mysql Ver 15.1 Distrib 5.5.32-MariaDB, for debian-linux-gnu (x86_64) using readline 5.1
ubuntu 12.04
Make sure to use an absolute path to the ca-cert given for the --ssl-ca option.
Relative paths, or shell expansions (like ~) won't work and will produce ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation.
This isn't documented anywhere that I can see in the mysql man page, or in the SSL Command Options of the MySQL Manual (http://download.nust.na/pub6/mysql/doc/refman/5.1/en/ssl-options.html).
I have a similar issue, apparently from what i have read all the binary (precompiled) versions of MySQL Community Edition (maybe the same applies to MariaDB), comes bundled with yaSSL not openSSL existing some limitations and restrictions from that library. According to the manual of mysql (https://dev.mysql.com/doc/refman/5.6/en/secure-connection-options.html)
" yaSSL does not look in any directory and does not follow a chained certificate tree.yaSSL requires that all components of the CA certificate tree be contained within a single CA certificate tree and that each certificate in the file has a unique SubjectName value. To work around this yaSSL limitation, concatenate the individual certificate files comprising the certificate tree into a new file and specify that file as the value of the --ssl-ca option".
If you want to check if your MySQL instalation uses yaSSL or openSSL you can follow the steps in this forum (http://mysqlblog.fivefarmers.com/2013/05/14/how-to-tell-whether-mysql-server-uses-yassl-or-openssl/). It tells to see the status variable ‘
Rsa_public_key’ with ‘show status like ‘%rsa%’ if your MySQL installation comes with yaSSL the results must be empty because no such variable exists in distributions with yaSSL.
Other possible cause is that the hostname on your server doesn't match with the subject of the server certificate (argument of the --ssl-cert parameter) for that compare the output of the command
shell> hostname
with the DNS subject in the server certificate, you could get it using the next command (look the part where it says "X509v3 Subject Alternative Name:"):
shell> openssl x509 -in "your-server-certificate" -noout -text
If none of this work you could see the next page http://milcom.us/2012/11/02/encrypted-mysql-connections/
PS: English is not my native language, sorry for any grammatical error
I was having the following error:
[root#example ~]$ mysql
ERROR 2026 (HY000): SSL connection error
FIX that worked for me: Server and client "Common Name" in certificates must be different than CA's. After changing the CNs the error stopped; I verified the connection status:
mysql> status;
...
SSL: Cipher in use is DHE-RSA-AES256-SHA
...
Source:
"Important Whatever method you use to generate the certificate and key
files, the Common Name value used for the server and client
certificates/keys must each differ from the Common Name value used for
the CA certificate. Otherwise, the certificate and key files will not
work for servers compiled using OpenSSL."
http://dev.mysql.com/doc/refman/5.0/en/creating-ssl-certs.html
PS: I'm not using wildcard certificates and/or a third party CA, I'm creating my own signed certificates, which works OK for me: http://angelcool.net/sphpblog/comments.php?y=14&m=05&entry=entry140511-164525
MySQL doesn't work with wildcard certificates. There are a number of difficiencies with MySQL and SSL.
See my post on Getting MySQL server to run with SSL (and also the post that I refer to therein).
I connect from CentOS-7 version ojf 5.6.29-76.2-log Percona Server and Client
to CentOS-6 (Server version: 5.6.23-72.1-log Source distribution Percona), also get this issue.
Add the option will fix it:
--ssl-cipher=AES128-SHA
maybe anther ssl-cipher will also fixed.
I'm trying to connect to a mySQL database at http://bluesql.net, but when I try to connect, it gives this error:
Connect Error (2000) mysqlnd cannot connect to MySQL 4.1+ using old authentication
I've looked into this, and it has to do with some old password scheme used before MySQL 4.1. Newer versions have the option to use old passwords, which I've read may cause this problem.
I'm running php 5.3, and connecting with mySQLi (new mysqli(...)). I'm hoping I can do something in the code to connect to the DB at bluesql.net - clearly I don't control how their database is set up. Downgrading php versions isn't an option.
Anyone have any ideas?
edit: This only applies if you are in control of the MySQL server... if you're not take a look at Mysql password hashing method old vs new
First check with the SQL query
SHOW VARIABLES LIKE 'old_passwords'
(in the MySQL command line client, HeidiSQL or whatever front end you like) whether the server is set to use the old password schema by default. If this returns old_passwords,Off you just happen to have old password entries in the user table. The MySQL server will use the old authentication routine for these accounts. You can simply set a new password for the account and the new routine will be used.
You can check which routine will be used by taking a look at the mysql.user table (with an account that has access to that table)
SELECT `User`, `Host`, Length(`Password`) FROM mysql.user
This will return 16 for accounts with old passwords and 41 for accounts with new passwords (and 0 for accounts with no password at all, you might want to take care of those as well).
Either use the user management tools of the MySQL front end (if there are any) or
SET PASSWORD FOR 'User'#'Host'=PASSWORD('yourpassword');
FLUSH Privileges;
(replace User and Host with the values you got from the previous query.) Then check the length of the password again. It should be 41 now and your client (e.g. mysqlnd) should be able to connect to the server.
see also the MySQL documentation:
* http://dev.mysql.com/doc/refman/5.0/en/old-client.html
* http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html
* http://dev.mysql.com/doc/refman/5.0/en/set-password.html
If you do not have control of the server
I just had this issue, and was able to work around it.
First, connect to the MySQL database with an older client that doesn't mind old_passwords. Connect using the user that your script will be using.
Run these queries:
SET SESSION old_passwords=FALSE;
SET PASSWORD = PASSWORD('[your password]');
In your PHP script, change your mysql_connect function to include the client flag 1:
define('CLIENT_LONG_PASSWORD', 1);
mysql_connect('[your server]', '[your username]', '[your password]', false, CLIENT_LONG_PASSWORD);
This allowed me to connect successfully.
Edit: as per Garland Pope's comment, it may not be necessary to set CLIENT_LONG_PASSWORD manually any more in your PHP code as of PHP 5.4!
Edit: courtesy of Antonio Bonifati, a PHP script to run the queries for you:
<?php const DB = [ 'host' => '...', # localhost may not work on some hosting
'user' => '...',
'pwd' => '...', ];
if (!mysql_connect(DB['host'], DB['user'], DB['pwd'])) {
die(mysql_error());
} if (!mysql_query($query = 'SET SESSION old_passwords=FALSE')) {
die($query);
} if (!mysql_query($query = "SET PASSWORD = PASSWORD('" . DB['pwd'] . "')")) {
die($query);
}
echo "Excellent, mysqli will now work";
?>
you can do these line on your mysql query browser or something
SET old_passwords = 0;
UPDATE mysql.user SET Password = PASSWORD('testpass') WHERE User = 'testuser' limit 1;
SELECT LENGTH(Password) FROM mysql.user WHERE User = 'testuser';
FLUSH PRIVILEGES;
note:your username and password
after that it should able to work. I just solved mine too
On OSX, I used MacPorts to address the same problem when connecting to my siteground database. Siteground appears to be using 5.0.77mm0.1-log, but creating a new user account didn't fix the problem. This is what did
sudo port install php5-mysql -mysqlnd +mysql5
This downgrades the mysql driver that php will use.
Had the same issue, but executing the queries alone will not help. To fix this I did the following,
Set old_passwords=0 in my.cnf file
Restart mysql
Login to mysql as root user
Execute FLUSH PRIVILEGES;
If you do not have Administrator access to the MySQL Server configuration (i.e. you are using a hosting service), then there are 2 options to get this to work:
1) Request that the old_passwords option be set to false on the MySQL server
2) Downgrade PHP to 5.2.2 until option 1 occurs.
From what I've been able to find, the issue seems to be with how the MySQL account passwords are stored and if the 'old_passwords' setting is set to true. This causes a compatibility issue between MySQL and newer versions of PHP (5.3+) where PHP attempts to connect using a 41-character hash but the MySQL server is still storing account passwords using a 16-character hash.
This incompatibility was brought about by the changing of the hashing method used in MySQL 4.1 which allows for both short and long hash lengths (Scenario 2 on this page from the MySQL site: http://dev.mysql.com/doc/refman/5.5/en/password-hashing.html) and the inclusion of the MySQL Native Driver in PHP 5.3 (backwards compatibility issue documented on bullet 7 of this page from the PHP documentation: http://www.php.net/manual/en/migration53.incompatible.php).
IF,
You are using a shared hosting, and don't have root access.
you are getting the said error while connecting to a remote database ie: not localhost.
and your using Xampp.
and the code is running fine on live server, but the issue is only on your development machine running xampp.
Then,
It is highly recommended that you install xampp 1.7.0 . Download Link
Note: This is not a solution to the above problem, but a FIX which would allow you to continue with your development.
For some reason, when creating a MySQL user with empty password, it only allows connections if the user has the same name as a system user (Ubuntu Server 10.04, MySQL version 5.1.41). According to everything I have read so far, MySQL users ought to be completely separate from the system user accounts, so I'm not sure how to explain what's going on.
Am I doing something wrong? Is there some settings somewhere that affects this?
(Additional info:
I'm setting this up to only allow connections from the local network; some of the tools I'm using on a project require a user without a password.)
This seems likely to be a duplicate, though when I searched I couldn't find any previous question about this issue. If the same question HAS been asked before, I apologize.
here is something i found in mysql docs.
When you assign an account a nonempty password using SET PASSWORD, INSERT, or UPDATE, you must use the PASSWORD() function to encrypt the password, otherwise the password is stored as plaintext. Suppose that you assign a password like this:
mysql> SET PASSWORD FOR
-> 'username'#'localhost' = 'mypass';
The result is that the literal value 'mypass' is stored as the password in the user table, not the encrypted value. When user attempts to connect to the server using this password, the value is encrypted and compared to the value stored in the user table. However, the stored value is the literal string 'mypass', so the comparison fails and the server rejects the connection with an Access denied errorFirst have a user name (other than system name) with some password.
So have a user name of your choice with some passowrd and then use PASSWORD() function to set an empty password. The use of the function can be seen here.
I have a Perl script that gets data from a MySQL database on one server (let's call it server1), does stuff with it and writes it out to another database on another server (server2). Both servers are remote to the server that runs the Perl script.
I can connect to the DB on server1 OK, but when I try to connect to the DB on server2, using the same DBI method, I get an error. Here, as command-line Perl, is the bit that's causing the error:
perl -MDBI -e 'DBI->connect("DBI:mysql:myDB:server2.whatever.co.uk","myuser","mypassword") or die DBI->errstr;'
And here's the error message:
DBI connect('myDB:server2.whatever.co.uk','myuser',...) failed: Client does not support authentication protocol requested by server; consider upgrading MySQL client at -e line 1
Client does not support authentication protocol requested by server; consider upgrading MySQL client at -e line 1.
I do not have root access so I can't upgrade MySQL and I can't change the password to use the old password hashing algorithm, which is the solution suggested in lots of places.
Ideas anyone?
The database may be set up to accept connections only from within a certain set of addresses, as a security measure. So if you're trying to access a prod database from a home laptop (for example), it may reject you, even if you have the proper credentials. Try accessing it from a place where it's known to work using another technology -- for example, if you have a website that accesses it already, go to wherever apache/tomcat is running, and try the perl there. If it works, that's the issue. You can also proactively check on the database settings.
OK, in the absence of an alternative, I got someone with root access to server2 to do the fix that's published elsewhere:
Connect to MySQL as the MySQL root user, then:
mysql> use mysql;
mysql> SET PASSWORD FOR 'username'#'hostname' = OLD_PASSWORD('password');
mysql> FLUSH PRIVILEGES;
Replacing 'username', 'hostname' and 'password' with appropriate values.
So what I'm saying here is, it seems like if you don't have root access to upgrade MySQL or to change the password to use the old password hashing algorithm, then the only solution is to find someone who does who can make the change for you.