On 08/25/2015 01:12 AM, Dan Egli wrote: > That's ESPECIALLY complex for those of us who have never LOOKED at > Kerberos. And how would you use something like that for a root FS on NFS? > I'm all for security, even in a home network. But I don't know that > anything else but NFSv3 can be used for a non-local root FS unless I want > to go all the way up to iSCSI, which is just crazy for a home network, I'd > think. I can see using that in certain settings, but not in a simple home > network where the only mass storage is on the server and all clients are > diskless.
Very true. However, without Kerberos, NFSv4 can do root file systems. NFS root filesystems trust clients by necessity. Plain old NFSv4 is now the default on RHEL/CentOS 7 I think. > The PAM hacks do sound of interest, and I'll probably look at them. But > since I don't think Linux supports a root on smbfs then that really > wouldn't work for my current project. Definitely something to keep in my > book of tricks for a later date, though. You never know when something like > that will come in handy. Samba and CIFS (CIFS supports posix, vs SMB which is the older protocol) are not really appropriate for root file systems. They can be used for home directories, though. > As far as the ssh keys, I'd imagine that's only a problem if you don't > specify a username on the command line (i.e. ssh user@host) and you don't > specify an identity file (i.e. ssh -i myremotekey root@remotehost). Am I > mistaken here? No, the problem is that without a password passed to sshd which can be picked up by pam, the mounter has no way of mounting the user's home directory. Furthermore, when you use an ssh key, sshd has to check the user's ~/.ssh/authorized_keys file, which isn't mounted yet. ssh keys don't work when using NFSv4 with Kerberos, for the same reason, but you can obtain a kerberos ticket, then ssh in and that ticket gets forwarded along with ssh and the other end can use that to mount the home directory. All this is why most people still use NFSv3, or NFSv4 without Kerberos to this day, fully trusting the client computer to enforce permissions and privacy. This worked fine in a computer lab where the sysadmins control everything. But in a department where you have individual people at their desk, some of whom need sudo access, then it becomes untenable. There are no good solutions to this dilemma that I know of. Anyway, this is just for your information! /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
