Kerberos/ssh ticket forwarding sometimes fails in Mac OS X

s_jester@gmx.net s_jester at gmx.net
Mon Apr 4 17:41:30 EDT 2005


Hi,

I can always get kerberos tickets on my Powerbook, but the tickets
don't always get forwarded if I ssh to a kerberized host (i.e. I can
ssh to a remote host without getting prompted for a password, but
logging in from there to another remote host does prompt for a
password), and the ssh loging hangs for some 10s of seconds; it tends
to work directly after restarting my computer, but I haven't been able
to figure out under which exact circumstances it works or doesn't work.
Has anyone encountered this problem before? Is there a thread in this
or another newsgroup that talks about it? An FAQ somewhere?

Here are all the details of the problem I could think of:

 I use Mac OS X 10.3.8 with Kerberos for Macintosh version 5.0.1 and
OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL
0x0090702f

I have a powerbook, so I move around a bit between my home and two
offices, typically setting the computer to sleep in between. I get an
IP number via DHCP at all locations. I can always get Kerberos tickets
and ssh to the kerberized host at my home institution. However, under
some circumstances, my kerberos tickets do not seem to get forwarded
properly to the login host at my home institution, even though I always
request addressless forwardable tickets.

I.e. on my powerbook I get kerberos tickets, and klist -f yields this
output after sshing:

Kerberos 5 ticket cache: 'API:Initial default ccache'
Default Principal: XXX at XXX.XXX
Valid Starting     Expires            Service Principal
04/04/05 16:05:05  04/05/05 17:05:06  krbtgt/XXX.XXX at XXX.XXX
        FPIA
04/04/05 16:05:20  04/05/05 17:05:06  host/somehost.xxx.xxx at XXX.XXX
        FPA

I can ssh to the remote host without getting prompted for a password.
When my problem occurs, klist -f on the remote host yields:

klist: No credentials cache file found (ticket cache /tmp/krb5cc_10629)

while at other times, it lists a forwarded ticket.

My .ssh/config file contains the following lines:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
KerberosAuthentication yes

If I look at the ssh debugging output, the login process hangs for a
few 10s of seconds after

debug1: Calling gss_init_sec_context
debug1: Delegating credentials

the next lines are

debug1: Received GSSAPI_COMPLETE
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
external-keyx,gssapi,keyboard-interactive
debug1: Next authentication method: external-keyx
debug1: Authentication succeeded (external-keyx).

I *think* that gssapi is supposed to be the method that does the
authentication, so I am wondering how the external-keyx comes in. Right
now, the login fails, so I don't have ssh debug output of a successful
login session.

Another effect of this failure is that I don't get AFS tickets:

aklog: Couldn't get fnal.gov AFS tickets:
aklog: Invalid argument while getting AFS tickets

I think the problem must be related to moving around with the laptop,
because I've seen a transition from "everything works as it should"
using tickets I acquired while at home, to seeing the symptoms above
when I renewed the existing kerberos tickets at the office. Any help or
hints would be appreciated.

Thanks,

Sebastian



More information about the Kerberos mailing list