Обсуждение: hostnossl in pg_hba.conf demands a password

I've been experimenting a bit with both 9.4.10 and 9.6.0 and both of these are exhibiting the same behavior. I've been
settingup zabbix and the local agent requires a trust connection. So, if my pg_hba.conf has a line: 

host         all                monitoring.          127.0.0.1/32.    trust

It works as I expected, but if I change "host" to "hostnossl" and reload, it then demands a password for the monitoring
user.

The servers are configured with SSL and all other connections require "hostssl", but the zabbix agent is not configured
withSSL. I'd say this behavior is a bug, but maybe I missed reading the fine manual somewhere. Has anyone else seen
thisor maybe the docs need updating. 

--
Jay

Sent from my iPad

On Tue, Nov 15, 2016 at 8:10 AM, John Scalia <jayknowsunix@gmail.com> wrote:

I've been experimenting a bit with both 9.4.10 and 9.6.0 and both of these are exhibiting the same behavior. I've been setting up zabbix and the local agent requires a trust connection. So, if my pg_hba.conf has a line:

host         all                monitoring.          127.0.0.1/32.    trust

It works as I expected, but if I change "host" to "hostnossl" and reload, it then demands a password for the monitoring user.

The servers are configured with SSL and all other connections require "hostssl", but the zabbix agent is not configured with SSL. I'd say this behavior is a bug, but maybe I missed reading the fine manual somewhere. Has anyone else seen this or maybe the docs need updating.

 

Do you have any other entries (for 127.0.0.1) in pg_hba.conf which is generating this behaviour ?

Regards,

Venkata B N

Database Consultant

Fujitsu Australia

John Scalia <jayknowsunix@gmail.com> writes:
> The only entries are a local connection line with md5 authentication specified and a line for local replication with
atrust authentication. Both of these entries do seem to be working properly. 

So the client is trying an SSL connection first (which would be the
default behavior for libpq at least), and that falls through the
hostnossl line and is captured by the md5 line.  Hence you get a
password prompt.  The client has no way to know that a non-SSL
connection would have gotten a different response.

You could change the md5 line to hostssl, perhaps.  Or configure
the client to try non-SSL first (see sslprefer).

            regards, tom lane

Thanks, Tom,

I'll check to see if it's trying an SSL comnection, but being that I logged into this server, and I know that I don't
havean .ssh subdirectory in my home dir, I didn't think an SSL connection would be tried. We'll see. 

Thanks again,
Jay





Sent from my iPad

> On Nov 14, 2016, at 4:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Scalia <jayknowsunix@gmail.com> writes:
>> The only entries are a local connection line with md5 authentication specified and a line for local replication with
atrust authentication. Both of these entries do seem to be working properly. 
>
> So the client is trying an SSL connection first (which would be the
> default behavior for libpq at least), and that falls through the
> hostnossl line and is captured by the md5 line.  Hence you get a
> password prompt.  The client has no way to know that a non-SSL
> connection would have gotten a different response.
>
> You could change the md5 line to hostssl, perhaps.  Or configure
> the client to try non-SSL first (see sslprefer).
>
>            regards, tom lane