Re: Kerberos on diskless clients
Den 07. juli 2010 00:43, skrev Veli-Matti Lintu: ti, 2010-06-15 kello 13:44 +0200, John S. Skogtvedt kirjoitti: Den 15. juni 2010 12:51, skrev Jonas Smedegaard: On Tue, Jun 15, 2010 at 12:02:57PM +0200, John S. Skogtvedt wrote: 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. Oh. I was unaware that the machine needed a separate key for NFS. Problem, yes! What exactly do a $host/nfs key grant access to? The whole partition, encrypted by user keys, or the whole partition, unencrypted? I'm not a Kerberos/NFSv4 expert, but AFAIK it's a ticket-granting ticket (TGT) which firstly gives the machine read-only access to the entire exported filesystem, and secondly allows the machine to grant a RW ticket to the user. Kerberos is used to authenticate writes, and optionally for encryption as well. Would AFS perhaps provide a key structure better suited for this? My question here is _only_ about the key structure - AFS might have other limitations making it unsuitable, but the act of comparing key handling might help understand possible/sane approaches. Ideally we would use a filesystem requiring only user key to authenticate. Hmm - would it perhaps be possible (while still secure) to create and permiy a $user/nfs keypair acting as host key for .../home* mount points? Hi, I've been dealing with these same issues recently and after testing it looks like machine credentials are not needed to get diskless clients working with kerberos. What I have understood is that with NFSv4 the machine credentials are used for the initial mount + root access. For the initial mount credentials any credentials are actually ok and if rpc.gssd is run with -n option, it uses existing credentials for the mount. When using sec=krb5 access to users' home directories on the mounted directory then requires valid credentials for the user. I haven't really tested the root access part here as I have always used root_squash on all the exports. Using user's credentials instead of a keytab means of course that the mount works only as long as the credentials are valid. man rpc.gssd -n By default, rpc.gssd treats accesses by the user with UID 0 spe‐ cially, and uses machine credentials for all accesses by that user which require Kerberos authentication. With the -n option, machine credentials will not be used for accesses by UID 0. Instead, credentials must be obtained manually like all other users. Use of this option means that root must manually obtain Kerberos credentials before attempting to mount an nfs filesystem requiring Kerberos authentication. Veli-Matti Kiitos, this is very helpful. Which DM/desktop did you test with? gdm for instance used to (or still does) check as root if the user's homedirectory existed, which might cause problems. I will try to test with debian-edu within the next two weeks. John. -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c359e31.4080...@bzz.no
Re: Kerberos on diskless clients
ti, 2010-06-15 kello 13:44 +0200, John S. Skogtvedt kirjoitti: Den 15. juni 2010 12:51, skrev Jonas Smedegaard: On Tue, Jun 15, 2010 at 12:02:57PM +0200, John S. Skogtvedt wrote: 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. Oh. I was unaware that the machine needed a separate key for NFS. Problem, yes! What exactly do a $host/nfs key grant access to? The whole partition, encrypted by user keys, or the whole partition, unencrypted? I'm not a Kerberos/NFSv4 expert, but AFAIK it's a ticket-granting ticket (TGT) which firstly gives the machine read-only access to the entire exported filesystem, and secondly allows the machine to grant a RW ticket to the user. Kerberos is used to authenticate writes, and optionally for encryption as well. Would AFS perhaps provide a key structure better suited for this? My question here is _only_ about the key structure - AFS might have other limitations making it unsuitable, but the act of comparing key handling might help understand possible/sane approaches. Ideally we would use a filesystem requiring only user key to authenticate. Hmm - would it perhaps be possible (while still secure) to create and permiy a $user/nfs keypair acting as host key for .../home* mount points? Hi, I've been dealing with these same issues recently and after testing it looks like machine credentials are not needed to get diskless clients working with kerberos. What I have understood is that with NFSv4 the machine credentials are used for the initial mount + root access. For the initial mount credentials any credentials are actually ok and if rpc.gssd is run with -n option, it uses existing credentials for the mount. When using sec=krb5 access to users' home directories on the mounted directory then requires valid credentials for the user. I haven't really tested the root access part here as I have always used root_squash on all the exports. Using user's credentials instead of a keytab means of course that the mount works only as long as the credentials are valid. man rpc.gssd -n By default, rpc.gssd treats accesses by the user with UID 0 spe‐ cially, and uses machine credentials for all accesses by that user which require Kerberos authentication. With the -n option, machine credentials will not be used for accesses by UID 0. Instead, credentials must be obtained manually like all other users. Use of this option means that root must manually obtain Kerberos credentials before attempting to mount an nfs filesystem requiring Kerberos authentication. Veli-Matti -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1278456218.3993.30.ca...@punajuuri.liitu.vm.opinsys.fi
Kerberos on diskless clients
Hello, 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). John. -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1726b7.80...@bzz.no
Re: Kerberos on diskless clients
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 -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
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. -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c174fd1.9030...@bzz.no
Re: Kerberos on diskless clients
On Tue, Jun 15, 2010 at 12:02:57PM +0200, John S. Skogtvedt wrote: 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). Thanks for rephrasing: Yes, this is exactly what I meant. 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. Oh. I was unaware that the machine needed a separate key for NFS. Problem, yes! What exactly do a $host/nfs key grant access to? The whole partition, encrypted by user keys, or the whole partition, unencrypted? Would AFS perhaps provide a key structure better suited for this? My question here is _only_ about the key structure - AFS might have other limitations making it unsuitable, but the act of comparing key handling might help understand possible/sane approaches. Ideally we would use a filesystem requiring only user key to authenticate. Hmm - would it perhaps be possible (while still secure) to create and permiy a $user/nfs keypair acting as host key for .../home* mount points? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Kerberos on diskless clients
Den 15. juni 2010 12:51, skrev Jonas Smedegaard: On Tue, Jun 15, 2010 at 12:02:57PM +0200, John S. Skogtvedt wrote: 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). Thanks for rephrasing: Yes, this is exactly what I meant. 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. Oh. I was unaware that the machine needed a separate key for NFS. Problem, yes! What exactly do a $host/nfs key grant access to? The whole partition, encrypted by user keys, or the whole partition, unencrypted? I'm not a Kerberos/NFSv4 expert, but AFAIK it's a ticket-granting ticket (TGT) which firstly gives the machine read-only access to the entire exported filesystem, and secondly allows the machine to grant a RW ticket to the user. Kerberos is used to authenticate writes, and optionally for encryption as well. Would AFS perhaps provide a key structure better suited for this? My question here is _only_ about the key structure - AFS might have other limitations making it unsuitable, but the act of comparing key handling might help understand possible/sane approaches. Ideally we would use a filesystem requiring only user key to authenticate. Hmm - would it perhaps be possible (while still secure) to create and permiy a $user/nfs keypair acting as host key for .../home* mount points? - Jonas Don't know about these. Anyone? -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c176794.8030...@bzz.no
