Oh ... wait a second. I've just managed to partially reproduce this
report. Assume that we have a working Kerberos environment on both
ends. Then libpq will establish a connection with GSS encryption
and continue on with the usual PG authentication exchange. If that
part fails, then this logic (fe_connect.c around line 3350):
/*
* If gssencmode is "prefer" and we're using GSSAPI, retry
* without it.
*/
if (conn->gssenc && conn->gssencmode[0] == 'p')
{
/* postmaster expects us to drop the connection */
conn->try_gss = false;
pqDropConnection(conn, true);
conn->status = CONNECTION_NEEDED;
goto keep_going;
}
drops the connection and tries again without GSS. But *we already
cleared allow_ssl_try*, in pqsecure_open_gss, so the next try will
not bother with SSL either.
So this directly explains the original report: if the only applicable
pg_hba.conf entry is "hostssl", right here is where libpq will see
that error, and it will go around and fail again because the next
try uses neither GSS nor SSL.
However, in the tests Mikael ran after backing that pg_hba.conf entry
off to just "host", pg_hba wouldn't have caused an authentication-stage
failure, so it's not so clear why we'd have looped back at this step.
We'd need to explain the later cases to have a full theory. It's
plenty plausible that something else caused an auth-stage failure,
but if so, why would the second GSS-free try work?
In any case, that allow_ssl_try reset in pqsecure_open_gss is definitely
even more broken than I thought before. I think we need to rejigger the
state machine so that it doesn't do that at all, but instead skips SSL
establishment when GSS is already active via an explicit test, rather
than munging the state variables.
regards, tom lane