I want to login to mysql db with another user
I create the user
mysql -u root
create USER 'myuser'#'%' IDENTIFIED BY 'password' REQUIRE SSL; flush privileges;
grant privileges
grant all on *.* to 'myuser'#'%' IDENTIFIED BY 'password'; flush privileges;
but mysql refuse connect and "force" localhost !
mysql -h myhost -p
Enter password:
ERROR 1045 (28000): Access denied for user 'myuser'#'localhost' (using password: YES)
the tcp port 3306 is open
telnet-ssl myshost 3306
Escape character is '^]'.
Y
******-MariaDB...
ss -tulnepona|grep 3306
tcp LISTEN 0 80 *:3306 *:* users:(("mariadbd",pid=13501,fd=20)) uid:27 ino:39020 sk:45 cgroup:unreachable:1 v6only:0 <->
tcp TIME-WAIT 0 0 [::1]:59876 [::1]:3306 timer:(timewait,53sec,0) ino:0 sk:47
why force the localhost and don't connect to remote server?
Server is mariadb on slackware-15, i don't use $HOME/.my.cnf
Solution found, I have to test it from a remote site, not from localsite
Related
I recently tried to login into my MariaDB database via shell and got this error even though I'm 100% sure the password is correct:
mysql -u root -p
ERROR 1045 (28000): Access denied for user 'root'#'localhost' (using password: YES)
I'm running a node.js server that connects to the same database with the same password with no problems...
You don't have privileges to connect to the root mysql user. Simply use sudo:
sudo mysql -u root -p
Enter password that you use on your machine, after that enter password to the root mysql user.
I have a google compute running CentOS 7, and I wrote up a quick test to try and communicate with it over port 9000 (from my home PC) - but I'm unexpectedly getting network errors.
This happens both with my test script (which attempts to send a payload) and even with plink.exe (which I'm just using to check the port availability).
>plink.exe -v -raw -P 9000 <external_IP>
Connecting to <external_IP> port 9000
Failed to connect to <external_IP>: Network error: Connection refused
Network error: Connection refused
FATAL ERROR: Network error: Connection refused
I've added my external IP to googles firewall (https://console.cloud.google.com/networking/firewalls) and set to allow ingress traffic over port 9000 (it's the lowest priority, at 1000)
I also updated firewalld in CentOS to allow TCP traffic over the port:
Redirecting to /bin/systemctl start firewalld.service
[foo#bar ~]$ sudo firewall-cmd --zone=public --add-port=9000/tcp --permanent
success
[foo#bar ~]$ sudo firewall-cmd --reload
success
I've confirmed my listener is running on port 9000
[foo#bar ~]$ netstat -npae | grep 9000
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1000 18381 1201/python3
By default, CentOS 7 doesn't use iptables (just to be sure, I confirmed it wasn't running)
Am I missing something?
NOTE: Actual external IP replaced with <external_IP> placeholder
Update:
If I nmap my listener over port 9000 from the CentOS 7 compute instance over a local IP, like 127.0.0.1 I get some results. Interestingly, if I make the same nmap call over the servers external IP -- nadda. So this has to be a firewall, right?
external call
[foo#bar~]$ nmap <external_IP> -Pn
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-25 00:33 UTC
Nmap scan report for <external_IP>.bc.googleusercontent.com (<external_IP>)
Host is up (0.00043s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
3389/tcp closed ms-wbt-server
Nmap done: 1 IP address (1 host up) scanned in 4.87 seconds
Internal Call
[foo#bar~]$ nmap 127.0.0.1 -Pn
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-25 04:36 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
9000/tcp open cslistener
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
In this case software running on the backend VM must be listening any IP (0.0.0.0 or ::), your's is listening to "127.0.0.1:9000" and it should be "0.0.0.0:9000".
The way to fix that it's to change the service config to listen to 0.0.0.0 instead of 127.0.0.1 .
Cheers.
hi i like to connect through an nginx to an azure sql db to have an single point of access to my network.
Goal is to access to the nginx publicip:1234 which is translated to mydb.database.microsoft.com:1433
I have configured a nginx on centos with stream addon.
config looks like:
stream {
upstream mssql {
server mydb.database.microsoft.com:1433;
server mydb.database.microsoft.com:1433;
}
server {
listen 1234;
proxy_pass mssql;
}
}
The mssql is configured to accept connections from the publicip of the nginx machine as well as has a service endpoint to the vnet where the nginx is connected to.
When i try to connect to the db through the nginx i receive the following error message:
.... connect() to IPOFDB:1433 failed (13: Permission denied) while connecting to upstream, client: MYIP server:0.0.0.0:1234 ...
The only idea why it my fail is that the outgoing ip from nginx is not the publicip which is whitelisted for the db and it does not use the vnet endpoint connection.
any ideas.
Thanks for your help.
Disable SElinux permanently and reboot
or
semanage port -a -t http_port_t -p tcp 1234
I have the following Scenario:
A Master Server where salt-master is installed and a Minion Server where salt-minion is installed in between those two servers there is a Cisco ASA Firewall.
The Firewall Admin told me he has opened both TCP 4505 and 4506 ports from the minion server ==> master server (only one direction)
Still i have problems connecting to the master server. So here comes my question is there a way to find out that the TCP 4505 und 4506 ports are opened? Master and Slave servers do not have iptables installed.
I found the solution at the Salt troubleshooting: https://docs.saltstack.com/en/latest/topics/troubleshooting/minion.html
I'll summarize it here (xx.xx.xx.xx is the master IP)
(if port is not open):
root#minion ~ # nc -v -z xx.xx.xx.xx 4505
salt [xx.xx.xx.xx] 4505 (?) : Connection refused
root#minion ~ # nc -v -z xx.xx.xx.xx 4506
salt [xx.xx.xx.xx] 4506 (?) : Connection refused
(if port is open):
root#minion:~# nc -v -z xx.xx.xx.xx 4505
salt [xx.xx.xx.xx] 4505 (?) open
root#minion:~# nc -v -z xx.xx.xx.xx 4506
salt [xx.xx.xx.xx] 4506 (?) open
I am trying to use dplyr to connect to a remote database, that I usually query through a ssh tunnel.
I first set up a ssh tunnel like the following:
alias tunnel_ncg='ssh -fNg -L 3307:127.0.0.1:3306 mysqluser#myhost mysql5 -h 127.0.0.1:3306 -P 3307 -u mysqluser -p mypassword'
At this point I can access the database by connecting to localhost:3307. For example:
mysql -h '127.0.0.1' -P 3307 -u mysqluser
If I try to access the same database through dplyr, I get an error complaining that it can't connect to the local MySQL socket:
> conDplyr = src_mysql(dbname = "mydb", user = "mysqluser", password = "mypassword", host = "localhost", port=3307)
Error in .local(drv, ...) :
Failed to connect to database: Error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
My understanding is that RMySQL/dplyr are trying to looking for a socket file in the local computer, however they should really be looking for it in the remote server. Is there a way to fix this, or a work-around?
UPDATE:
If I try to connect through dbConnect/RMySQL, the connection works fine:
> dbConnect(dbDriver("MySQL"), user="mysqluser", password="mypassword", dbname="mydb", host="127.0.0.1", port=3307)
<MySQLConnection:0,1>
As silly as it sounds replacing localhost with an IP address (127.0.0.1) solves the problem.
src_mysql(
dbname = "mydb", user = "mysqluser", password = "mypassword",
host = "127.0.0.1", port=3307)
For an explanation take a look at the MySQL documentation:
On Unix, MySQL programs treat the host name localhost specially, in a way that is likely different from what you expect compared to other network-based programs.
For connections to localhost, MySQL programs attempt to connect to the local server by using a Unix socket file. This occurs even if a --port or -P option is given to specify a port number.
To ensure that the client makes a TCP/IP connection to the local server, use --host or -h to specify a host name value of 127.0.0.1, or the IP address or name of the local server.