Match directive breaks SSH

Question

On my Ubunut server 12.04 LTS machine, I try to add a user with only sFTP or FTP access. Let's call him 'Jim' for now. Jim only needs access to a directory /var/www/example.com.

So far I've tried both vsftpd and openSSH, both to no avail.

I have OpenSSH installed correctly and I can use sFTP for my own account. But I can reach all directories and use SSH which should both not be possible for Jim.

I've tried several tutorials including:

• http://www.serverubuntu.it/SFTP-chroot
• http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP

At current stage I have a user account for Jim, and he can't get SSH access. I changed his home directory to /var/www/example.com. Which is from www-data:users, Jim is part of the users group and the sftponly group. There are no changes made to sshd_config to limit Jim's options.

When I try to add Match User jim or Match Group sftponly and supply any option like ChrootDirectory SSH won't be able to restart. When I restart the service I don't get any notice but when taking a look with ps -ae | grep ssh ssh is not listed. If I remove the Match directive SSH will properly restart. Can anyone give me a hint how to finish my sFTP or FTP setup?

I would prefer to have a setup where ftp users wouldn't be local users but separate managed virtual users.

Answer 1

Your going about this pretty .... wrong. Not to say that it won't work but it's not going to be easy. Your fighting some pretty serious defaults.

I would recommend two things. First create the users home directory from scratch, using adduser or whatever, you can specify the home directory with the -d flag. So you can do adduser jim -d /var/www/jim

Sharing a home directory between several users will not work without a ton of effort.

Next, to restrict to scp/sftp only change their login to /bin/nologin. This will stop then from sshing or logging in locally.

Finally, strongly consider why you want to chroot. In order to chroot you will effectively need a base system install for every home directory complete with some things in ~/bin ~/lib and ~/etc along with probably a lot else. I you truly must chroot a ssh session you can have a look at this link, however I strongly suggest against that for anything but a public ssh server. Even then I would want a really good reason for doing so personally. Keep in mind if you don't want them accessing a directory you can just chmod o-r it (that's what your first link suggests).

If your even considering chroot, then stay well away from FTP. FTP would typically be chrooted but FTP is insecure, so if your trying to secure something don't bother with FTP. A 90 foot thick bank vault door with lasers and guard robots wont do squat if the rest of the vault is made from cardboard.