For a system that I am using, I run into the problem pasted on the title when I try to drop a database and recreate it. More specifically, this is the exact problem that I am facing:
Couldn't drop staging_databse : #<PG::ConnectionBad: FATAL: no pg_hba.conf entry for host xxx.xx.xxxx.xxx, user "ruby", database "postgres", SSL off
I've done some research regarding this problem and it seems that the solution is simply to turn on SSL. I've consulted Postgresql Documentation on pg_hba.conf but I'm unable to find this configuration file.
I typed in locate postgresql and I noticed that there is a postgresql-client-9.2 installed on the system. From what I have determined, I won't find this pg_hba.conf file because the client doesn't have it. I've also looked for the postgresql.conf file on SSL according to the official documentation but this file is not included either.
Finally, the documentation shows me this configuration option of the pgsql 9.2 client shown below:
libpq reads the system-wide OpenSSL configuration file. By default,
this file is named openssl.cnf and is located in the directory reported by
openssl version -d. This default can be overridden by setting environment
variable OPENSSL_CONF to the name of the desired configuration file.
However, this too isn't in my system. I've run the linux find command and this file doesn't seem to be there. I've run out of leagues and I have a sneaking suspicion that I am overlooking something very simple. Is there any other leads I can go on? Thanks.
Based on this message and the rest of the context:
FATAL: no pg_hba.conf entry for host xxx.xx.xxxx.xxx, user "ruby", database "postgres", SSL off
It looks plausible that:
you're connecting to a remote PostgreSQL instance which you don't administrate because you're acting as developer, not admin.
the db management layer tries to connect to the database named postgres in order to drop another database (staging_database) . It's necessary indeed because we can't drop a database when we're connected to it (in fact, a database can't be dropped when anyone is connected to it).
the admin policy established by the remote pg_hba.conf is such that your login and IP address together are not allowed to connect to the database named postgres
These facts combined together imply that you're missing the necessary rights to drop your database, even if indirectly.
At this point you want to submit the problem to the admin responsible for that PostgreSQL server.
Related
I connect to my PostgreSQL databases (which run on AWS EC2 instances) using certificate authentication (and not passwords). An example of a psql command I would use to connect to one of my databases is:
psql "host=<AWS EC2 instance> user=<db user> sslcert=<path to .crt> sslkey=<path to .key> sslrootcert=<path to .crt> sslmode=require dbname=<db name>"
I would like to be able to connect Tableau Desktop to one of my databases. The standard PostgreSQL connector does not allow me to specify which SSL certs to use (but it does have a Require SSL checkbox - which I think is for encryption not authentication).
So I have tried to use the ODBC connector. I make the following entries:
Connect Using
Driver: PostgreSQL Unicode
Connection Attributes
Server: <AWS EC2 instance>
Port: 5432
Database: <db name>
Username: <db user>
String Extras: sslcert=<path to .crt>; sslkey=<path to .key>; sslrootcert=<path to .crt>; sslmode=require
By much trial and error I think the String Extras require a semicolon as a delimiter, but I still cannot connect. I get the error message:
An error occurred while communicating with Other Databases (ODBC).
Unable to connect to the server. Check that the server is running and that you have access privileges to the requested database.
FATAL: connection requires a valid client certificate
Generic ODBC requires additional configuration. The driver and DSN (data source name) must be installed and configured to match the connection.
Unable to connect to the server "<AWS EC2 instance>" using the driver "PostgreSQL Unicode". Check that the server is running and that you have access privileges to the requested database.
I would be really grateful to hear from anyone who has connected Tableau Desktop to PostgreSQL using certificate authentication and could tell me what I’m doing wrong. Cheers!
I managed to fix this myself, and just in case there's someone out there who might be vaguely interested I'll go through the salient features:
1. Created a DSN (Data Store Name)
This made testing much easier rather than constantly retyping details into dialog boxes.
Rather than create manually I used this: http://www.odbcmanager.net/
On Mac OS I had to run it as sudo from the terminal or it wouldn't create anything.
I created a User DSN, which on my Mac have details stored in /Users/<user name>/.odbc.ini
It picked up the PostgreSQL Unicode driver that I'd previously installed. On Mac OS you might need to do brew install brew install psqlodbc and/or brew install unixodbc
Most of the configuration was specified by adding key/value pairs e.g. DBNAME <db name>
Set SSLMODE verify-ca (changed from require to make behaviour specific - psql assumes verify-ca/verify-full if SSL certs are supplied)
The cert paths are set with key Pqopt, value sslcert=<path to .crt> sslkey=<path to .key> sslrootcert=<path to .crt>. Must be lower case and only spaces between entries!
Here's what it added to my user's odbc.ini file:
[<DSN name>]
Driver = <path to driver, this was mine /usr/local/lib/psqlodbcw.so>
Description = <description>
SSLMODE = verify-ca
HOST = <host>
DBNAME = <database>
PORT = 5432
UID = <db user>
Pqopt = sslcert=<path to .crt> sslkey=<path to .key> sslrootcert=<path to .crt>
2. Tableau Desktop Connection
Select Other Database (ODBC) connector.
Select the DSN you created previously (it should be automatically picked up), it will automatically populate host, port, db and user fields, then click Sign In.
Once signed in behaviour was slightly different to the dedicated PostgreSQL connector. Tables did not appear on left-hand side initially. But they are accessible - they can all be displayed by clicking on the 'contains' radio button and searching with a blank name.
Hope this helps. Let me know if you've got any questions.
It has been working fine for last several months; and suddenly started noticing this error in application,
FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user "postgres", database "prod", SSL off
pg_hba.conf has,
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 0.0.0.0/0 md5
postgresql.conf has,
listen_addresses = '*'
Both file have not been touched/changed for many months.
Has anybody faced similar issue in a running environment ?
I have gone through several connection related issues on stoackoverflow; but they all point to one of these two files being misconfigured. Thats not the issue in this case.
The root cause is found and fixed.
This is what happened (for the benefit of those who might encounter such a strange issue)
Three mysterious entires were found in pg_hba.conf, right at the top of the file
These had reject method configured for user postgres, pgsql & pgdbadm
None of our team members added them
Because these were right at the top, even before "# PostgreSQL Client Authentication Configuration File...." comment starts, we couldn't notice it.
I am still not sure, how these appeared there
It might be some upgrade issue - but we haven't updated Postgres
It might be a partially successful hacking attempt - still investigating this
But to be on safer side, we have changed server credentials and looking into other hardening methods.
It just might save someone a sleepless night, if such an issue occurs, in a perfectly running environment.
I got the same issue. It is a hack. The same thing is described here:
https://dba.stackexchange.com/questions/215834/postgres-9-6-10-pg-hba-conf-altered
I got a new admin postgres user "pgdbadm", which could not be deleted because 3 objects in the template1 database depended on it. After restoring the template1 db from template0 I managed to drop the user.
There were two new rules on the top of the pg_hba.conf file:
host all postgres 0.0.0.0/0 reject
host all pgdbadm 0.0.0.0/0 md5
The rest of the file was the same.
I managed to replicate the hack with no shell access at all by doing the following in pgAdmin 4:
-- creating a new table
create table test(a text);
-- inserting the contents of pg_hba.conf into the table
copy test from '/var/lib/pgsql/data/pg_hba.conf';
-- overwriting the pg_hba.conf file with the contents from the table prepended with one random rule (just to test it)
copy (select 'host all all 127.0.0.1/32 md5' union all select * from test) TO '/var/lib/pgsql/data/pg_hba.conf';
-- cleanup
drop table a;
-- reloading the server config
select pg_reload_conf();
Of course, this was only possible because postgres was set up on an AWS EC2 instance with all ports open, default postgres user, default port, a stupid super-easy to guess password: "asd123". The security logs in the instance were full of attempts to connect on various ports, with various usernames, etc, so it most probably was a random attack.
I am installing postgres along side a intranet application. The data folder of postgres can be accessed by the user. I have seen here how one can reset the postgres user password and thus compromising data security.
Am I correct in understanding pg_hba.conf is data specific?
Is it possible to lock down modifications to pg_hba.conf or hard code the configuration somewhere so that one cant follow the steps described to the question linked above?
I have a Cloud66 hosted web app and Postgres database (on a dedicated server)
I'd like to connect to the Postgres DB via PGAdmin3 but I have been unable to configure Postgres to accept my connection.
I have added the following line to pg_hba.conf
host all all 86.161.230.162/32 md5
I have checked that postgresql.conf has the following setting:
listen_addresses = '*'
Any ideas?
The doubt in my mind is - Am I editing the correct version of these files? They took me a while to find and now I'm wondering if maybe there not the correct versions. These files are located in the directory
./usr/local/pgsql/data/
Advice/guidance all appreciated.
School boy error.
Of course. Firewall!
Doh.
I am working on an open source application that has PostgreSQL as its default DBMS. Now when I install it on my system, its configuration is so that PostgreSQL also gets installed with it.
My problem is with getting access to the installed PostgreSQL database. The database that gets created during installation is named iviewdb.
I read at many forums that the default superuser is postgres, but when I try to get access to the database using this username through a command prompt, it prompts me for password that I don't have.
I wanted to know from where in the PostgreSQL installation directory
the default username and password with the port number to access the database is stored. I have even tried changing the pg_hba.conf file, but that creates a problem with the application and it won't start then.
How can I find the password for this database? I am working in a Windows environment.
The password isn't stored in an easily recoverable manner, and if you change the password, the application may not be able to access the database properly. You may find the password in the application settings or documentation, though.
If you decide to risk changing the postgres user's password, stop the application and PostgreSQL service, and then edit pg_hba.conf. Add (or change if it already exists) a line (if it doesn't exist, add it before any other "host...." lines):
host all all 127.0.0.1/32 trust
And restart the PostgreSQL service. That should give you access from localhost, where you could change the postgres user's password, or add yourself another user with the permissions you want. Then set the pg_hba.conf file back the way it was and restart.
I've encountered this similar problem, and I noticed that the default being set for PostgreSQL upon installation in my case is as follows:
username = postgres
password = ' '