I was given an old database. The colleague who maintained is long gone and nobody (inculding me) has a clue how to handle it. I am able to use SQL queries to manage the data, but now I need to add a new user with reduced priviliges.
But I am not getting anywhere. The poor documentation the colleague left tells me to ssh into the server and add the new user to pg_hba.conf file. So I did that by doing that and it looks like this now:
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all test1 x.0.0.0/8 md5
host all test2 x.0.0.0/8 md5
host all hft x.0.0.0/8 md5
# IPv6 local connections:
host all all ::1/128 md5
host all test1 x.0.0.0/8 md5
host all test2 x.0.0.0/8 md5
host all hft x.0.0.0/8 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
I can login using the users test1 or test2 without problems: psql -h xxx.xxx.xxx.xxx -U user db. But when I try the same with the new added user hft to the same database, I am getting asked for a password. But I never set a password (which might be the problem?). I restarted the db with /etc/init.d/postgresql restart before trying. But doesn't change anything.
So long story short: I want to add a new user. That user should be able to access the database and use SQL queries from anywhere.
Not sure where I am wrong, as not even the local access for my new user works.
Related
I'm standing up a new application and having some issues with host based authentication. I know there are other posts out there (espec this one) but nothing I try seems to work.
My error:
no pg_hba.conf entry for host "::1", user "root", database "db_name_here", SSL off
My pg_hba.conf file looks like:
# TYPE DATABASE USER ADDRESS METHOD
local all all peer map=usermap
local replication all peer map=usermap
hostssl all all all md5
host replication all all md5
I have a note to myself from the past where I said the following worked:
host db_name_here root ::1 trust
But it doesn't.
I've even tried:
all all all all trust
even that didn't work, same error.
I've read the postgresql docs, and while the helped explain what was going on, (and made me try hostnossl, to no avail) I'm still getting the same error.
Do you see my mistake?
Your pg_hba.conf entry is missing the netmask; a plain IP address is a syntax error. This one should work:
host db_name_here root ::1/128 trust
Don't use trust for anything but tests. As soon as you get that to work, replace it with a real authentication method like scram-sha-256.
Make sure you reload the database with
pg_ctl -D /path/to/datadir reload
and check the log file for errors (that is important, as a syntactically wrong file won't be loaded).
The alternative is to enable SSL on the server side and use it for the local connection.
The fastest way to connect would be via Unix sockets (if you are not on Windows or use the JDBC driver), perhaps that is the best thing to do.
Have you tried allow IPv6 localhost seperately like this
# TYPE DATABASE USER ADDRESS METHOD
host all all ::1/128 trust
Add sslmode=Require; and Trust Server Certificate=true; in your connection string.It will work for sure.
In my case, the DB is hosted on a different server and we get access credentials for the DB server. So, I only had to use sslmode:require while creating the connection string, like this
dbURI := fmt.Sprintf("sslmode=require host=%s port=%s user=%s dbname=%s password=%s", dbHost, dbPort, username, dbName, password)
log.Println("Postgres connection string: " + dbURI)
conn, err := gorm.Open("postgres", dbURI)
return conn
I'm having a trouble which I can't connect to my database using IP Address. It works fine when I access it to my local but the problem is the other PC can't connect to my server. I've been using postgre v11 and navicat v12. Is there any permission to setup in my device in order that the other devices can access to my database? It would be great if anybody could figure out where I am doing something wrong. thank you so much in advance
You have to change the host settings of the database to access it from a foreign IP
I would look at two things if connections from remote hosts are being rejected.
First what is the value of the parameter listen_addresses in the postgresql.conf file? If it is set to:
listen_addresses='localhost'
It will be allow only local loopback connections. Change this (for example to listen on all interfaces) to:
listen_addresses='*'
Next, check the pg_hba.conf file has a rule to allow connections from your remote client. By default PostgreSQL will refuse these remote connections and they must be whitelisted. The following example entry would allow any user to connect to any database from 192.168.1.2 and they must supply the password
host all all 192.168.1.2/32 md5
Check out the official PostgreSQL docs for this at:
https://www.postgresql.org/docs/11/auth-pg-hba-conf.html
I just installed the new version of Elementary OS and I lost the configuration that makes work my Postgresql.
I have an app that works perfectly online with a remote DB on Heroku, but when I run that on my local machine I can't reach the server. I think I miss something in the pg_hba.conf because I have all services up and running and all ports open for the DB. Actually I have this config file
# Database administrative login by Unix domain socket
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all peer
host replication all 127.0.0.1/32 md5
host replication all ::1/128 md5
host all all 0.0.0.0/0 md5
host all all ::/0 md5
I hope you can give me a way to contact my DB. In the last installation, I was able to, but I lost the config file.
Hello and thanks for the replies. I read the docs that says just how to connect to local service or configure a server that runs on a machine. I did all the steps before (just in case): user add, configuration of the local DB, giving admin user to the DB etc.
This line (the last)
host all all ::/0 md5
Is the one the docs say to add, but it is working for DB calls on the same machine.
I take web monitors, scanned ports and whatever I could see on linux system: ports for Postgresql are open, service runs, seems all fine. DB is reachable via PGAdmin, same credentials in the app. App is a NodeJS that calls the DB for an interactive website.
For those reasons I believe that should be a configuration problem. I have also no active firewall, no other rules than the actual config file for postgresql.
As I write the app works perfectly when it is on local or when it is all on the server. I need to have a cross config for development to have quick way to work on the actual online DB and a local copy (editable) of the web app. Or permit more people to develop at same time from different machines.
There is no error, just the app can't go online to get the DB and loops to find it. At last goes timeout.
Last time I had fix this with a similar line, obviously it is not the right form. What I ask is simply a line of config. I am not skilled in server configuration and I don't need to be anyway: once this will be online the server will have already configuration. I don't even care on what SQL type I will work, the app has a parser that makes all SQLs compatible.
I had to restore the system because of a problem, otherwise all was working before and I changed just that line, can't remember how...
Hope this will clear the situation.
Do you think they are getting a kickback from Oracle (the makers of Workbench), or is there a valid reason to consider phpmyadmin to be less secure than (the paid) workbench application?
The main issue using phpmyadmin is related to MySQL users allowed ip's.
For example; Let assume that you have installed MySQL with default configuration and you set 123456 as a password (which is not good). As you know root login are only allowed when source ip is 127.0.0.1 ( default configuration ). In this scenario, your database server will be secure even if 3306 port can be accessible from internet. Because of client have to initiate connection from 127.0.0.1 which is localhost.
If you've installed phpMyAdmin on your server, this source ip protection will be useless. Because hackers will be able to initiate MySQL connection from localhost through PHP/Apache.
In order to keep your database server secure, use SSH Tunneling feature of workbench . Documentation for ssh tunneling can be found here; https://www.namecheap.com/support/knowledgebase/article.aspx/9330/2180/how-to-connect-to-database-using-workbench-mysql-client
I would like to start this discussion about mysqldump security.
With security I'm not speaking about Cron tasks that display password security or password security in any way, instead I'm talink about the security of the command itself.
In my particular case I have setup the command to execute on my home server the cron job with mysqldump and backup my website database on my VPS that I have with 1&1.
So basically the scenario is that my Home PC is backing up remotely the MySQL database on port 3306.
This work correctly but I start making nightmares while sleeping and thinking that maybe could someone listen on port 3306 and get all my data while I'm backing up (with mysqldump) I mean for what I have understanded mysql is not under SSL with port 3306 so anybody could potentially get the backup copy from the database?
I mean it would be possible this scenario:
My Home PC start mysqldump task
My VPS on 1&1 prepare remotely the sql dump
My Home PC receive locally the dump from the remote server
between point 2 and point 3 is possible that someone get a copy of my file?
Thanks in advance for the answers
Marcos
You should not expose port 3306 on your VPS host to the public internet. MySQL's unencrypted port is not secure.
If you're running mysqldump on your VPS host, and only transferring the resulting dump file to your PC, then you can do this securely.
If you can ssh to your VPS, you should be able to use scp too. This gives you the ability to transfer files securely.
Here's a FAQ article about using scp with 1&1. I found this by googling for "1&1 scp":
http://faq.1and1.co.uk/server/root_server/linux_recovery/9.html
If you need to run mysqldump on your Home PC and connect remotely to MySQL on the VPS host, you have options:
Run mysqldump on the PC with SSL connection options.
Open an port-forwarding ssh tunnel, then run mysqldump on the PC connecting to the forwarded port.
Run ssh to invoke mysqldump on the VPS, then capture output. See example in the accepted answer to this question: https://serverfault.com/questions/36467/temporary-ssh-tunnel-for-backup-purposes
Create a VPN and do anything you want because it's all encrypted.
Re your comments of 10/11:
I need to execute the command from home PC to backup the VPS remotely.
I want to ... receive instead the backup file directly so in the VPS should be saved nothing.
Okay, here's what you can do, without exposing port 3306:
$ ssh marcos#192.168.1.3 'mysqldump ...options.. | gzip -c' > ~/dump.sql.gz
Notice the position of quotes in that command. You're executing on the VPS the command: mysqldump ...options.. | gzip -c. The stdout of that command is a gzipped stream of the dump. That stream is returned via ssh, and then > saves the output locally in the shell on your PC.
Re your comment of 10/13:
now I'm storing on the server an open text file that contain the credentials to access the MySQL server. I mean if someone will break into the server it will be able not just to damage the server content but also to damage and stolen MySQL database and informations. Am I right?
If you use MySQL 5.6 you can use the new feature to store connection credentials in a semi-encrypted manner. See http://dev.mysql.com/doc/refman/5.6/en/mysql-config-editor.html
If you use MySQL 5.5 or earlier, then you're right, you should be careful to restrict the file permissions of my.cnf. Mode 600 should be enough (i.e. it's not an executable file).
But if someone breaks into your server, they may have broken in with root access, in which case nothing can restrict what files they read.
MySQL doesn't have enough security to block access if someone gains root access, so it's up to you to use other means to prevent breakins. Firewalls, etc.
Yes it's possible, but you don't mention how you gonna fetch that data. If you use ssh/scp (with dedicated user for dumps, IP filtered, auth based on private key with key password) is acceptable and consider as safe in my opinion. Another fast way is be a more secure is to set up VPN. Any else is paranoid level for personal use.