Modify pg_hba.conf file to allow me access - linux

I keep getting an error when trying to connect to psql database, "connection closed by remote host". I have tried modifying the pg_hba.conf file to allow the IP of my computer to have access, but I still get the same error, what am I doing wrong? Do I have to restart the server or something?
host all all <ip>/32 md5
As well, I have seen /24 instead of /32, how do I know which number to use?

The notation "/32" refers to a single IP address whereas the notation "192.168.1.0/24" refers to all addresses on the 192.168.1.x network.
And yes, you will probably have to do an SQL restart, something like:
service postmaster restart
But make sure your IP address is restrictive so that hackers won't be visiting your database all day. Use "localhost" if you can (127.0.0.1).

Related

How to configure PostgreSQL to accept specific IPV6 incoming connection

I'm trying to connect to my remote DB from inside Intellij.
So I think I need to be in pg_hba.conf
I have my IPV4 local connections:
host all all my.IP.V4.ip/32 md5
Question: beneath this is a line to configure IPV6, I have the address but I don't know what exactly to put for the IPV6 line after the "/"? Do I even need the slash?
host all all 1:2:3:4:5:6:7:8/??? md5
UPDATE: Hmm, so I have...
host all all xxxx:xxxx:xxxx:ccc:xxxx:xxxx:xxxx/128 trust
...and my db client (intellij) is still asking for a username / password.
user:postgres....pass:none....is still failing
thanks in advance
pg_hba.conf takes CIDR addresses, so yes, just like with IPv4 address you'll need the slash and the number behind it.
If you want to narrow the permissible connection down to one specific host you'll want to specify a /128.
host all all 1:2:3:4:5:6:7:8/128 md5

Can't access to postgreSQL server

I'm having a trouble which I can't connect to my database using IP Address. It works fine when I access it to my local but the problem is the other PC can't connect to my server. I've been using postgre v11 and navicat v12. Is there any permission to setup in my device in order that the other devices can access to my database? It would be great if anybody could figure out where I am doing something wrong. thank you so much in advance
You have to change the host settings of the database to access it from a foreign IP
I would look at two things if connections from remote hosts are being rejected.
First what is the value of the parameter listen_addresses in the postgresql.conf file? If it is set to:
listen_addresses='localhost'
It will be allow only local loopback connections. Change this (for example to listen on all interfaces) to:
listen_addresses='*'
Next, check the pg_hba.conf file has a rule to allow connections from your remote client. By default PostgreSQL will refuse these remote connections and they must be whitelisted. The following example entry would allow any user to connect to any database from 192.168.1.2 and they must supply the password
host all all 192.168.1.2/32 md5
Check out the official PostgreSQL docs for this at:
https://www.postgresql.org/docs/11/auth-pg-hba-conf.html

Confluence in Docker can't see PostgreSQL in Docker

