Обсуждение: PG 8.3 and kerberos failures
Hi all,
I just upgraded one of my servers and I'm having a bit of trouble
getting some of the kerberos authentication bits working.
Specifically, any Kerberos instance run out of a v5srvtab doesn't work
so well. Using stashed tickets or normal principals worked fine.
Gritty details follow.
Peter
Here are details from the specific v5srvtab's...
[root@sensei postgres]# klist -k -t /etc/v5srvtab.wsbackup
Keytab name: FILE:/etc/v5srvtab.wsbackup
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
13 12/20/07 15:56:11 wsbackup/sensei.cs.wisc.edu@CS.WISC.EDU
[root@sensei postgres]# klist -k -t /etc/v5srvtab
Keytab name: FILE:/etc/v5srvtab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
13 12/20/07 15:56:11 host/sensei.cs.wisc.edu@CS.WISC.EDU
13 12/20/07 15:56:11 rcmd/sensei.cs.wisc.edu@CS.WISC.EDU
13 12/20/07 15:56:11 telnet/sensei.cs.wisc.edu@CS.WISC.EDU
13 12/20/07 15:56:11 ftp/sensei.cs.wisc.edu@CS.WISC.EDU
13 12/20/07 15:56:11 pop/sensei.cs.wisc.edu@CS.WISC.EDU
13 12/20/07 15:56:11 wsbackup/sensei.cs.wisc.edu@CS.WISC.EDU
12 12/20/07 15:56:11 auth/sensei.cs.wisc.edu@CS.WISC.EDU
8 12/20/07 15:56:11 postgres/sensei.cs.wisc.edu@CS.WISC.EDU
Here's the error from the syslog...
Apr 17 11:18:39 sensei postgres[4486]: [3-1] LOG: connection
received: host=mitchell.cs.wisc.edu port=56925
Apr 17 11:18:39 sensei postgres[4486]: [4-1] LOG: unexpected Kerberos
user name received from client (received "wsbackup", expected
"wsbackup/mitchell.cs.wisc.edu")
Apr 17 11:18:39 sensei postgres[4486]: [5-1] FATAL: Kerberos 5
authentication failed for user "wsbackup"
Apr 17 11:18:39 sensei postgres[4488]: [3-1] LOG: connection
received: host=mitchell.cs.wisc.edu port=56926
Apr 17 11:18:39 sensei postgres[4488]: [4-1] FATAL: no pg_hba.conf
entry for host "128.105.207.19", user "wsbackup", database "sushi",
SSL off
Here's the relevant bit from my pg_hba.conf. For compatibility, I'm
using krb5 instead of gss until everything is upgraded from 8.2. If
using gss authentication will work, please let me know.
hostssl all all 128.105.0.0/16 krb5
hostssl all all 198.133.224.0/24 krb5
And from postgresql.conf...
# - Security & Authentication -
#authentication_timeout = 1min # 1s-600s
ssl = on # (change requires restart)
#ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH' # Allowed SSL ciphers
# (change requires restart)
#password_encryption = on
krb_realm = 'CS.WISC.EDU'
#db_user_namespace = off
# Kerberos and GSSAPI
krb_server_keyfile = '/etc/v5srvtab.postgres' # (change requires restart)
#krb_srvname = 'postgres' # (change requires restart, kerberos onl
y)
#krb_server_hostname = '' # empty string matches any keytab entry
# (change requires restart, kerberos onl
y)
#krb_caseins_users = off # (change requires restart)
On Thu, Apr 17, 2008 at 11:40 AM, Peter Koczan <pjkoczan@gmail.com> wrote: > Hi all, > > I just upgraded one of my servers and I'm having a bit of trouble > getting some of the kerberos authentication bits working. > Specifically, any Kerberos instance run out of a v5srvtab doesn't work > so well. Using stashed tickets or normal principals worked fine. > Gritty details follow. > > Peter > > Here are details from the specific v5srvtab's... > [root@sensei postgres]# klist -k -t /etc/v5srvtab.wsbackup > Keytab name: FILE:/etc/v5srvtab.wsbackup > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 13 12/20/07 15:56:11 wsbackup/sensei.cs.wisc.edu@CS.WISC.EDU Here's what happens when I do this (it's on a different machine but it's the same mechanism). [root@ator] ~ $ su - wsbackup ator(1)% kinit -f -k -t /etc/v5srvtab.wsbackup -l 1d wsbackup/ator.cs.wisc.edu@CS.WISC.EDU ator(2)% klist Ticket cache: FILE:/var/adm/krb5/tmp/tkt/krb5cc_28528 Default principal: wsbackup/ator.cs.wisc.edu@CS.WISC.EDU Valid starting Expires Service principal 04/18/08 12:25:00 04/19/08 12:25:00 krbtgt/CS.WISC.EDU@CS.WISC.EDU Kerberos 4 ticket cache: /tmp/tkt28528 klist: You have no tickets cached ator(4)% /s/postgresql-8.2/bin/psql -h sensei -p 5432 postgres Connecting to 8.2 works... ator(5)% /s/postgresql-8.3/bin/psql -h sensei -p 5432 postgres Connecting to 8.2 via 8.3 binaries works... ator(6)% /s/postgresql-8.3/bin/psql -h sensei -p 49173 postgres psql: FATAL: no pg_hba.conf entry for host "128.105.162.36", user "wsbackup", database "postgres", SSL off And then it fails as above... Apr 18 12:20:41 sensei postgres[4486]: [3-1] LOG: connection received: host=ator.cs.wisc.edu port=56925 Apr 18 12:20:41 sensei postgres[4486]: [4-1] LOG: unexpected Kerberos user name received from client (received "wsbackup", expected "wsbackup/ator.cs.wisc.edu") Apr 18 12:20:41 sensei postgres[4486]: [5-1] FATAL: Kerberos 5 authentication failed for user "wsbackup" Apr 18 12:20:41 sensei postgres[4488]: [3-1] LOG: connection received: host=ator.cs.wisc.edu port=56926 Apr 18 12:20:41 sensei postgres[4488]: [4-1] FATAL: no pg_hba.conf entry for host "128.105.162.36", user "wsbackup", database "postgres", SSL off And this is what syslog shows when I try GSSAPI authentication. Apr 18 12:34:40 sensei postgres[25885]: [3-1] LOG: connection received: host=ator.cs.wisc.edu port=41148 Apr 18 12:34:40 sensei postgres[25885]: [4-1] FATAL: GSSAPI authentication failed for user "wsbackup" Apr 18 12:34:40 sensei postgres[25886]: [3-1] LOG: connection received: host=ator.cs.wisc.edu port=41149 Apr 18 12:34:40 sensei postgres[25886]: [4-1] FATAL: no pg_hba.conf entry for host "128.105.162.36", user "wsbackup", database "postgres", SSL off Is this something I'm just going to have to find a way to work around or should I file a bug report? Peter
On Fri, Apr 18, 2008 at 12:43 PM, Peter Koczan <pjkoczan@gmail.com> wrote: > On Thu, Apr 17, 2008 at 11:40 AM, Peter Koczan <pjkoczan@gmail.com> wrote: > > Hi all, > > > > I just upgraded one of my servers and I'm having a bit of trouble > > getting some of the kerberos authentication bits working. > > Specifically, any Kerberos instance run out of a v5srvtab doesn't work > > so well. Using stashed tickets or normal principals worked fine. > > Gritty details follow. > > > > Peter > > > > Here are details from the specific v5srvtab's... > > [root@sensei postgres]# klist -k -t /etc/v5srvtab.wsbackup > > Keytab name: FILE:/etc/v5srvtab.wsbackup > > KVNO Timestamp Principal > > ---- ----------------- -------------------------------------------------------- > > 13 12/20/07 15:56:11 wsbackup/sensei.cs.wisc.edu@CS.WISC.EDU > > Here's what happens when I do this (it's on a different machine but > it's the same mechanism). > > [root@ator] ~ $ su - wsbackup > ator(1)% kinit -f -k -t /etc/v5srvtab.wsbackup -l 1d > wsbackup/ator.cs.wisc.edu@CS.WISC.EDU > ator(2)% klist > Ticket cache: FILE:/var/adm/krb5/tmp/tkt/krb5cc_28528 > Default principal: wsbackup/ator.cs.wisc.edu@CS.WISC.EDU > > Valid starting Expires Service principal > 04/18/08 12:25:00 04/19/08 12:25:00 krbtgt/CS.WISC.EDU@CS.WISC.EDU > > > Kerberos 4 ticket cache: /tmp/tkt28528 > klist: You have no tickets cached One more thing to note, I said before that stashed tickets and login principals "just work." Here might be something... [koczan@ator] koczan $ klist Ticket cache: FILE:/var/adm/krb5/tmp/tkt/krb5cc_3258_ZtKJNK Default principal: koczan@CS.WISC.EDU ... [root@mitchell ~]# export KRB5CCNAME=/var/adm/krb5/tmp/stash/krb5cc_25555.stash [root@mitchell ~]# klist Ticket cache: FILE:/var/adm/krb5/tmp/stash/krb5cc_25555.stash Default principal: strivia@CS.WISC.EDU ... They don't contain hostname data in the default principal like the keytab principal does, and yet they both connect fine. There could be something to this, but I don't know what, or how to take advantage of it. Peter