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
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.
Maarten Broekman
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
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.