On August 22, 2015, Michael Torrie wrote: > The really sad thing is that there aren't that many good, secure, file
> serving options for plain Linux. NFSv3 permissions are enforced by the > client, which is okay in a lab environment where end users don't have > root access. NFSv4 is much more secure (clients can be authenticated by > Kerberos), but it's very much complex to set up. 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. 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. 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? --- Dan On Sat, Aug 22, 2015 at 8:26 AM, Michael Torrie <[email protected]> wrote: > On 08/22/2015 02:19 AM, Dan Egli wrote: > > On August 20, 2015, Levi Pearson wrote: > > > >> Why did it occur to you that no one is using Samba anymore? > > > > > > > > I should have said no one would be using samba where this whole thing is > > being implemented. I did not mean that no one anywhere is using it, just > > not where I have to deal with it for now. :) > > The really sad thing is that there aren't that many good, secure, file > serving options for plain Linux. NFSv3 permissions are enforced by the > client, which works okay in a lab environment where end users don't have > root access. NFSv4 is much more secure (clients can be authenticated by > Kerberos), but it is very much complex to set up. > > In some respects, Samba is a good choice for sharing files between Linux > machines. Samba implements full posix support, so if the client is > Linux, Samba will make sure the permissions and ownership work. The > problem here is obtaining the user's password for performing the mount. > There are PAM hacks that store the user's password during login, and > pass it to an autofs mount. A few years ago I set up a bunch of test > machines set up that would mount a users home directory via Samba upon > login using this method. It seemed to work okay. > > See: > https://wiki.archlinux.org/index.php/Pam_mount > http://buechse.de/HOWTO/samba_pam_mount_sshd/ > > Note that winbind is not required; that's for authenticating against a > window server. > > One big downside to both the Samba method and the NFSv4+Kerberos home > directory methods is that logins using ssh keys just don't work, as > there aren't any credentials to perform the mount with. Also ssh needs > to be reconfigured to use PAM, which is does not by default. > NFSv4+Kerberos does work with Kerberized, password-less ssh logins. If > the Kerberos ticket is passed along with ssh, the mount should be able > to use that ticket. > > What should be simple turns out to be really complicated, which is why > most places still use NFSv3 to this day, despite the security problems. > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
