I use Ubuntu 14.10 and installed PostgreSQL 9.2 from PostgreSQL official apt repository. (apt.postgresql.org)
When I switched user postgres and try following command, I can successfully login.
$ psql -U postgres dbname -W
Password for user postgres: (Enter Password)
psql (9.2.9)
Type "help" for help.
dbname=#
However, when I specify host value, I cannot login with following error.
$ psql -h localhost -U postgres notel -W
Password for user postgres:
psql: FATAL: password authentication failed for user "postgres"
FATAL: password authentication failed for user "postgres"
I'm trying to connect from Sequelize.js, an ORM for node.js, but I experienced almost the same error message:
Possibly unhandled Error: error: password authentication failed for user "postgres"
Does anyone know how I can solve this problem?
Edit
My pg_hba.conf is as follows:
local all postgres peer
local all all peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
I refered document about pg_hba.conf, but I don't know what's wrong...
Most likely this has to do with the client authentication file: pg_hba.conf.
It holds entries for each host/socket/user/password/database combination.
When you change your host to localhost, you have a different access route than when you connect directly over a Unix socket. You will patch yourself through TCP/IP instead of going "directly". If you open your pg_hba.conf file, you will find a bunch of rules at the end. These rules define which combinations are allowed to access the database.
In your case, look for lines that start with host, which means access through TCP/IP (and thus localhost) as opposed to local which means a Unix socket.
Probably there is a line tucked in there which prevents host connection access, or not via the credentials you think are correct (peer/md5 pitfall, read below).
As you show in your pg_hba.conf file you have local entries with peer authentication and host entries with md5 authentication. If you don't know the difference between the two authentication mechanisms, then that is your culprit at the moment and can cause some serious head-banging (not the Metal kind; the Against-a-wall kind).
Common pitfall
To avoid possible confusion, the difference between peer and md5 is ground for a common pitfall. They both use a user called postgres (when using -U postgres, that is), but the former is actual a Unix user created during installment of your PostgreSQL system, the latter is a database user created inside your PostgreSQL bookkeeping tables.
Always remember, if your setting is peer, use the credentials of the Unix user, if it is md5 use the credentials of the database user.
If no password has been set for the database user postgres, make sure you set one first. Empty passwords are not allowed either.
Extra notes
Always try to make your rules specific, avoid too many all entries for databases and users as this could put your installation wide open.
The first line that fits your access combination will be picked and any subsequent lines will be ignored. Make sure that there is no higher line that overwrites your rule.
Remember to restart your PostgreSQL daemon after changing this file, otherwise the changes won't be picked up.
If you want to do a secure "localhost" login with $ psql -U username dbname -h localhost -W
You need to make sure the user has been setup with an encrypted password and also setup your "pg_hba.conf" correctly to be "samehost".
1.) Create a Secure Login: "$ psql dbname"
ALTER USER username with encrypted password 'your_password';
2.) Modify "pg_hba.conf" as your main "postgres" user
# IPv4 local connections:
host all all samehost md5
3.) Restart your PostgreSQL server
service postgresql restart
If you have any other problems read your PostgreSQL log carefully at "/var/lib/pgsql/data/pg_log/*.log"
sudo nano /etc/postgresql/12/main/postgresql.conf
and set listening address: localhost
sudo nano /etc/postgresql/12/main/pg_hba.conf
IPv4 local connections:
host all all localhost md5
Related
I am having an issue that has been bothering me for some time now. It is with postgres on my mac. I set a password for postgres and I can not remember it for some reason. I have looked up and attempted several different methods for trying to reset the password but none of them are working and I need it fixed as soon as possible.
Here is what my pg_hba.conf file
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
I reset the local all all trust and then restarted my postgres server running
brew services restart postgres
and when i go to try and open postgres on my terminal I get the same password issue:
omars-MacBook-Pro:postgres omarjandali$ psql -U postgres -W -h localhost
Password:
psql: error: could not connect to server: FATAL: password authentication failed for user "postgres"
or
omars-MacBook-Pro:~ omarjandali$ psql -h 127.0.0.1 -U postgres
Password for user postgres:
psql: error: could not connect to server: FATAL: password authentication failed for user "postgres"`
You only configured "local" connections which are using Unix domain sockets. But your psql command line tries to establish a TCP connection (-h ...), which is not configured in your pg_hba.conf.
You need to use host instead of localin pg_hba.conf to allow trusted, non-password connections through TCP.
But that is a really, really bad idea, because that means that as soon as your Mac is visible on the internet, everybody can connect to your Postgres instance and hack it. This isn't a theoretical threat - there have been numerous posts on this site regarding that.
If you want to allow connections without passwords, at least only allow them from "localhost", not from the outside:
# TYPE DATABASE USER ADDRESS METHOD
host all all samehost trust
I've used MySQL for years so I might be naively layering my MySQL expectations on to Posgres, but I am hitting a wall. I created a user, flasktut with LOGIN CREATEDB but when I try to log in, I get
psql: FATAL: Peer authentication failed for user "flasktut" -- I tried resetting the password:
postgres=# ALTER USER flasktut WITH PASSWORD 'zx80xb1';
ALTER ROLE
and I'm still seeing the error. I suspect I'm doing something super obvious wrong here?
I think the simple answer to your question is that there are two parts to logging in, to a Postgres database, and you're considering only one.
Logging into Postgres, has two parts:
The outer security check ensures that certain IP addresses / subnets / local or foreign hosts can be (dis)allowed to even 'reach' the Postgres database. The second aspect to that is that a given combination of user / database is allowed to go through. Importantly, your current setup is probably missing this aspect, and although you've seemingly taken care of the point 2 (below), it doesn't matter, because the login attempts aren't even reaching step 2.
Once the login process gets through the outer check, the Database / User itself should be valid / existing and usable.
The first aspect (above) is controlled by the pg_hba.conf file, and what you need to ensure is that when the database parses through the pg_hba.conf file, the 'first' line that is permissive enough to apply to a given login scenario, is what is accepted as the effective 'rule' for that login attempt.
For e.g.
If logging in locally (without 127.0.0.1 or eth0 etc. IP addresses)
# "local" is for Unix domain socket connections only
local all all trust
Should allow any login process to get through. Once you're able to login, try to restrict and make things more secure (since the above would allow every attempt to go through).
Importantly, subsequent lines although may be more secure / apt they wouldn't apply if a previous line in the configuration file already is considered as a candidate for a login attempt. Also, don't forget to restart / reload Postgres after each change to pg_hba.conf.
If you omit the host name, psql will connect via a Unix-domain socket to a server on the local host, or via TCP/IP to localhost on machines that don't have Unix-domain sockets.
So edit the pg_hba.conf file and add/update the lines:
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
Restart the server for the changes to take effect.
Now run psql -d <your_db> -U flasktut
No password should be asked since we set the method to 'trust' and you should be logged in.
When you feel confident with your postgres skills, you should probably change the 'trust' above to something safer, like 'md5'.
There are two things to consider here.
First, the settings in pg_hba.conf need to allow you to connect to whatever database you are trying to connect to. A typical entry in the file looks like this:
host my_db myself 192.168.1.17/32 md5
host all all 192.168.1.0/24 md5
The first line allows a specific user (myself) from a specific remote client (192.168.1.17/32) to connect to a specific database (my_db) over TCP/IP (host). The second line allows any user to connect to any database on the network 192.168.1.0/24, typical network address for home or a small office. Both need to authenticate with a password (md5). You should add a line like either of the above to allow flasktut to even reach the server for establishing a connection. Note that when you change this file you need to restart the server for the changes to take effect.
The second issue is that your new user flasktut needs to have the permission to connect to whatever database s/he wants to connect to:
GRANT CONNECT ON DATABASE some_db TO flasktut;
And then within that database you have to grant privileges to access the objects, either directly or by granting role flasktut membership in a group role that has the required permissions:
GRANT some_role TO flasktut;
If flasktut is going to have her/his own database, you are probably better off as a superuser impersonating user flasktut to create the database and then letting the real user log in to that database her/himself:
SET SESSION AUTHORIZATION flasktut;
CREATE DATABASE some_db; -- somedb is owned by flasktut
RESET SESSION AUTHORIZATION;
i think you have already used localhost port server,so you can create another database in localhost port server(no need to add server in postgres ,create a db directly from that port server)
or
you can check on settings in pg_hba.conf?
https://help.ubuntu.com/stable/serverguide/postgresql.html
The PostgreSQL authentication system is managed in pg_hba.conf. Multiple authentication mechanisms can be configured depending on how the connection is made, to which database and by which user.
What can be surprising coming from a MySQL background is the default configuration often in place in Linux installations: it is using peer authentication by default for local connections.
Here are the default values on a Debian/Ubuntu system:
# 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
peer looks for the current Linux user running psql (or whatever PostgreSQL client). In this case, password authentication is not used, but it relies on the OS providing the user name. This only works locally, using a Unix socket here (which is the default when you don't specify anything to psql).
md5 will ask for a password, but this is only configured for network connections in this configuration.
As a result, if I create a user and a DB as follows (logged on as postgres):
postgres#mymachine:~$ createuser -S -D -R -P myuser
Enter password for new role:
Enter it again:
postgres#mymachine:~$ createdb -E UTF-8 -O myuser mydb
This will try to connect using a unix socket, and fail because I'm still logged on as postgres, not as myuser (which may or may not even exist on that system):
postgres#mymachine:~$ psql -U myuser mydb
psql: FATAL: Peer authentication failed for user "myuser"
(Had I been logged on as myuser in that Linux shell, it would have worked.)
In contrast, if I explicitly specify I want to connect via the network (albeit 127.0.0.1), I am prompted for the password and I can log on:
postgres#mymachine:~$ psql -U myuser -h 127.0.0.1 mydb
Password for user myuser:
psql (9.1.20)
SSL connection (cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256)
Type "help" for help.
mydb=>
The trust mechanism is one that presents the most security risks, in that it does not check anything, but the connection mode on that line.
For example:
# This will let any local user connect to any DB via the Unix socket
# without any authentication:
local all all trust
# This will let any user connect to any DB via 127.0.0.1
# without any authentication:
host all all 127.0.0.1/32 trust
# And worse (DO NOT USE):
# This will let any user connect to any DB from anywhere
# without any authentication:
host all all 0.0.0.0/0 trust
There are not many cases besides resetting a lost postgres (admin) password where using trust is justified.
As a side note, you say you've used this to change the password in psql:
postgres=# ALTER USER flasktut WITH PASSWORD 'zx80xb1';
ALTER ROLE
This works indeed, but there are a couple of side effects: the password is now likely to be logged in clear in ~/.psql_history, and it may also have been logged on the server side (wherever its logs are sent).
Within psql, it is generally better to use the \password command:
postgres=# \password flasktut
Enter new password:
Enter it again:
This will not leave a trace of the password in clear in the logs or history.
I can't connect to my local Postgresql database on my Linux Fedora setup using an account I've created (alex). I've tried lots of different things including changing the 'method' to md5 and such. Here's a copy of my pg_hba.conf file:
local all all peer
local project alex peer
host all all 127.0.0.1/32 ident
host all all ::1/128 ident
The user 'alex' has login permissions and replication permissions along with a password (encrypted).
psql -U alex -d project -h 127.0.0.1
psql: FATAL: Ident authentication failed for user "alex"
Forcing password input with the '-W' switch causes this to happen:
psql -U alex -d project -h 127.0.0.1 -W
Password for user alex:
psql: FATAL: Ident authentication failed for user "alex"
You're using TCP/IP (-h 127.0.0.1 or -h localhost) so it's using the host lines. The local lines are for unix sockets and do not apply to TCP/IP.
So it's choosing ident authentication, which expects that the connecting user have the same unix user name as the PostgreSQL user they're connecting to. It's also not well supported in modern operating systems. (I personally think that defaulting to ident authentication is effectively a bug).
I suggest using md5 password authentication instead of ident. Remember to reload the configuration to make change take effect.
Alternately, omit the -h 127.0.0.1 to use peer authentication over a unix socket, if your current unix user name matches the name of the PostgreSQL user you wish to connect as.
Fixed it, I guess the higher that the entry is then the higher the priority it is inside the pg_hpa.conf file. I removed the top peer entry, and problem solved.
when i create a new user, but it cannot login the database.
I do that like this:
postgres#Aspire:/home/XXX$ createuser dev
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) y
then create a database:
postgres#Aspire:/home/XXX$ createdb -O dev test_development
after that, I try psql -U dev -W test_development to login, but get the error:
psql: FATAL: Peer authentication failed for user "dev"
I tried to solve the problem but failed.
Try:
psql -U user_name -h 127.0.0.1 -d db_name
where
-U is the database user name
-h is the hostname/IP of the local server, thus avoiding Unix domain sockets
-d is the database name to connect to
This is then evaluated as a "network" connection by Postgresql rather than a Unix domain socket connection, thus not evaluated as a "local" connect as you might see in pg_hba.conf:
local all all peer
Your connection failed because by default psql connects over UNIX sockets using peer authentication, that requires the current UNIX user to have the same user name as psql. So you will have to create the UNIX user dev and then login as dev or use sudo -u dev psql test_development for accessing the database (and psql should not ask for a password).
If you cannot or do not want to create the UNIX user, like if you just want to connect to your database for ad hoc queries, forcing a socket connection using psql --host=localhost --dbname=test_development --username=dev (as pointed out by #meyerson answer) will solve your immediate problem.
But if you intend to force password authentication over Unix sockets instead of the peer method, try changing the following pg_hba.conf* line:
from
# TYPE DATABASE USER ADDRESS METHOD
local all all peer
to
# TYPE DATABASE USER ADDRESS METHOD
local all all md5
peer means it will trust the identity (authenticity) of UNIX user. So not asking for a password.
md5 means it will always ask for a password, and validate it after hashing with MD5.
You can, of course, also create more specific rules for a specific database or user, with some users having peer and others requiring passwords.
After changing pg_hba.conf if PostgreSQL is running you'll need to make it re-read the configuration by reloading (pg_ctl reload) or restarting (sudo service postgresql restart).
* The file pg_hba.conf will most likely be at /etc/postgresql/9.x/main/pg_hba.conf
Edited: Remarks from #Chloe, #JavierEH, #Jonas Eicher, #fccoelho, #Joanis, #Uphill_What comments incorporated into answer.
Peer authentication means that postgres asks the operating system for your login name and uses this for authentication. To login as user "dev" using peer authentication on postgres, you must also be the user "dev" on the operating system.
You can find details to the authentication methods in the Postgresql documentation.
Hint: If no authentication method works anymore, disconnect the server from the network and use method "trust" for "localhost" (and double check that your server is not reachable through the network while method "trust" is enabled).
When you specify:
psql -U user
it connects via UNIX Socket, which by default uses peer authentication, unless specified in pg_hba.conf otherwise.
You can specify:
host database user 127.0.0.1/32 md5
host database user ::1/128 md5
to get TCP/IP connection on loopback interface (both IPv4 and IPv6) for specified database and user.
After changes you have to restart postgres or reload it's configuration.
Restart that should work in modern RHEL/Debian based distros:
service postgresql restart
Reload should work in following way:
pg_ctl reload
but the command may differ depending of PATH configuration - you may have to specify absolute path, which may be different, depending on way the postgres was installed.
Then you can use:
psql -h localhost -U user -d database
to login with that user to specified database over TCP/IP.
md5 stands for encrypted password, while you can also specify password for plain text passwords during authorisation. These 2 options shouldn't be of a great matter as long as database server is only locally accessible, with no network access.
Important note:
Definition order in pg_hba.conf matters - rules are read from top to bottom, like iptables, so you probably want to add proposed rules above the rule:
host all all 127.0.0.1/32 ident
While #flaviodesousa's answer would work, it also makes it mandatory for all users (everyone else) to enter a password.
Sometime it makes sense to keep peer authentication for everyone else, but make an exception for a service user. In that case you would want to add a line to the pg_hba.conf that looks like:
local all some_batch_user md5
I would recommend that you add this line right below the commented header line:
# TYPE DATABASE USER ADDRESS METHOD
local all some_batch_user md5
You will need to restart PostgreSQL using
sudo service postgresql restart
If you're using 9.3, your pg_hba.conf would most likely be:
/etc/postgresql/9.3/main/pg_hba.conf
This works for me when I run into it:
sudo -u username psql
I simply had to add -h localhost
The easiest solution:
CREATE USER dev WITH PASSWORD 'dev';
CREATE DATABASE test_development;
GRANT ALL PRIVILEGES ON DATABASE test_development to dev;
ALTER ROLE dev CREATEROLE CREATEDB;
In my case I was using different port. Default is 5432. I was using 5433. This worked for me:
$ psql -f update_table.sql -d db_name -U db_user_name -h 127.0.0.1 -p 5433
For people in the future seeing this, postgres is in the /usr/lib/postgresql/10/bin on my Ubuntu server.
I added it to the PATH in my .bashrc file, and add this line at the end
PATH=$PATH:/usr/lib/postgresql/10/bin
then on the command line
$> source ./.bashrc
I refreshed my bash environment. Now I can use postgres -D /wherever from any directory
pg_dump -h localhost -U postgres -F c -b -v -f mydb.backup mydb
Try in terminal:
>> psql -U role_name -d database -h hostname.<domain>.com -W
I have installed PostgreSQL and pgAdminIII on my Ubuntu Karmic box.
I am able to use pgAdminIII successfully (i.e. connect/log on), however when I try to login to the server using the same username/pwd on the command line (using psql), I get the error:
psql: FATAL: Ident authentication failed for user "postgres"
Does anyone now how to resolve this issue?
The following steps work for a fresh install of postgres 9.1 on Ubuntu 12.04. (Worked for postgres 9.3.9 on Ubuntu 14.04 too.)
By default, postgres creates a user named 'postgres'. We log in as her, and give her a password.
$ sudo -u postgres psql
\password
Enter password: ...
...
Logout of psql by typing \q or ctrl+d. Then we connect as 'postgres'. The -h localhost part is important: it tells the psql client that we wish to connect using a TCP connection (which is configured to use password authentication), and not by a PEER connection (which does not care about the password).
$ psql -U postgres -h localhost
Did you set the proper settings in pg_hba.conf?
See https://ubuntu.com/server/docs/databases-postgresql how to do it.
Edit the file /etc/postgresql/8.4/main/pg_hba.conf and replace ident or peer by either md5 or trust, depending on whether you want it to ask for a password on your own computer or not.
Then reload the configuration file with:
/etc/init.d/postgresql reload
You're getting this error because you're failing client authentication. Based on the error message, you probably have the default postgres configuration, which sets client authentication method to "IDENT" for all PostgreSQL connections.
You should definitely read section 19.1 Client Authentication in the PostgreSQL manual to better understand the authentication settings available (for each record in pg_hba.conf), but here is the relevant snippet to help with the problem you're having (from the version 9.5 manual):
trust
Allow the connection unconditionally. This method allows anyone that
can connect to the PostgreSQL database server to login as any
PostgreSQL user they wish, without the need for a password or any
other authentication. See Section 19.3.1 for details.
reject
Reject the connection unconditionally. This is useful for "filtering
out" certain hosts from a group, for example a reject line could block
a specific host from connecting, while a later line allows the
remaining hosts in a specific network to connect.
md5
Require the client to supply a double-MD5-hashed password for
authentication. See Section 19.3.2 for details.
password
Require the client to supply an unencrypted password for
authentication. Since the password is sent in clear text over the
network, this should not be used on untrusted networks. See Section
19.3.2 for details.
gss
Use GSSAPI to authenticate the user. This is only available for TCP/IP
connections. See Section 19.3.3 for details.
sspi
Use SSPI to authenticate the user. This is only available on Windows.
See Section 19.3.4 for details.
ident
Obtain the operating system user name of the client by contacting the
ident server on the client and check if it matches the requested
database user name. Ident authentication can only be used on TCP/IP
connections. When specified for local connections, peer authentication
will be used instead. See Section 19.3.5 for details.
peer
Obtain the client's operating system user name from the operating
system and check if it matches the requested database user name. This
is only available for local connections. See Section 19.3.6 for
details.
ldap
Authenticate using an LDAP server. See Section 19.3.7 for details.
radius
Authenticate using a RADIUS server. See Section 19.3.8 for details.
cert
Authenticate using SSL client certificates. See Section 19.3.9 for
details.
pam
Authenticate using the Pluggable Authentication Modules (PAM) service
provided by the operating system. See Section 19.3.10 for details.
So ... to solve the problem you're experiencing, you could do one of the following:
Change the authentication method(s) defined in your pg_hba.conf
file to trust, md5, or password (depending on your security
and simplicity needs) for the local connection records you have
defined in there.
Update pg_ident.conf to map your operating system users to
PostgreSQL users and grant them the corresponding access privileges,
depending on your needs.
Leave the IDENT settings alone and create users in your database for
each operating system user that you want to grant access to. If a
user is already authenticated by the OS and logged in, PostgreSQL
won't require further authentication and will grant access to that
user based on whatever privileges (roles) are assigned to it in the
database. This is the default configuration.
Note: The location of pg_hba.conf and pg_ident.conf is OS dependent.
Simply adding the -h localhost bit was all mine required to work
In case none of the above works for you:
I've done quite a few Postgres installations, but was flummoxed today on a RedHat 6.5 system (installing Postgres 9.3). My typical hba.conf configuration that Aron shows above didn't work. It turned out that my system was using IPV6, and ignoring the IPV4 configuration. Adding the line:
host all all ::1/128 password
allowed me to login successfully.
For fedora26 and postgres9.6
First, log as user root then enter to psql by the following commands
$ su postgres
then
$ psql
in psql find location of hba_file ==> means pg_hba.conf
postgres=# show hba_file ;
hba_file
--------------------------------------
/etc/postgresql/9.6/main/pg_hba.conf
(1 row)
in file pg_hba.conf change user access to this
host all all 127.0.0.1/32 md5
In my case, solution here: (for people who concerned)
login to postgres:
sudo -i -u postgres
psql
ALTER USER postgres WITH PASSWORD 'postgres'; # type your password here
regards
You can set the environment variable PGHOST=localhost:
$ psql -U db_user db_name
psql: FATAL: Peer authentication failed for user "db_user"
$ export PGHOST=localhost
$ psql -U db_user db_name
Password for user mfonline:
Hmmm ...
If you can connect with the username and password in pgAdminIII but you can't connect with psql then those two programs are probably connecting to the database differently.
[If you're connecting to different databases, first try connecting to the same database. See below.]
From PostgreSQL: Documentation: 9.3: psql:
If you omit the host name, psql will connect via a Unix-domain socket to a server on the local host, or via TCP/IP to localhost on machines that don't have Unix-domain sockets.
If you're not running something like psql ... -h host_name ..., and you're running Ubuntu, psql should be connecting via a Unix-domain socket, so PostgreSQL probably isn't configured to allow one of the password authentication methods for the postgres user.
You can test this by running:
sudo -u postgres psql
If the above works, your server is probably configured to use peer authentication for local connections by the postgres user, i.e. asking the OS for your user name to confirm that you're postgres.
So It's Probably Your pg_hba.conf File
The full path of the file will be something like /etc/postgresql/9.3/main/pg_hba.conf. You can view it by, e.g. sudo cat /etc/postgresql/9.3/main/pg_hba.conf | more.
If you're omitting the host name in your psql command, you should be able to connect if you add the following entry to your pg_hba.conf file:
# Connection type Database User IP addresses Method
local all postgres md5
[Commented lines in the pg_hba.conf file start with #.]
If you are including the host name in your psql command, add this entry instead:
# Connection type Database User IP addresses Method
host all postgres 127.0.0.1/32 md5
You need to put the entry before any other entries are matched for your connection via psql. If in doubt about where to put it, just put it before the first un-commented line.
More about pg_hba.conf
From PostgreSQL: Documentation: 9.3: The pg_hba.conf File [bold emphasis mine]:
The first record with a matching connection type, client address, requested database, and user name is used to perform authentication. There is no "fall-through" or "backup": if one record is chosen and the authentication fails, subsequent records are not considered. If no record matches, access is denied.
Note that records are not matched on authentication method. So, if your pg_hba.conf file contains the following entry:
# Connection type Database User IP addresses Method
local all postgres peer
Then you won't be able to connect via:
psql -u postgres
Unless one of these entries is in your pg_hba.conf file above the former entry:
# Connection type Database User IP addresses Method
local all postgres md5
local all postgres password # Unencrypted!
local all all md5
local all all password # Unencrypted!
Out of all the answers above nothing worked for me. I had to manually change the users password in the database and it suddenly worked.
psql -U postgres -d postgres -c "alter user produser with password 'produser';"
I used the following settings:
pg_hba.conf
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 password
# IPv6 local connections:
host all all ::1/128 password
Connection is successful finally for the following command:
psql -U produser -d dbname -h localhost -W
I found that I had to install an identity server, that listens on port 113.
sudo apt-get install pidentd
sudo service postgresql restart
And then ident worked.
The problem is still your pg_hba.conf file. This line: You can found this file in /etc/postgres/varion/main
local all postgres peer
Should be
local all postgres md5
These are brief descriptions of both options according to the official PostgreSQL docs on authentication methods.
Peer authentication
The peer authentication method works by obtaining the client's operating system user name from the kernel and using it as the allowed database user name (with optional user name mapping). This method is only supported on local connections.
Password authentication
The password-based authentication methods are md5 and password. These methods operate similarly except for the way that the password is sent across the connection, namely MD5-hashed and clear-text respectively.
If you are at all concerned about password "sniffing" attacks then md5 is preferred. Plain password should always be avoided if possible. However, md5 cannot be used with the db_user_namespace feature. If the connection is protected by SSL encryption then password can be used safely (though SSL certificate authentication might be a better choice if one is depending on using SSL).
After altering this file, don't forget to restart your PostgreSQL server. If you're on Linux, that would be sudo service postgresql restart.
my solution on PostgreSQL 9.3 on Mac OSX in bash shell was to use sudo to go into the data folder, and then append the necessary lines to the pg_hba.conf file to allow for all users to be trusted and be able to log in. This is what I did:
# in bash_profile edit PGDATA environmental variable
open ~/.bash_profile
# append this line to bash_profile
export PGDATA="/Library/PostgreSQL/9.3/data"
# reload bash_profile
source ~/.bash_profile
# open pg_hba.conf in vim
sudo vi /Library/PostgreSQL/9.3/data/pg_hba.conf
# append these two lines to the end of the pg_hba.conf file
local all all trust
host all all 127.0.0.1/32 trust
# can now login as user in bash
psql -d <db_name> -U <user_name> -W
I've spent more time solving this error that I care to admit.
The order of authentication configuration in pg_hba.conf is relevant in your case I think. The default configuration file includes several lines in a vanilla install. These defaults can match the conditions of your authentication attempts resulting in a failure to authenticate. It fails regardless of additional configuration added at the end of the .conf file.
To check which line of configuration is use make sure to look at the default log file for messages. You might see something like this
LOG: could not connect to Ident server at address "127.0.0.1", port 113: Connection refused
FATAL: Ident authentication failed for user "acme"
DETAIL: Connection matched pg_hba.conf line 82: "host all all 127.0.0.1/32 ident"
It turns out this default line is causing the rejection.
host all all 127.0.0.1/32 ident
try commenting it out.
If you've done all this and it still doesn't work, check the expiry for that user:
Postgres password authentication fails
I had similar problem and I fixed it in pg_hba.conf when removing all ident methods even for IP6 address (in spite I have only IP4 on machine).
host all all 127.0.0.1/32 password
host all all ::1/128 password
#for pgAdmin running at local network
host all all 192.168.0.0/24 md5
One hack around this is to edit pg_hba.conf
sudo vi /etc/postgresql/9.3/main/pg_hba.conf
To temporarily
# Database administrative login by Unix domain socket
local all postgres trust
At this point you are done. For security, then go and
sudo -u postgres psql template1
ALTER USER postgres with encrypted password 'your_password';
then go back and set pg_hba.conf back to
# Database administrative login by Unix domain socket
local all postgres md5
If you are using it on CentOS,you may need to reload postgres after making the above solutions:
systemctl restart postgresql-9.3.service
It related to configuration issue of PostgreSQL installation:
Configure # TYPE DATABASE USER ADDRESS METHOD section in below mentioned conf file
Find and Edit /var/lib/pgsql/10/data/pg_hba.conf or based on your file location to update method(md5). Update entry in the file if not existing for your config by comparing as below:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::1/128 md5
Configure CONNECTIONS AND AUTHENTICATION section in below mentioned conf file
Find and Edit /var/lib/pgsql/10/data/postgresql.conf or based on your file location
Update Listen Address and Port
listen_addresses = '*' // # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
port = 5432 // Set port as 5432
Restart your PostgreSQL:
sudo systemctl restart postgresql-10 # Update service name based on your installation
For Windows if you dont want to edit pb_gba.conf ie leave the method to MD5(default), create a new user, by running this query in Query tool in PGadmin
CREATE USER admin WITH PASSWORD 'secret'
then in cmd
psql "dbname=Main_db host=127.0.0.1 user=admin password=secret port=5432
where dbname is your db in postgresql
I had the same issuse after following this: PostgreSQL setup for Rails development in Ubuntu 12.04
I tried the other answers but all I had to do was in: "config/database.yml"
development:
adapter: postgresql
encoding: unicode
database: (appname)_development
pool: 5
username: (username you granted appname database priviledges to)
password:
I had to reinstall pdAdmin to resolve this issue
brew cask reinstall pgadmin4
I provisioned the username and password via terraform in GCP SQL and the problem was the password was not set properly via terraform so though not a proper fix but just to figure out the exact cause.
I changed the password for the user from GCP console and that worked.
This worked for me :
http://tecadmin.net/fatal-ident-authentication-failed-for-user-postgres/#
local all postgres trust
local all myapp_usr trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
#host all all ::1/128 trust