I have been using Postgres 12 with MD5 as authentication method and have not faced any issues when trying to connect to a database with password. Nor have I faced issues with user authentication when supplying user password.
However, since I have installed Postgres 13 , I have been blocked by this error client password must be a string. This is a fresh installation of Postgres. Please note that there are solutions which talk about how to migrate from MD5 authentication to scram-sha-256 by making changes to postgresql.conf and pg_hba.conf files. But none of them speak about this issue for a fresh installation of Postgres 13.
What should I be looking for to get rid of this error?
Related
I have a RDS PSQL14 database on eu-central-1 and would like to connect this to Quicksight as a new data source.
However, I always get the following error:
sourceErrorCode: GENERIC_SQL_EXCEPTION
sourceErrorMessage: The authentication type 10 is not supported. Check that you have configured the pg_hba.conf file to include the client's IP address or subnet, and that it is using an authentication scheme supported by the driver.
I have no clue how could I edit the pg_hba.conf file. Though I know that the VPC in which the RDS is in would allow the connection.
Most likely this is something with sha256 vs md5 authentication or so I've read in a couple of posts, but I don't know for sure. Please someone educate me :)
This was a huge time waster.
tldr: psql 13 and up uses scram-sha-256 but older version only support md5.
The reason behind this is that AWS Quicksight is using PostgreSQL JDBC driver 42.2.1
If you try to connect this with any of the newer psql versions it will fail due to a change made to the password authentication method used in the more recent versions of PostgreSQL (scram-sha-256). However, the 42.2.x driver only supports connecting via md5 passwords.
How to solve?
1. Downgrade:
If you downgrade to version 12.9 or below the problem should sort itself out.
2. Change Auth to md5:
!! it will affect all users and connections !!
Create a new Parameter group.
Once a new Parameter group is created > Search for password_encryption > Edit parameters
Select md5 (change the "rds.accepted_password_auth_method" parameter to allow md5 + scram which would allow you to create a user with md5 for QuickSight to connect with).
Save changes
Then you can modify your database to use the DB parameter group created in step 1.
Create a new user to be used in the QuickSight authentication with the RDS instance with the necessary permissions.
3. New Quicksight user with session-level md5:
Verify current password_encryption value:
show password_encryption;
Set the session variable of the parameter to 'md5:
set password_encryption = 'md5';
Create a user and assign it the necessary credentials
create user (username) with password '(password)';
grant connect on database (database) to (username);
Use the user to connect from QuickSight and it should be able to connect successfully using the "md5" encryption and not "scram-sha-256".
I'm working on a project with the kosmtik tool together with osm2pgsql to be able to generate data for OPENS STREET MAP directly from my postgres database, and I'm having this connection problem when I make requests to the database, they are being accessed by the file localconfig.js and together with project.mml
Has anyone had a similar problem or worked with this tool to be able to use it in OSM ??
From PostgreSQL authentication method 10 not supported, you can understand that your client cannot authenticate using scram-sha-256, and from POSTGRES_HOST_AUTH_METHOD in https://hub.docker.com/_/postgres, you get that scram-sha-256 is the default auth method when using postgres 14 and later.
So, you can either update the postgresql client you use, or downgrade postgres to v13. You could also choose to disable passwords or use md5 auth method on postgres.
It does looks like kosmtik uses mapnik, which has Unable to connect to Postgresql 14 with scram-sha-256 password hashing · Issue #4283 · mapnik/mapnik.
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.
I am installing geoportal 1.2.4 on CentOS from the command line terminal...during my installation I am receiving a fatal ident error message for my user geoportal. The pg_hba.conf file has been altered to follow my credentials accordingly, yet I am consistently receivng this error for both the default user postgres and my created user geoportal.
I have created a geoportal db with geoportal user with a password. Trust and md5 authentication methods have been explored in this configuration. I have also installed the ident server, with no avail.
I am able to connect to the geoportal db as postgres user. Below is a screen shot of the error which is returned for both the postgres and geoportal user.....
A look at the PostgreSQL user manual would be well advised here, particularly pg_hba.conf and the rest of the client authentication chapter.
You're trying to use ident authentication but the user ID doesn't match or the ident daemon isn't running.
You probably want md5 password authentication instead.
I stopped my db using db2stop force. The started did a backup restarted and after that
i cannot connect to db from the a client anymore i get:
using the command
db2 connect to "dbname" using "user"
SQL30082N Security processing failed
with reason "42" ("ROOT CAPABILITY
REQUIRED"). SQLSTATE=08001
password and username are correct. When im on the server connecting using command
db2 connect to "dbname"
or
db2 connect to "dbnmae" user "user"
or
db2 connect to "dbname" user db2inst1
works just fine.
I m really confused. Any help is much appreciated
Thanks.
What i tried so far :
db2 get dbm cfg | grep -i auth GSS
Plugin for Local Authorization
(LOCAL_GSSPLUGIN) = Server
Connection Authentication
(SRVCON_AUTH) = NOT_SPECIFIED
Database manager authentication
(AUTHENTICATION) = SERVER Cataloging
allowed without authority
(CATALOG_NOAUTH) = NO Trusted client
authentication
(TRUST_CLNTAUTH) = CLIENT Bypass
federated authentication
(FED_NOAUTH) = NO
switched to client but did not using
db2 update dbm cfg using
authentication client
Update:
Despite the age of this question, it would be wonderful to have a solid answer to this question. Hi locojay, how did you manage? :-)
I'm having the SQL30082N reason code 24 issue in my Windows PC, and today we experienced the same issue in an AIX server.
I googled for a couple hours and didn't find but one happy answer, related to having users with the same name both in the server and the client.
IMO it does not apply to me, as I'm running into a VBox that´s isolated from the domain (no network).
My case: I installed DB2 as user db2admin, no security. Then I granted DBADM to VIRTUALUSR01 and gave this user a password.
db2 connect to TheBase
works fine. But
db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword
returns SQL30082N with reason code 24.
Using client authentication is generally a Bad Idea(TM). That's because you now rely on machines that you may not control for authentication. If I wanted to subvert your system, I could create a new user locally, say, db2inst1 or VIRTUALUSR01 or Administrator, with a password I know, and then, use that to wreak havoc on the database. If, however, no one in your organisation has root/administrator authority over their own machines, client authentication can be made to work. But all it takes is someone plugging in their own personal laptop, and your database could be at risk.
Instead, check the permissions of the files. If you've installed as root, ~db2inst1/sqllib/security/db2c[hk]pw (assuming instance ID of db2inst1) should be setuid root. If not, run db2iupdt against your instance (./db2iupdt db2inst1) which should fix the permissions.
If you've installed without root authority ("non-root install"), which I doubt, since you seem to have had this working, you would need to read the DB2 documentation on non-root installations and their limitations - I don't use non-root installs myself, so I'm not so familiar with them. However, there should be a set-root script that you can use to enable setuid root which, of course, you have to run as root.
I had the same problem and solved with the following way.
Problem occurs because of /etc/shadow file. If the user's password hash is created with SHA then DB2 cannot authenticate or authorize that user. You need MD5 for hashing that user's password.
If you are using Fedora or RedHat Linux, first change hashing method of passwords with:
# authconfig –-passalgo md5 –-update
Then drop and recreate the user:
# userdel userName
# useradd userName
# passwd userName
If you are using AIX or any other linux distros, authconfig won't work. So instead of passwd userName, issue this command:
# usermod --password `openssl passwd desiredPassword`
After that, your password hash belonging to userName will be generated with MD5.
Now grant user privilege to that user:
# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName
I hope it works for you too.
Thanks to Honza for his solution
Solutions to specific problem causes described previously in
this message are:
1. Run DB2IUPDT <InstName> to update the instance.
2. Ensure that the username created is valid. Review the DB2
General Naming Rules.
3. Ensure that catalog information is correct.