My teammate can't access to my Database on PgAdmin. I have connected the database on IntelliJ.
That's what i see:
That's what my teammate see:
Under postgres>schemas>public
He can only see Student table.
On the file postgresql.conf I already have replaced the line listen_addresses = 'localhost' with listen_addresses= '*'
And on the file pg_hba.conf that's the situation:
Why he cant see all the tables? How can we fix it?
We need that from his pc he can access to my database.
Thanks for help and orry for bad english.
Related
I want to use elephantsql with pgadmin but not able to connect.
Below is the my issue:-"
FATAL: no pg_hba.conf entry for host "169.149.233.33", user "tfndkxmm", database "aaehpcif", SSL on
FATAL: no pg_hba.conf entry for host "169.149.233.33", user "tfndkxmm", database "aaehpcif", SSL off
i am following this instruction : https://www.elephantsql.com/docs/pgadmin.html but keep getting this error.
I had seen similar question on Stackoverflow.But it doesn't solve my problem.
I am also attaching my connection Screenshot here.
Please someone help me to resolve this issue.
Thanks
I created a new postgresql 11 database cluster. I wrote a simple CRUD script using SQLAlchemy to test the connection on localhost and get "user authentication failed" output from python.
I checked the pg_hba.conf file for the new cluster and it shows:
local all ian peer
Already checked pg_authid and pg_shadow which clearly shows md5 password assigned to the db owner "ian." Also, I have checked that the new cluster is running with pg_lsclusters and it shows it running on port 5433. Checked logs after connection attempts and get the following message:
2018-11-16 10:00:59.712 PST [2102] ian#iandb1 DETAIL: User "ian" has no password assigned.
Connection matched pg_hba.conf line 94: "host all all ::1/128 md5"
A little background: I have already connected this script to the default DB cluster owned by postgres. I can connect and perform the CRUD operations fine with the postgres username and password in the connection string.
Any help would be appreciated. I think there is some type of change I need to make, but can't imagine where it needs to happen. Still learning the ropes.
Ok, well I hope this post saves someone else a little frustration, immediately after submitting this question-- which had me stumped for several hours, I found this:
source: link to article
By default, when you create a PostgreSQL cluster, password authentication for the database superuser (“postgres”) is disabled. The simplest and safest way to add a password to the “postgres” user is to connect to the local server using “psql” (see steps #1 and #2 above), then type the “\password” meta command of psql. You will be asked to enter a password and confirm it.
postgres=# \password
Enter new password:
Enter it again:
postgres=#
I substituted my new cluster owner name 'ian' and assigned a password. I ran the script and everything seems to be working fine now. These are the little things new programmers have to struggle through I guess... Thanks to anyone who can add to my explanation here.
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.
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.
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.