[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kerberos on diskless clients



Den 15. juni 2010 11:01, skrev Jonas Smedegaard:
> On Tue, Jun 15, 2010 at 09:07:35AM +0200, John S. Skogtvedt wrote:
>> sorry for my late entry to the discussion on kerberos. It's really
>> good that you're working on it.
>>
>> I wonder, has anybody thought about how to implement Kerberos+NFSv4 on
>> diskless clients?
>> My understanding is that every workstation needs to have a
>> "$hostname/nfs" principal in Kerberos, with a secret key. Every
>> machine which presents a correct principal and key can read the
>> exported filesystem, but to write to it you need to authenticate to
>> kerberos (with a user principal). If any of this is incorrect, please
>> correct me.
>>
>> As the diskless filesystem is (by necessity) available to anyone,
>> putting Kerberos keys for all clients there would be no more secure
>> than NFSv3. One idea is to put the key on a HD or CF card, another is
>> to put the encrypted keys in the chroot and prompt the admin for the
>> password at boot. Of course, both of these suffer from the problem
>> that the server can't be trusted (e.g. a second server on the network
>> serving a filesystem which gathers keys and passwords).
> 
> How about this:
> 
>  1) Serve (like now?) root filesystem read-only using unencrypted nfs
>  2) Add (like now?) local ram-based overlays to writable parts like /var
>  3) Authenticate using Kerberos at login time
>  4) Mount /home using nfs v4
> 
> 
>  - Jonas
> 

Sorry, my email was unclear: I was talking about the /skole/tjener/home0
filesystem. The / filesystem can stay on NFSv3 and needs to be readable
to (nearly) all, writing to it is today handled by using ramdisks (using
aufs would be better, but that's off topic).

With /skole/tjener/home0, the problem is that the machine itself needs a
"$hostname/nfs" principal with corresponding secret key. It's not enough
that the user can authenticate to Kerberos.

John.


Reply to: