I am installing DSPACE which needs PostgresSQL.
Please see this link: DSPACE INSTALL
It says:
Then tighten up security a bit by editing pg_hba.conf and adding this line:
host dspace dspace 127.0.0.1 255.255.255.255 md5.
I have read on the internet as to how the above line works. It needs a connection type followed by database name/user name followed by IP address and the authentication scheme.
My question is: Should this not be a local (in place of host) connection since the dspace user is running locally?
Can someone show me step by step as to what happens when a request comes in?
Where are the instructions that the dspace user will submit a request using md5?
DSpace uses JDBC, so local won't work for it. Here local means a completely different kind of inter-process connection that has nothing to do with IP and can only address local processes: Unix sockets. JDBC uses only IP, so DSpace needs a host descriptor.
That period at the end of the line is not supposed to be part of it. The documentation was unclear there -- I've fixed it.
As Laurenz Albe noted, DSpace doesn't specify that MD5 password hashes be used. The PostgreSQL server controls which methods will be tried, based on what you specify in pg_hba.conf.
First, there is a . at the end of your pg_hba.conf line. That is a syntax error.
Whether to use local or host depends on
what API this DSPACE is using (JDBC, for example, allows no UNIX socket connections)
what connection string DSPACE is using
If you can specify a socket directory as host name, you can probably use UNIX sockets, which would be more efficient.
If DSPACE uses a driver that supports md5 authentication, the procedure is like this:
client sends server a connect packet with user and database
server requests md5 authentication and sends a random "salt" string
client computes an MD5 hash of the password with the salt from the server and sends the result to the server
server verifies that the hash is correct
Related
I'm using pg-promise in a typescript express app.
I can log on to psql by just typing psql because the linux username is the same as the database name and I'm set to use peer authentication.
I can't seem to get pg-promise to let me do this - it always fails and gives an error that password authentication failed.
I've been looking at the pgpromise docs but can't find anything - I've tried all sorts of connection strings.
I managed to make this work for me by using a Unix Domain Socket instead of a TCP socket and connecting using a connection string.
So my connection looks like this const db = pgp('socket:/var/run/postgresql'); but presumably the /var/run/postgresql could vary by system.
I'm setting up a server, with postgresql running as a service. I can use nmap to get current postgresql version
nmap -p 5432 -sV [IP]
It returns:
PORT STATE SERVICE VERSION
5432/tcp open postgresql PostgreSQL DB 9.3.1
Is there a way to hide the postgresql version from nmap scanning? I've searched but it's all about hiding the OS detection.
Thank you.
There's only one answer here: Firewall it.
If you have your Postgres port open, you will be probed. If you can be probed, your service can be disrupted. Most databases are not intended to be open like this to public, they're not hardened against denial-of-service attacks.
Maintain a very narrow white-list of IPs that are allowed to connect to it, and whenever possible use a VPN or an SSH tunnel to connect to Postgres instead of doing it directly. This has the additional advantage of encrypting all your traffic that would otherwise be plain-text.
You have a few options, but first understand how Nmap does it: PostgreSQL database server responds to a malformed handshake with an error message containing the line number in the source code where the error occurred. Nmap has a list of possible PostgreSQL versions and the line number where the error happens in that particular version. The source file in question changes frequently enough that Nmap can usually tell the exact version in use, or at least a range of 2 or 3 version numbers.
So what options do you have?
Do nothing. Why does it matter if someone can tell what version of PostgreSQL you are running? Keep it up to date and implement proper security controls elsewhere and you have nothing to worry about.
Restrict access. Use a firewall to limit access to the database system to only trusted hosts. Configure PostgreSQL to listen only on localhost if network communication is not required. Isolate the system so that unauthorized users can't even talk to it.
Patch the source and rebuild. Change PostgreSQL so that it does not return the source line where the error happened. Or just add a few hundred blank lines to the top of postmaster.c so Nmap's standard fingerprints can't match. But realize you'll have to do this every time there's a new version or security patch.
I have two databases set up as part of the same Postgresql 9.4 database cluster, and I'm trying to access a table in one of them from the other using a postgres_fdw. I have it all set up and working as a superuser, however when I try to access the foreign table as a normal user, I get the following error:
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
Now I understand that this is because I have the server set up with trust authentication for certain subnets, including Its own. However, in the 1 USER MAPPING I created, I did specify a password, with the hope that doing so would force it to use password authentication. No such luck apparently.
As such, my question is if there is any way around this somewhat onerous requirement? Is there a way to force this connection, or a specific user, or the like to use password authentication? Or some way to disable the requirement? Or is my only option to change the configuration to require passwords, and deal with whatever that breaks?
As Nick Barnes pointed out in a comment, pg_hba allows different authentication rules for specific users. As such, the solution to this issue was to simply create a user specifically for these FDW connections, and set that user in the pg_hba.conf to require a password. That way my trusted web apps on the trusted network can continue connecting as usual, but the FDW can get the password request it requires.
You can't force FDW to use a password: the server on the other end must request the password. the usual default for local socket connections is no password.
Try connecting via TCP instead of using local sockets: add host=localhost to the connection parameters, that will usually fix it.
I love postgres.app. It makes it really simple to develop against postgres. I'm configuring a vagrant setup so some of my other developer friends can easily use postgres, however I'd like to enable the same behavior of postgres.app, namely I'd like them to be able to connect using localhost and without having to have a username or password specified. I know it's gotta be possible, but I haven't figured out how yet. Any ideas?
Worst case I can create a super user, since I know the username of vagrant boxes, but if you have any ideas, I'd love to hear 'em.
You can automatically install local instance of PostgreSQL server and preconfigure pg_hba.conf file to have trust entries like this:
# Allow any user on the local system to connect to any database
# with any database user name using Unix-domain sockets
# (the default for local connections):
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
# The same using local loopback TCP/IP connections:
host all all 127.0.0.1/32 trust
I am trying to setup PostgreSQL and allow only certain Windows users to access the data from the database. Setting up Windows Authentication is Quite easy with MS SQL, but I can't figure out how to set it up in PostgreSQL.
I have gone through the documentation at http://www.postgresql.org/docs/current/static/auth-methods.html
and edited the pg_hba file. But after doing so, the PostgreSQL service fails to start.
Is the Postgresql server running on Windows as well as the clients then you might test with this to see if this works:
host all all 0.0.0.0/0 sspi
Magnus Hagander, a Postgresql developer, elaborates on this:
"All users connecting from the local machine, your domain, or a trusted domain will be automatically authenticated using the SSPI configured authentication (you can enable/disable things like NTLMv2 or LM using Group Policy - it's a Windows configuration, not a PostgreSQL one). You still need to create the login role in PostgreSQL, but that's it. Note that the domain is not verified at all, only the username. So the user Administrator in your primary and a trusted domain will be considered the same user if they try to connect to PostgreSQL. Note that this method is not compatible with Unix clients."
If you mix Unix-Windows then you have to resort to kerberos using GSSAPI which means you have to do some configuration. This article on deploying Pg in Windows environments may perhaps lead you in the right path.
If anyone else encouters this like I did so starting from 9.5 you wil need to add an optional parameter both to the ipv4 and ipv6 in order for this to work
include_realm=0
so the whole thing will look like
host all your_username 127.0.0.1/32 sspi include_realm=0