I found my posgresql database server is not asking password for user postgres when remote connecting through pgadmin. I mean this is when I connect to remote database server from my local computer through pgAdmin.
I did add a password in psql, ALTER USER postgres PASSWORD 'mypassword'.
This is my pg_hba.config file:
/usr/local/pgsql/bin/psql -qAt -c "show hba_file" | xargs grep -v -E '^[[:space:]]*#'
local all all trust
host all all 127.0.0.1/32 md5
host all all 0.0.0.0/0 md5
host all all ::1/128 md5
So, I do not quite understand what is happening here.
Can anyone help with this?
Thanks a lot.
UPDATE:
If i change:
local all all trust
to
local all all md5
Now, local connections (via SSH) will be asked for password ( wasn't asking for password before.) but remote connections will still connect without a password.
Acutally, I tried connecting to this database server by a rails appliaction from another server, without a password, and the rails server started without a problem.
PUTTING RESULT HERE FOR THE CONVENIENCE
The real reason of this issue was the .pgpass file. Mac stored the password locally in the .pgpass file under user home folder. Then every time when user try to login without a password, PostgreSQL will send the password for user.
Official doc here
Thanks for all the comments and answers ppl!
But the real reason of this issue was the .pgpass file. My mac stored the password locally in the .pgpass file under my user home folder. Then every time when i try to login without a password, PostgreSQL will send the password for me.
So that was the issue i was having....
Thanks for all the reply and the comments again!
For more details can refer to here
Reading the documentation at Postgresql.org
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
I would suggest that you change the user field with the names of the few users allowed to connect remotely:
host all john,charles 0.0.0.0/0 scram-sha-256
host all john,charles ::1/128 scram-sha-256
Further, for security reasons, I would advice that you look into using hostssl and also that you specify the name of the database(s) that can be accessed remotely:
hostsll webapp123 john,charles 0.0.0.0/0 scram-sha-256
And if the remote access is only from specific computers, specify their static IP addresses (if DHCP is used, use a mask accordingly.)
hostsll webapp123 john,charles 1.2.3.4/32 scram-sha-256
This way you only compromise database webapp123, to what users john and charles can do, and only from computer 1.2.3.4.
As mentioned in the documentation, you can have any number of entries, so if you want to add a test server (i.e. your server at home) then you can add one line so it looks like this:
hostsll webapp123 john,charles 1.2.3.4/32 scram-sha-256
hostsll webapp123 henry home-ip/32 scram-sha-256
By not specifying the users, you probably allow any user, including those without passwords and one of them is selected and it works...
Of course, I would strongly advice that you do not name a user who has administration rights in your database unless you also specify his static IP address.
Related
Hi I am new in postgresql.But I have background of sql server.I try to understand security concept of postgres.I use windows 10 and I want to restrict postgres user's login without password.I searched for this and as far as i understand this can be achieved in pg_hba.config.I changed from
host all all 127.0.0.1/32 trust
to
host all all 127.0.0.1/32 md5
and restarted postgresql service.But still postgresql user can login without password or with wrong password.Password validation does not seem to work.
When I try to login from another machine.Password validation works.
Because
host all all 0.0.0.0/0 md5
in pg_hba.config works.
Why Does not it work in localhost for postgres user? How can i achieve this ?
pg_hba.config's content
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# IPv4 local & remote 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
By the way I am using postgresql 11 version.
Eventually I solved this problem.As I say,I use windows 10.When I searched for this problem deeply,I found Postgresql user can login without password or with wrong password in same machine even if I switch from trust to md5 in pg_hba.conf post.This post contains a comment that is
"Looks like I had a password set over here which was causing problems, C:\Users*****\AppData\Roaming/postgresql/pgpass.conf All sorted now, thanks!".
When I look pgpass.conf in this directory and empty this file,it works as I want.
As a result,If we make md5 authentication and want to force password in command promt,we have to empty this file.As postgresql document says in https://www.postgresql.org/docs/9.1/libpq-pgpass.html
if a connection requires password like in md5 authentication,this pgpass.conf is used implicitly.So If we want more security,we must realize this file and empty it.
I'm struggling to get Rails up and running through Windows Bash - for some reason, PostgreSQL is requiring passwords for all TCP/IP connections. It does not prompt for a password when connecting through a unix socket. Ideally my environment would never require a password.
All the advice I can find on this issue points to modifying the pg_hba.conf file. I've edited mine accordingly - there's only one (v9.5). I've reloaded the config via select pg_reload_conf(); and restarted the service to no avail.
# Database administrative login by Unix domain socket
local all postgres trust
# TYPE DATABASE USER ADDRESS METHOD
# "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
I've tried to remove the password from the default "postgres" account, but it still requires the password "root" when I try to connect via $ psql -h localhost -U postgres. When I supply no password, I get psql: fe_sendauth: no password supplied and the prompt terminates.
I've created a new role, root, with no password. This has the same behavior, except the password "root" doesn't work - I'm not sure what password it expects, but it does expect one.
Little lost on what to do next. Everything I can find online points to modifying the pg_hba.conf file to look similar to what I have. I've tried uninstalling/reinstalling postgresql packages, but ran into the same problem. Any ideas?
I have Postgresql server 8.2 running on a Windows server. I am trying to reset the root postgres account password and just not having any luck. I have so far done the following:
Edited pg_hba.conf to allow:
local all all trust
I then restarted the postgres server so changes could be applied.
Then I opened command prompt and change directory to the bin folder of the postgres installation folder that has all the postgres .exe files.
From what I understand I am supposed to type the following:
psql -U postgres
And at this point it should let me in and should type:
ALTER USER postgres with password 'newpassword';
However, it keeps prompting me for password for user postgres:
And it just does not seem to be working. So from my understanding it seems that the the trust local rule in the pg_hba.conf is not really working correctly.
Update
My pg_hba.conf file only has the following uncommented tags in it:
host all all 127.0.0.1/32 trust
local all all trust
host all all ::1/128 md5
You seem to be asking to change the user on the operating system password. The Postgres user is a user on the the operating system.
Plus you are locked out due to the security hierarchy in Host Based Authentication (HBA)
host all all 127.0.0.1/32 trust
local all all trust
-> host all all ::1/128 md5 <-
NB Loopback Address - ::1/128
::1/128 is the loopback address of the local host which is the equivalent of the 127.0.0.1 in IPv4.
If the postgres user password (as in operating system user) is not set, the postgresq user password is stored
%APPDATA%\postgresql\pgpass.conf
Ref Location of postgresql default user password if not set
On Unix systems, the permissions on .pgpass must disallow any access to world or group; achieve this by the command chmod 0600 ~/.pgpass. If the permissions are less strict than this, the file will be ignored. On Microsoft Windows, it is assumed that the file is stored in a directory that is secure, so no special permissions check is made.
You could update you Host Based Authentication (HBA) file and if you wanted to; change the password for the postgres user on the operating system or windows Then everything should be fine from psql
Hope this helps
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'm trying to register new server in pgadmin3 with following settings:
Name: postgres
Host: localhost
Username: postgres
Password: <password which works for psql>
Service: empty or postgres
But it shows error:
FATAL: Ident authentification failed for user "postgres"
I've restarted postgresql service, but to no avail.
Contents of /var/lib/pgsql/data/pg_hba.conf:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "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 ident
EDIT: Tools -> Server Configuration -> pg_hba.conf is greyed out.
It looks like PgAdmin-III is probably connecting over IPv6 by default, so it's using the ident line that matches the IPv6 address for localhost, ::1/128.
If you want to use password authentication, you probably want:
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
I'm not sure why you have the unix domain socket line set to trust, but that's probably OK if it's just a development machine, so leave it unchanged. It's really much safer to have it as ident (if you want the unix user to have to be the same as the Pg user) or md5 (for password auth on local unix sockets) though.
You'll need to edit pg_hba.conf directly in a text editor if PgAdmin-III doesn't have permissions to edit it. You could run PgAdmin-III as user postgres via sudo, but it's way safer (and probably easier) to just use nano or a similar command-line text editor to modify pg_hba.conf.
The password works for psql because psql will, unless told otherwise, connect over a unix domain socket, and you have that set to trust. You'll probably find you could give any password to psql and it'll still work, because it's never being asked to actually give the password, it's just being automatically trusted.
Yes this type of error is seen by every newbie user to pgadmin.
I have found this solution and it worked for me.
sudo -u postgres psql
This will ask for your system password and then you will get the postgres prompt.
and then in psql type below command to change the password.
\password
now enter the new password and re-enter it.
PostGreSQL Account Debugging Steps (Linux Specific):
Make sure you actually have it installed (not just the client, the server too).
Make sure it is running.
Make sure you know where this is - usually in /var/lib/pgsql/data - however this could be anywhere - /var/lib/pgsql/unrelated-instance. Check your postgres process to see which directory (-D argument) this is.
Modify the pg_hba.conf file in the directory from the last step. I have no idea why this step isn't in the postgres documentation.
The specific configuration has been covered in e.g. Jay and Craig Ringer's answer. Make sure to configure both IPV4 and IPV6.
Restart the server.
Test that your configuration worked. Repeat 5-7 until you can login successfully.
Important Don't stop! Now you should configure a more secure password option - postgres may be fine for doing quick local setup, but you want to be using a more secure, configurable authentication mechanism, like LDAP, Kerberos, or GSSAPI. Additionally, you want to make sure you have SSL turned on.