This seems simple, but how do I restrict user to their home?

I am starting to host multiple sites, nothing major, but some are completely self managed. I recently discovered that when a user logs in via terminal or SFTP app, they get to their home dir fine, but they can also back out and see my entire / directory. Where did I go wrong when creating the users?

All the users I am creating are just for their sites, so their home dir is /srv/www/domain.tld, but they can go anywhere they want and view everything.

Thanks

11 Replies

http://www.minstrel.org.uk/papers/sftp/builtin/

Try this.

For SFTP, http://library.linode.com/security/sftp-jails/ will get you there lickety-split. However, allowing terminal-based logins will require a little more thought.

With SFTP, the user just needs access to their data, since the SFTP server is embedded within the SSH server. However, just chrooting and running bash will present a number of challenges, since the user won't have access to /bin, /etc, /lib, /usr/bin, /usr/lib, etc, etc. This means they won't be able to use things like /bin/ls or be able to map uids to usernames via /etc/passwd.

Something like http://olivier.sessink.nl/jailkit/ will build and maintain a "fake" userspace within the users' home directories, allowing them to do what they need to do with bash. Alternatively, some sort of restricted, self-contained shell (busybox?) might do the job. But there's gonna be some thought, planning, testing and effort required to make it happen.

Hoopycat: Thats exactly what I am trying to do, in the first link. I wasn't aware I could block shell and only allow sftp, which is perfect. So I went through the guide, and am having trouble. I already have the 7 usernames and groups, and each already has been set to have a home directory of /srv/www/domain.tld/.

I modified /etc/ssh/sshd_config

I added the group filetransfer

I then did the usermod -G filetransfer username on all 7 usernames.

Now here's where I varied from the instructions. Since they already had the home dirs, I skipped chown'ing root:root to the home/username, and skipped making the docs and public_html folders (again, since they already had home dirs).

So I went on to the last step

chown username:username * for each username in their respective home directories.

With all that said, I can successfully login as root in shell, and I can also login to sftp using the root username and password, however when the username/password is sent for any other user, FileZilla returns the following:

Error: Server unexpectedly closed network connection

Error: Could not connect to server

So thats where I am at. It seems it is blocking the usernames from logging into anything… I will say this. I went back and looked at the group setups, and some didn't look like, so I modified all the 7 users to ONLY be in group filetransfer. Any others that were in a group that matched their username, I simply removed them from that group… was that my mistake?

You need to do the root chowning step you skipped. Essentially, for sftp jails to work like you want, the folder you're jailing them to has to be owned by root. Basically, you chown the user's home to root to allow ssh to jail to it, and then chown the folders in it to the user, so the user can actually do something with it.

:facepalm:

Worked like a charm. Ive learned that:

chown'ing root /home/username != chown'ing /hom/username/*

Thanks!

OK, I am still having a problem. When a user logins via sftp, it does properly restrict them to their home directories, but I cannot write to anything. I tried the following:

  • User (loj in this case) was only in filetransfer group, so I added their username to the group that is named the same as their username (loj:loj)

  • I tried it both with filetransfer and loj as their "primary" group

Still cannot write. Only root can write at this moment.

Yes.

You need to create a subdirectory, and make the user owner of that subdirectory.

He'll never be able to write to the "top" directory he's chrooted into.

If you're doing web hosting, a

/site1.com

/site2.com

/private_files

layout may be good.

Also, mind, these must be real directories, not sym-links to outside of the chroot. Latter won't work. You'll need to point your web server config to the websites which reside in subdirs of your users' homedirs.

Just to be clear, let me give you two examples. I have teamslow.com and legionofjeepers.com. Users are teamslow and loj respectively.

Their directories are /srv/www/legionofjeepers.com and /srv/www/teamslow.com

Following the guide, I first did

chown root:root /srv/www/legionofjeepers.com

chown root:root /srv/www/teamslow.com

Then

chown loj:loj /srv/www/legiomofjeepers.com/*

chown teamslow:teamslow /srv/www/teamslow.com/*

There are various other folders within those directories, such as the public_html folder for storing the site, log folders etc… Should I have done this differently? I have done the same thing to all 7 of my hosted sites and their users/home dirs.

Edit: After posting this, I re-read your reply and did confirm user loj could write to /public_html, /log etc… if I wanted them to be able to write to the root of /srv/www/legionofjeepers.com, would I then need to just do

chown root:root /srv/www

chown loj:loj /srv/www/legionofjeepers.com

chown teamslow:teamslow /srv/www/teamslow.com

???

No matter how you want to structure your files, the following 2 conditions must be true in order for your setup to "work".

1. The folder you're using as the chroot must be owned by root. If this is not the case, you will not be able to connect at all with sftp for that user.

2. There must be a folder inside the chroot owned by the user who is being jailed. This is because the user cannot create files inside a folder owned by root. If this is not the case, you will be able to connect with sftp, but the user won't actually be able to do anything useful.

So, if you want to keep your two domains separate, I recommend a setup like this:

srv/

srv/legionofjeepers.com/

srv/legionofjeepers.com/public_html/

srv/teamslow.com/

srv/teamslow.com/public_html/

Each user's home directory should be "srv/legionofjeepers.com" and "srv/teamslow.com" respectively, and the should be jailed to those directories. Chown root to those two, and then chown the publichtml files to their respective owners. Then setup your web server to point to the publichtml files.

That way each user sftp's into their own contained folder, puts their site in the public_html folder, and it's served from there.

That makes sense, and the way I set it up in my prevoious post should work. root owns all /srv/www/domain.tld folders, and then each user was chown'd to /srv/www/domain.tld/*. With this setup, they should be able to write to any subfolder within the domain.tld folder, they just will not be able to write directly to the root folder (domain.tld). Which is fine, I cannot see any reason, web site related, for them to need access to their chroot.

My last question regarding this… I suppose you can only have one user with write access to the directories (excluding root user of course), correct?

Well, my system has single users responsible for many sites, so I use

/srv/userA/site1.com

/srv/userA/site2.com

/srv/userA/private # for non-site files

/srv/userB/site3.com

/srv/userB/site4.com

/srv/userB/private # for non-site files

but it's a matter of preference.

You can semi-easily have one user have access to all those sites - don't chroot him (or chroot to /srv), make sure he belongs to all the others' "user groups" (by default each user has its own group) and make sure all the files in the site subdirs are group-writeable. I'm not sure if you can force umask 002 in SFTP, if not, a cronjob (or manual chmod -R g+w by root) might work.

(edit: Ack, 11pm grammar)

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct