Backstory:
I've gotten jdbc to connect to postgres using a client cert. In java I set the user in the properties, and the driver looks it up in the keystore and sends it along. All was good.
But I just found out that I won't be getting certs with a CN of pg-user. The certs I'll be getting will have a CN of pg-user.XYZ.foo.com & pg-user.ABC.foo.com. This looks like a job for username maps. Hey they even have regexp, it'll be perfect.
I got unix user root logging in to postgres as pg-user using a username map and local ident authentication using psql -d db -U pg-user. But in that case postgres knows BOTH that the user is root, AND is trying to log in as pg-user.
Problem:
What I can't figure out is how to tell the postgres jdbc driver to grab the cert from the keystore with a CN of pg-user.XYZ.foo.com, but present to postgres as user pg-user. It appears to be the single argument of user that controls both. Does anyone know how to do this?
This page includes a list of the connection options, but it doesn't seem to offer a way to split the user names. The closest I'm seeing is the option to write my own sslfactory, and I'm really hoping to avoid that...
Thanks to #harmic's comment I was able to solve this.
Starting with to following three files:
pg-user.pem which has a CN of pg-user.XYZ.foo.com
pg-user-chain.pem which contains the chain certs
pg-user.private_key which contains the private key for the cert
Then I created the pkcs12 file like this:
cat pg-user.pem pg-user-chain.pem > cert-and-chain.pem
openssl pkcs12 -export -out ssl_cert.p12 -in cert-and-chain.pem -name pg-user -inkey private_key.pem -passout pass:{password here}
After that I declared the user property for the connection to be pg-user, and it worked. In order to test, I altered the regexp in pg_ident to not match, then I could no longer log in, I changed it back and I could.
Related
I am going through the exact same process as the answered question found here (Connect a Google CloudSQL Postgres database to Data Studio), but I am not as advanced a user as most. I am encountering a similar problem to what was mentioned in the above question, and then some:
I have created a client certificate and downloaded the
client-cert.pem, client-key.pem and the server-ca.pem files to my
local machine.
I received the same error when attempting to link
Data Studio to our Google Cloud SQL Postgres Database as a data
source. " Can't reach the host. Please double check your connection parameters. Learn more about database connectors here. "
I tried running the following command " openssl pkcs8 -topk8 -inform PEM -outform DER -in client-key.pem -out client-key.pkcs8 -nocrypt " to change the format of the
client key in our Cloud Shell Project, but I received this error "
pkcs8: Cannot open input file client-key.pem, No such file or
directory ".
I would assume that I should not be running this command from the Cloud Shell Project terminal then. Would anybody know where I should be running this command instead? I can provide any extra material if needed. Thank you in advance - much appreciated.
It sounds like the file doesn't exist location where you are running the command. Did you upload the client-key.pem into Cloud Shell?
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.
I have an old website that I created a folder that's protected with htpasswd. However, it's over a decade old, and I have since forgotten the password. I wish to access the contents of the folder. I'm able to view the directory contents via the control panel, but I'm unable to access the individual protected files.
I have access to the htpasswd file, and it has lines of user:password, where the password seems to be hashed (13 characters, uppercase/lowercase/digits). I tried loading it into John and it detects it as CRYPT, but was unable to crack it even after a few hours. Are there better ways of accessing the files? Given server access, can I reset/remove the password protection? Or, failing that, are there better/faster ways of brute forcing the password hash?
So you have SSH access to the server, but don't remember the values used to generate the passwords stored in the htpasswd file so you can't access them via control panel?
You could just login and rename (disable) the .htaccess file:
$ mv protected_dir/.htaccess protected_dir/.old.htaccess
If you want to crack the old password first read this: https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils to understand the password format.
Then basically you can use John, but you have to take the password file and append the salt to each password.
$ john --wordlist=passwd_salted.txt passwords_to_crack.txt
Good luck!
I'm having troubles to connect an existing heroku database to Google Datastudio. I'm trying to add the connection and I get the following:
Access denied, please check your username and password.
Now, I'm 100% sure that I'm correct on those credentials and the problem comes from somewhere else.
I've tried with different setup, either a free or a paid PSQL instance, nothing works.
I've also setup a dummy account on elephantsql and the connection worked the first time without any issue.
Do you have any idea of the cause of that problem?
Edit:
Just found https://www.en.advertisercommunity.com/t5/Data-Studio/Heroku-Postgres-lt-gt-Google-Data-Studio/m-p/1031729 which is not helpful at the time of writing this post.
Since the February 6, 2018 update, Google DataStudio allows SSL connections with PostgreSQL, which is necessary to connect to a database created via Heroku.
To enable SSL you need to provide client key+cert and server cert, which can be accomplished by taking the following steps:
Generate a self-signed cert + key with openssl for client key + certificate:
openssl req \
-newkey rsa:2048 -nodes -keyout client.key \
-x509 -days 365 -out client.crt
Use the postgres_get_server_cert.py script to get the self-signed server cert from heroku psql:
https://raw.githubusercontent.com/thusoy/postgres-mitm/master/postgres_get_server_cert.py
The problem is that Heroku Postgres requires an SSL connection which doesn't seem possible with Data Studio at the moment. Hopefully Google will add that option soon.
Make sure to run the openssl command on one line to generate the client.key and client.crt in one command. It took me a couple of tries of downloading the certificates (unable to reach host error), but this finally got me connected to Heroku Postgres with GDS.
I thought I would mention that I have used this for quite awhile, but every time my database undergoes maintenance it breaks and I have to manually reconnect the certificates. I developed a better approach - connect the data to Google BigQuery and do your blends there, and then use the BigQuery Community Connector. The charts are more performant this way AND you can now use query parameters on blended data.
Of course, DataStudio won't connect directly to Heroku Postgres for the same reason, so I use a service called Fivetran to grab the raw data and send it to Google BigQuery. There is a cost to this, of course, but for some projects it may be worth it. At some point I will move my database off of Heroku to either AWS or Google itself to allow a direct connection, but that is a larger project.
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.