[27842] in Kerberos
Re: Use ssh key to acquire TGT?
daemon@ATHENA.MIT.EDU (Christopher D. Clausen)
Fri Jun 1 00:36:53 2007
Message-ID: <F551256E51ED4F2EAA3F28566AB722EE@CDCHOME>
From: "Christopher D. Clausen" <cclausen@acm.org>
To: <kerberos@mit.edu>
Date: Thu, 31 May 2007 23:36:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Adam Megacz <megacz@hcoop.net> wrote:
> "Christopher D. Clausen" <cclausen@acm.org> writes:
>> How exactly is having a private key password different from simply
>> telling the user to kinit ONCE on their local machine before
>> attempting to SSH to your Kerberized machines?
>
> Because you have to kinit once **per realm**.
Well, if the passwords are differnet you can't get around that. If the
passwords are manually syncronized, it should be possible to have some
process that takes a single password and gets multiple tickets from it.
And wouldn't a user need to enter multiple passwords if the passphrases
were different on seperate private keys?
> Most users also have many accounts on many machines that are not part
> of HCOOP. Sadly, the world does not revolve around our KDC.
Ask for realm trusts. (Or wait for $bigcompany to create a single huge
world-wide Kerberos realm.)
> That's the nice part about ssh public keys -- you can use the same
> private key to log into any number of servers, even if the server
> admins don't have the logistical bandwidth (or political leverage) to
> negotiate complicated cross-realm arrangements with each other. Or
> even if some of the servers don't use kerberos.
You can similarly set your password to be the same for multiple realms.
>> Also, you could rig up a login script (or PAM) that used a local
>> keytab file to obtain AFS tickets automatically at sucessful login.
>
> Yes, unfortunately this would mean that anybody who hacked local root
> on any one of the shell servers would instantly have keytabs for every
> user. Not good.
Anyone who hacked local root would be able to just copy all the tickets
in the krbcc in /tmp when users login anyway. Yes, immediate access to
all principals would be bad, but having access to even some tickets
would be bad enough. Or replace the login process with something that
grabs tickets / passwords.
I don't know know enough about sshd and private keys to know if its
possible to use something locally on a shell server to decrypt a keytab
at login and then use it for AFS access. I suspect such an a sshd / PAM
modification is possible, but I have no idea how to go about
implementing it.
> Also, I don't know if MIT KDC supports having both a password and a
> keytab for a user. I know it's possible in theory, but I think that
> feature just isn't there -- creating a keytab erases their password.
It should be possible. Use the addent ktutil function.
kinit username
Password for username@REALM:
kvno username
username@REALM: kvno = 1
kdestroy
($kvno = 1)
ktutil
ktutil: addent -password -p username -k $kvno -e des-cbc-crc
Password for username@REALM:
ktutil: addent -password -p username -k $kvno -e des3-cbc-sha1
Password for username@REALM:
ktutil: wkt username.keytab
ktutil: quit
(and enc_types as needed)
<<CDC
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
