Setting Up SSH Permissions (Chrooting?)

[Waffles13]

This is undoubtedly a fairly common topic, but excessive searching both on this forum and Google have not yielded an idiot-proof tutorial for my specific use case.

I have a fairly basic setup with a single volume ("Storage") divided into a number of sub-directories ("Video", "Documents", "Games", etc). There's currently only one user account ("Waffles") which matches my Windows user and password and has full read/write access to everything on Storage. I've had no trouble getting SSH working for myself (just turn on the service in FreeNAS and log in with "Waffles" on an SSH client). However, I'd like to share specific folders with others who can log in with their own accounts and be locked to the specified folders.

I've set up other users (let's call them "VideoShare" and "DocShare") and set their home directories to their respective folders, but when SSH-ing in you can very easily go up a level and access anything else on the volume. Numerous tutorials talk about chrooting, but all that I've found involve using ZFS datasets with no explanation of what they are or how they work (a fact that led me to name a dataset "Video" and made that entire sub-directory disappear). Furthermore, many of the folders on my volume are full of terabytes of data, and creating datasets seems to create new, empty directories. While I could technically create datasets and manually move the files into them, my volume is approaching capacity and the idea of cut/pasting a two terabyte folder is somewhat worrying to me.

I should also point out that while largely computer savvy, I have very little knowledge of Unix based stuff and have done just about all of my FreeNAS work so far through the GUI. Also, I would really like my existing "Waffles" account to be unaffected by this if possible, as it is basically my admin account.

tl;dr: I need a dumbed down tutorial to take a nearly full volume with multiple sub-directories and divvy those directories up to SSH users that cannot exit them WITHOUT affecting my personal account's ability to access all the folders at once.

Bonus points if one user could access multiple of those directories (say a "Family" account that can access "Video" and "Documents" but NOT access "Games"), but now I'm just getting greedy.

 

[Dusan]

Unfortunately there is no easy solution.
It is quite easy to chroot SFTP sessions (but it would apply to all users), however I understand you want your users to be able to use SSH shell sessions? Chrooting SSH sessions is more complex as you need to provide all files needed to support the session in the jail (at least some basic /dev nodes, the shell binary, ...).
Why do you actually need full SSH sessions? Do the users need to run programs?
My suggestion is to use proper file sharing protocols (CIFS/AFP/NFS) where users can't "escape" the share be default.
If you really need SSH sessions then you should set your permissions properly so that even when a users leaves his home directory he won't be able to access anything he isn't supposed to.
Yet another option is to use FTP. The Always Chroot option chroots every user except those that are members of the wheel group. If you also enable TLS the connection will be encrypted too.

 

[Waffles13]

So I have a very loose understanding of how all this stuff works, particularly when it comes to networking. As far as I understood it, SFTP and SSH were the same thing in the context of FreeNAS. I basically just want to be able to use Filezilla or a similar program to download files from my NAS when I'm not inside my home network. Really just that simple, and it works fine if using my main user account. I just want to be able to designate other users who can log in with other passwords and get subsets of my data without being able to see all of it. They don't need to run programs or anything like that; just access and download files.

 

[warri]

In this case you can just choose the scponly shell, and put the users in a group or auxiliary group called sftp. This won't allow normal SSH sessions, but file transfer with Filezilla works. In the SSH service advanced options, you then need to configure how users of group sftp are handled, here is my configuration:

Code:

Match Group sftp
    ChrootDirectory /mnt/tank1
    ForceCommand internal-sftp
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no

This chroots the users to /mnt/tank1, the mount point of my pool. The ForceCommand directive is explained in the man pages as follows:

Specifying a command of internal-sftp will force the use of an in-process sftp server that requires no support files when used with ChrootDirectory.