[32924] in Kerberos
Re: GSSAPI Issue
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Nov 24 12:39:31 2010
From: Greg Hudson <ghudson@mit.edu>
To: Bram Cymet <bcymet@cbnco.com>
In-Reply-To: <4CED470E.9050005@cbnco.com>
Date: Wed, 24 Nov 2010 12:39:25 -0500
Message-ID: <1290620365.20307.5.camel@ray>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, 2010-11-24 at 12:10 -0500, Bram Cymet wrote:
> If I just ssh with no tickets on my local machine it will ask me for a
> password and I can then run a klist on the server and see:
Right, the server is using the password you typed to get credentials.
> So it allows me to ssh without a password (as I want) but then when I
> try to klist on the server I don't seem to have a credentials cache and
> I am fairly sure I should have one.
Since you didn't enter a password, the server didn't have a convenient
opportunity to get credentials for you.
It is possible to forward credentials from the client to the server.
For this to work, the following must be true:
* You must have obtained forwardable tickets on the client. You can do
this with kinit -f, or by setting "forwardable = true" in the
[libdefaults] section of krb5.conf.
* "GSSAPIDelegateCredentials yes" must be set in ssh_config, or
specified on the command line with ssh -o GSSAPIDelegateCredentials=yes.
There may be other requirements I've forgotten. If anything goes wrong,
credential forwarding will typically fail silently and you'll get logged
in without credentials.
Note that forwarding credentials has security implications, in that it
allows the server to do things on your behalf that it wouldn't otherwise
be able to do. If you elect set GSSAPIDelegateCredentials yes in
ssh_config, you may wish to restrict it to a Host section.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
