Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GSSAPI / Kerberos ticket authentication issues

51 views
Skip to first unread message

Broekman, Maarten

unread,
Nov 16, 2009, 9:01:15 AM11/16/09
to kerb...@mit.edu
All,
I'm trying to configure my RHEL5 servers to perform GSSAPI
authentication via gssftp and ssh. I've enabled the gssftp service and
GSSAPIAuthentication (in ssh). Everything works properly with Kerberos
tickets over the "hostname" IP address (as well as any CNAMEs for it).
However, when I try to connect to a secondary IP address on the same
system, GSSAPI authentication fails. I have host principals in the
keytab for all hostnames on the system and /etc/hosts contains all the
appropriate host / IP entries.

Example:
$ kinit
$ ftp -n -i hostname --> Works properly
...
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI authentication succeeded
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote user username
232 GSSAPI user user...@DOMAIN.COM is authorized as
username

$ ftp -n -i hostname-alt --> Doesn't work.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI error major: Unspecified GSS failure. Minor code
may provide more information
GSSAPI error minor: Unknown code krb5 144
GSSAPI error: accepting context
GSSAPI ADAT failed
GSSAPI authentication failed
334 Using authentication type KERBEROS_V4; ADAT must
follow
KERBEROS_V4 accepted as authentication type
Kerberos V4 krb_mk_req failed: You have no tickets
cached
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote user username
331 Password required for username.

Code 144 is "wrong principal in request" but I can't for the
life of me figure out why.

Running klist -k /etc/krb5.keytab on the target server shows:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
------------------------------------------------------------------------
--
10 host/hostname-al...@DOMAIN.COM
10 host/hostname-al...@DOMAIN.COM
10 host/hostname-al...@DOMAIN.COM
10 host/hostname-al...@DOMAIN.COM
6 host/hostname....@DOMAIN.COM
6 host/hostname....@DOMAIN.COM
6 host/hostname....@DOMAIN.COM
6 host/hostname....@DOMAIN.COM

Checking both of these host principals in our kerberos database
shows that they are all valid.

Running a klist on my ticket cache on the source system shows:
$ klist
Ticket cache: FILE:/tmp/krb5cc_62548_AdrweK
Default principal: user...@DOMAIN.COM

Valid starting Expires Service principal
11/16/09 08:50:05 11/17/09 08:50:05
krbtgt/DOMAI...@DOMAIN.COM
11/16/09 08:50:34 11/17/09 08:50:05
host/hostname....@DOMAIN.COM
11/16/09 08:50:40 11/17/09 08:50:05
host/hostname-al...@DOMAIN.COM


Kerberos 4 ticket cache: /tmp/tkt62548
klist: You have no tickets cached

Any assistance with this would be greatly appreciated.

Thanks in advance,
--Maarten

Greg Hudson

unread,
Nov 16, 2009, 4:34:49 PM11/16/09
to Broekman, Maarten, kerb...@mit.edu
On Mon, 2009-11-16 at 09:01 -0500, Broekman, Maarten wrote:
> $ ftp -n -i hostname --> Works properly
> $ ftp -n -i hostname-alt --> Doesn't work.

I believe this is a consequence of how ftpd uses GSSAPI. It's using
gss_acquire_cred to get credentials for ftp@localhostname and
host@localhostname, instead of just passing the default to
gss_accept_sec_context, which would make it work for any key in the
keytab.

I don't see any good opportunities for workarounds without patching and
recompiling gssftpd. The local hostname is determined by calling
gethostbyname() on the result of gethostname(), so you can typically
influence which hostname is picked by fiddling with /etc/hosts, but you
can't make it try multiple hostnames.

I'll bring this up on the dev list and see about getting it fixed for a
future release. If you do want to patch and rebuild to work around
this, I can probably come up with a provisional patch for you in short
order.


Broekman, Maarten

unread,
Nov 16, 2009, 4:39:57 PM11/16/09
to Greg Hudson, kerb...@mit.edu
Thanks Greg. Getting it addressed in a future version would be great. Unfortunately, I don't think I'll be able to patch and rebuild.

Maarten Broekman

Broekman, Maarten

unread,
Nov 16, 2009, 4:53:03 PM11/16/09
to Greg Hudson, kerb...@mit.edu
Greg,
One thing I realized is that I forgot to mention is that I also
tried using the scan_interfaces and extra_addresses tags in my krb5.conf
but that didn't help. From the manpage for the krb5.conf these looked
like they might have addressed the issue. Also ssh suffers from the
same problem as gssftp so I'm guessing this is a more general issue and
not specific to gssftp.

Maarten Broekman
Fidelity | Investment Management Technology
TSO Server Architecture and Engineering
Office: (617) 563-9756
Cell: (617) 590-8005
Email: maarten....@fmr.com

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos


Greg Hudson

unread,
Nov 16, 2009, 5:40:31 PM11/16/09
to Broekman, Maarten, kerb...@mit.edu
On Mon, 2009-11-16 at 16:53 -0500, Broekman, Maarten wrote:
> Greg,
> One thing I realized is that I forgot to mention is that I also
> tried using the scan_interfaces and extra_addresses tags in my krb5.conf
> but that didn't help. From the manpage for the krb5.conf these looked
> like they might have addressed the issue.

Those settings don't pertain to this code.

> Also ssh suffers from the
> same problem as gssftp so I'm guessing this is a more general issue and
> not specific to gssftp.

Stock OpenSSH sshd has the same coding issue as ftpd, yes. If your sshd
had the gss-keyex patch, you could control this behavior with the
GSSAPIStrictAcceptorCheck config variable, but unfortunately Red Hat is
not one of the OS vendors who incorporate the gss-keyex patch.


0 new messages