Adam Megacz <[EMAIL PROTECTED]> wrote: > "Christopher D. Clausen" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]: kvno username [EMAIL PROTECTED]: kvno = 1 kdestroy ($kvno = 1) ktutil ktutil: addent -password -p username -k $kvno -e des-cbc-crc Password for [EMAIL PROTECTED]: ktutil: addent -password -p username -k $kvno -e des3-cbc-sha1 Password for [EMAIL PROTECTED]: 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