Use ssh key to acquire TGT?

[Christopher D. Clausen]

Adam Megacz <megacz at hcoop.net> wrote:
> "Christopher D. Clausen" <cclausen at 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 at REALM:
kvno username
username at REALM: kvno = 1
kdestroy

($kvno = 1)

ktutil
ktutil: addent -password -p username -k $kvno -e des-cbc-crc
Password for username at REALM:
ktutil: addent -password -p username -k $kvno -e des3-cbc-sha1
Password for username at REALM:
ktutil: wkt username.keytab
ktutil: quit

(and enc_types as needed)

<<CDC