I setup my website on AWS.
Now, the problem is: I am able to select data from my DB but I am not able to insert it. But, my root is having "Insert" privileges.
I did create another user and provided the same privileges but the same problem persists.
Here is my configuration:
mysql - "select" and "insert" privileges for "root" user.
+-------------+-------------+
| Select_priv | Insert_priv |
| Y | Y |
+-------------+-------------+
mysql - "host" and "user" details
+----------------+------+
| host | user |
| % | root |
| 127.0.0.1 | root |
| (my ip) | root |
| ::1 | root |
| ip-(my ip) | |
| ip-(my ip) | root |
| localhost | |
| localhost | root |
+----------------+------+
php - I am connecting using "username" as "root", "host" as "localhost" and "port" as 3306
Inbound security group
Outbound security group
Table names in insert query are case sensitive when deployed in aws RDS mysql. So, make sure to have same table names i.e. same case in insert query and in database. I hope this will work.
Related
I have a 2 nodes mariadb cluster with one maxscale load balancer.
maxscale blocks connection if i want to connect directly to a database: so for example:
mysql -h 35.300.208.100 -u finn -p works and if i then do a USE test i can do everything with the database "test". so the rights are correct.
but if a do a mysql -h 35.300.208.100 -u finn -p test i get the error:
ERROR 1045 (28000): Access denied for user 'finn'#'188.68.43.150' (using password: YES) to database 'test'
So if i do the same on the nodes with localhost, everything works fine.
This is my maxscale.cnf
Most of the time you will receive ERROR 1045 (28000): Access denied when the grants on the database do not contain matching grants for both the client IP and the MaxScale IP.
The usual way of solving this is to:
Execute SHOW GRANTS on the database from the client server
Execute SHOW GRANTS on the database from the MaxScale server
Compare the output of the two queries and make sure they are identical
This is usually enough to spot any problems with grants in the database.
Another way to resolve these sorts of errors is to execute the query that MaxScale uses to load the database users. The exact SQL for these queries can be found on the MaxScale wiki on GitHub. For MaxScale 2.1 and newer, this would be:
SELECT u.user, u.host, d.db, u.select_priv, u.password
FROM mysql.user AS u LEFT JOIN mysql.db AS d
ON (u.user = d.user AND u.host = d.host)
UNION
SELECT u.user, u.host, t.db, u.select_priv, u.password
FROM mysql.user AS u LEFT JOIN mysql.tables_priv AS t
ON (u.user = t.user AND u.host = t.host);
This should return a result set containing the authentication data that MaxScale uses. Here's an example of what the query can return:
+---------------+-----------+------+-------------+-------------------------------------------+
| user | host | db | select_priv | password |
+---------------+-----------+------+-------------+-------------------------------------------+
| root | localhost | NULL | Y | |
| maxuser | 127.0.0.1 | NULL | Y | *5EDBD32E469DAE0CE10E6999C3899DEFCB9F12E0 |
| root | % | NULL | Y | |
| maxuser | % | NULL | Y | *5EDBD32E469DAE0CE10E6999C3899DEFCB9F12E0 |
| skysql | 127.0.0.1 | NULL | Y | *85058F5DEAD82AE3507664C2C11BDA7B1827B80D |
| skysql | % | NULL | Y | *85058F5DEAD82AE3507664C2C11BDA7B1827B80D |
| test | % | NULL | Y | *94BDCEBE19083CE2A1F959FD02F964C7AF4CFC29 |
| stackoverflow | % | test | N | *5635C63172887A7D7C0828876228A5E4DC523969 |
| stackoverflow | % | NULL | N | *5635C63172887A7D7C0828876228A5E4DC523969 |
+---------------+-----------+------+-------------+-------------------------------------------+
The select_priv tells whether the user is allowed to connect with any default database. If it is set to N, then the value in the db column is the only database that the client is allowed to use. As we can see from the example result, the 'stackoverflow'#'%' user is either allowed to connect without a default database or with the test default database.
The error is 1045. But my username and password are correct.
I am connecting as fcapdi from 192.168.0.18 (to 192.168.0.240:3306)
My users table
MariaDB [(none)]> SELECT User,Host FROM mysql.user;
+--------+-----------+
| User | Host |
+--------+-----------+
| dba | % |
| fcapdi | % |
| root | 127.0.0.1 |
| root | ::1 |
| | localhost |
| root | localhost |
| | tester |
| root | tester |
+--------+-----------+
When I login with phpMyAdmin with the root account I receive
#1045 - Access denied for user 'root'#'localhost' (using password: YES)
But my account dba can login fine. What is going on?
Also I guess I should note the MySQL instance is sitting on a server that has 2 NIC's and sits on 2 (internal) networks. One is a local domain 192.168.0/24 the other is a larger domain 10.228./16.
I can login via the fcapdi account from the 10.228./16 network. But not from the 192.168.0./24 network.
Execute:
GRANT ALL ON
your_database_schema_name.* to
'fcapdi'#'192.168.0.18' IDENTIFIED BY 'your_connection_password';
as user with GRANT privileges on the server and try to connect.
As an aside question under comments
SET PASSWORD FOR 'root'#'localhost' = PASSWORD('newPass123^');
SET PASSWORD FOR 'root'#'127.0.0.1' = PASSWORD('newPass123^');
SET PASSWORD FOR 'root'#'etc_etc' = PASSWORD('newPass123^');
you can also do it in a single update statement but it depends on your mysql version
create user 'joe1'#'localhost' identified by 'blah';
create user 'joe1'#'127.0.0.1' identified by 'afadfafsdblah2';
create user 'joe1'#'%' identified by 'djdjdjjdjdd';;
select user,host,password from mysql.user where user='joe1';
+------+-----------+-------------------------------------------+
| user | host | password |
+------+-----------+-------------------------------------------+
| joe1 | localhost | *0380BEA27363E56C37F0BFDA438F429080848051 |
| joe1 | % | *7BEAF25E9BDFBDEF5A9B9E4A37023721B668FA51 |
| joe1 | 127.0.0.1 | *5CD978E569B31B1558E5C1D0972E6E02516893BF |
+------+-----------+-------------------------------------------+
update mysql.user set password=PASSWORD('nEW_COMMon_password762') where user='joe1';
-- 3 rows updated
select user,host,password from mysql.user where user='joe1';
+------+-----------+-------------------------------------------+
| user | host | password |
+------+-----------+-------------------------------------------+
| joe1 | localhost | *A248B352CE5BF750A11AA9BA253B5F191C721D1A |
| joe1 | % | *A248B352CE5BF750A11AA9BA253B5F191C721D1A |
| joe1 | 127.0.0.1 | *A248B352CE5BF750A11AA9BA253B5F191C721D1A |
+------+-----------+-------------------------------------------+
For Mysql 5.7 it is not a column named password. Instead do it against authentication_string
Cleanup:
drop user 'joe1'#'%';
drop user 'joe1'#'127.0.0.1';
drop user 'joe1'#'localhost';
Was recently managing my MySQL (5.5.41) on Linux machine and decided to remove/merge MySQL initially created root users.
Quoting MySQL 5.5 documentation (also nice article here)
On Unix, each root account permits connections from the local host. Connections can be made by specifying the host name localhost, the IP address 127.0.0.1, the IPv6 address ::1, or the actual host name or IP address.
The user table is as follows
+-----------+------------------+-------------------------------------------+
| Host | User | Password |
+-----------+------------------+-------------------------------------------+
| localhost | root | *ABC... |
| lamp | root | |
| 127.0.0.1 | root | *ABC... |
| ::1 | root | |
| localhost | john | *EFG... |
| lamp | john | |
| 127.0.0.1 | john | *EFG... |
| ::1 | john | |
+-----------+------------------+-------------------------------------------+
It is also set to listen only to localhost bind-address = 127.0.0.1. The question is
What could be the possible downfalls of merging multiple root users to a single one and using % wildcard as Host ?
Some of the passwords are blank thus not required to login. If % is used and password is set some users (lamp, IPv6 ::1) would not be able to login. Should this be avoided?
What could be the best pracice - to create a new user basing on initial create (127.0.0.1, ::1, localhost) or to stick with the % wildcard?
First off, i'd suggest you avoid using % wildcard (if it's not strictly necessary). If your users connect to the database from the same host the mysql server is running on, my advice is to use 127.0.0.1
All best practices point out that no-password login should be disabled.
As for IPv6, there's no point in having that user if you're not using it.
I'd suggest you read this http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips
Hi so I am trying to set up my mysql server to accept remote connections from all hostnames by using a % sign in the place of hostname. This however still will not let me connect. My MySQL user table is as follows:
mysql> select host,user from user;
+----------------+------------------+
| host | user |
+----------------+------------------+
| % | guest |
| 127.0.0.1 | root |
| 197.87.180.*** | guest |
| ::1 | root |
| localhost | |
| localhost | debian-sys-maint |
| localhost | root |
| raspberrypi | |
| raspberrypi | root |
+----------------+------------------+
I am able to connect to the server using the username guest from my remote computer with IP address 197.87.180.* but any other IP it gives me the error Access denied for user 'guest'#'197.87..' (using password: YES)
Anyone know the reason for this or what I am doing wrong?
Verify the privileges for guest#'%' with the following:
show grants for 'guest'#'%';
Also, user guest can have a different password for host 197.87.180.*** and another password for host %.
You can verify if the password is the same for both instances of guest user by executing the following query: select host,user,password from mysql.user;
If they don't have the same password, you can change it by executing the following: set password for guest#'%' = password('newPwd');
Cheers,
JF
I just set up mysql my Yosemite by following the directions here:
http://coolestguidesontheplanet.com/get-apache-mysql-php-phpmyadmin-working-osx-10-10-yosemite/
I tried to set the password for root with the mysqladmin command. The result is that now I can log in mysql with the new password or no password. I think it's because one root user (root#localhost) has no password and the other root user has the new passwor.
Should I drop any root users here? I don't understand why 2 root users exist for both localhost and macbook-pro.local.
+------+-------------------+
| User | Host |
+------+-------------------+
| root | 127.0.0.1 |
| root | ::1 |
| | localhost |
| root | localhost |
| | macbook-pro.local |
| root | macbook-pro.local |
+------+-------------------+
So I got another representation by add the password field:
mysql> select User,Host,password from mysql.user;
+------+-------------------+-------------------------------------------+
| User | Host | password |
+------+-------------------+-------------------------------------------+
| root | localhost | *xxx |
| root | macbook-pro.local | |
| root | 127.0.0.1 | |
| root | ::1 | |
| | localhost | |
| | macbook-pro.local | |
+------+-------------------+-------------------------------------------+
So this made me understand that there are users with empty strings and I guess there's no duplicate after all. But then how do I NOT let users log in with just:
mysql -u root
Set password for all root user:
SET PASSWORD FOR 'root'#'localhost' = PASSWORD('cleartext password');
SET PASSWORD FOR 'root'#'macbook-pro.local' = PASSWORD('cleartext password');
SET PASSWORD FOR 'root'#'127.0.0.1' = PASSWORD('cleartext password');
SET PASSWORD FOR 'root'#'::1' = PASSWORD('cleartext password');
And if you don't want any user can log into your mysql without username and password, drop any user from the list:
DROP USER ''#'localhost';
DROP USER ''#'macbook-pro.local';
Note that '' (blank) user is any user. If you don't set a password for them, any user(human, machine) can log into your mysql with any (means anything,any word,any phrase) as username without a password.
But, your 2 blank users here is used by mysql (itself) during installation of mysql service, and it doesn't have granted access. If you have installed mysql service, you can safely drop them.
see reference1
see reference2