I'm trying to set up both Confluence and PostgreSQL in Docker. I've got them both up and running on my fully up to date CentOS 6 machine, with volume-mapping to the host file system so I can back them up easily. I can connect to PostgreSQL using pgAdmin from another machine just fine, and I can get into Confluence from a browser from that same machine. So, basically, both apps seem to be running as expected inside their respective containers and are accessible to the outside world, which of course eliminates a whole bunch of possibilities for my issue.
And that issue is that Confluence can't talk to PostgreSQL during initial setup, which is necessary for it to function. I'm getting connection failed errors (to be specific: "Can't reach database server or port : SQLState - 08001 org.postgresql.util.PSQLException: The connection attempt failed").
PostgreSQL is using the default 5432 port, which of course is exposed, otherwise I wouldn't be able to connect to it via pgAdmin, and of course I know the ID/password I'm trying is correct for the same reason (and besides, if it was an auth problem I wouldn't expect to see this error message). When I try to configure the database connection during Confluence's initial setup, I specify the IP address of the host machine, just like from pgAdmin on the other machine, but that doesn't work. I also tried some things that I basically knew wouldn't work (0.0.0.0, 127.0.0.1 and localhost).
I'm not sure what I need to do to make this work. Is there maybe some special method to specify the IP to a container from the same host machine, some nomenclature I'm not aware of?
At this point, I'm "okay" with Docker in terms of basic operations, but I'm far from an expert, so I'm a bit lost. I'm also not a big-time *nix user generally, though I can usually fumble my way through most things... but any hints would be greatly appreciated because I'm at a loss right now otherwise.
Thanks,
Frank
EDIT 1: As requested by someone below, here's my pg_hba.conf file, minus comments:
local all all trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
host all all all md5
try changing the second line of the pg_hba.conf file to the following:
host all all 0.0.0.0/32 trust
this will cause PostgreSQL to start accepting calls from any source address. Since a docker container is technically not operating on localhost but on its own ip, the current configuration causes PostgreSQL to block any connections to it.
Also check if confluence is searching for the database on localhost. If that is the case change that to the ip of the hostmachine within the docker network.
Success! The solution was to create a custom network and then use the image name in the connection string to PostreSQL container from Confluence container. In other words, I ran this:
docker network create -d bridge docker-net
Then, on both of the docker run commands for the PostgreSQL and Confluence containers, I added:
--network=docker-net
That way, when I ran through the Confluence configuration wizard, when it asked for the hostname for the PostgreSQL server, I used postgres (the name I gave the container) rather than an IP address or actual hostname. Docker makes that work thanks to the custom network. This also leaves the containers available via the IP of the host machine, so for example I can still connect to PostgreSQL via 192.168.123.12:5432, and of course I can launch Confluence in the browser via 192.168.123.12:8080.
FYI, I didn't even have to alter the pg_hba.conf file, I just used the official PostgreSQL image (latest) as it was, which is ideal.
Thanks very much to RSloeserwij for the suggestions... while none of them proved to be the solution I needed, they did put me on the right track in the Docker docs, which, after some reading, led me to understand a few things I didn't before and figure out the config magic I needed.

Accessing a server using VPN connection

I am trying to connect to a university server using a VPN client. I can connect to the client. Also, if I ping the server by name and by IP address, they both work:
ping servername
ping serveripaddress
However, I cannot access the server from the browser if I type:
\servername
\serveripaddress
and also I do not see anything in Network apart from my own computer. I changed my Workgroup to the correct Workgroup, and it still doesn't work.
Also, as my DNS suffix I use the domain name as well as the FQDN, but it doesn't work either.
I restarted after each of these changes, but it didn't help.
I read that when I have a VPN connection working and I am also able to ping the server to which I want to connect, it is most probably DNS resolution problem. But I do not know anymore what to do (I checked and tried the correct DNS suffixes).
Do you know what should I do more? I am using Windows 7.
Thank you.
It sounds like you're trying to use UNC pathing. Assuming that you're getting your network settings from DHCP, are you getting a WINS server?

SSH Works For Some Hosts, Not For Others

I've been having problems SSHing into my work computer from home. I have been able to succesfully ssh into one of our web servers so I know the ssh daemon is working and my connection is at least allowing some ssh. But when I try to ssh to my work computer it times out.
I went to my University yesterday and I was able to succesfully ssh into both the web server and my work computer. I've looked into our firewall at work to see if there are any blocks on my IP but it isn't blocked.
My ISP is comcast if that helps at all. I've done a few google searches and some comcast customers say that comcast sometimes blocks file sharing ports such as the ssh port (22).
Any help would be appreciated. Thanks.
First check the /etc/hosts.deny file of your work computer. That may contain lines which might suggests that certain IP may be blocked. Then check /etc/hosts.allow file. You can add your home-computers outgoing IP to your work computers /etc/hosts.allow.
NOTE: This question should belong to superusers or serverfault. stackoverflow is for questions that involves coding...
There is not one single "ssh daemon"... there is one running on each host to which you connect successfully. If you cannot connect to a host there are two primary reasons:
There is no SSH daemon running on the host. In that case you will likely get "connection refused"
There is a firewall between you and the host, and it is not allowing port 22 to pass through. In that case you will likely get timeouts.
If you are trying to connect to a host behind a firewall from "outside", as you suggest, it is extremely likely that host is not reachable from the Internet. If the IP address of the "work computer" looks like 192.168.x.x or 172.[16-31].x.x or 10.x.x.x then it is an unroutable private address and you will not be able to reach it from the outside no matter what you do unless a specific port-forwarding rule is set up on the firewall; in that case you would be connecting to the firewall's IP address, not your target host.

Resources