First off, the home directories in /etc/passwd
should reflect the un-chrooted paths, or you'll run into problems in general. In this case, sshd
checks for authorized keys before it chroots, so it needs to find them using an un-chrooted path. That's why your first try doesn't work.
Second thing to note: Under your first setup, when david logs in he starts in /var/chroot-home/david
, but he is actually chrooted to /var/chroot-home
, meaning if he types cd ..
he can see all of the other home dirs (although not their contents, if permissions are correct). This might or might not be a problem for you, but it's a good thing to be aware of.
If the above is fine with you, you can use your first sshd_config, set david's home dir to /var/chroot-home/david
in the passwd
file, and add the following symlink so that david still starts in his home directory:
cd /var/chroot-home
mkdir var
ln -s .. var/chroot-home
That symbolic link will make sure that you can reach a home directory using the same path whether or not you are in the chroot.
However, if you don't want the clients to see the names of each other's home directories, you need to chroot into the home directory itself, as in your second solution. But as you've seen, sshd
doesn't like that (because for various subtle reasons, it's dangerous to give a user write access to the root of a filesystem). Sadly, you're mostly out of luck here. One (kludgy) solution to this is to create a files/
subdirectory in each home directory and give the client write access to that instead.
Another option might be to chroot to /var/chroot-home anyway, and name the home directories differently, e.g. using the user ID number instead of the name.
By default services that provide a remote shell, like ssh or telnet, or an interactive remote session for commands like sftp, allow a local user to change into any directory they have permissions for, and retrieve a copy of any file they have access to.
As a general security configuration this is unfortunate because there are many files and directories which are world-readable of necessity. For example here is me a non-root user on some remote CentOS box;
$ cd /etc
-bash-3.2$ ls -1
acpi
adjtime
aliases
...
e.g. I can access lots of stuff, that ideally you would want to restrict from some unknown user who you wish to provide local access to.
Here is me looking at all the local users configured in the /etc/passwd
file;
$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
...
Unix systems provide the chroot
command which allows you to reset the /
of the user to some directory in the filesystem hierarchy, where they cannot access "higher-up" files and directories.
However in your case, it would appropriate to provide a virtual chroot implemented by the remote shell service. sftp can be easily configured to restrict a local user to a specific subset of the filesystem using a configuration in the
hence in your case, you want to chroot
the adeveloper
user into the /var/www/html/website_abc
directory.
You can set a chroot directory for your user to confine them to the subdirectory /var/www/html/website_abc
like so in /etc/ssh/sshd_config
;
This stuff requires openssh-server later than 4.8?, so probably requires CentOS 6.2
Match Group sftp
ChrootDirectory %h
AllowTcpForwarding no
(not tested, see man sshd_config
to confirm syntax)
and then add those users to the sftp group;
groupadd sftp
usermod -d /var/www/html/website_abc adeveloper
usermod -G sftp adeveloper
Regarding shared keys
you should create an additional keypair for the adeveloper users, and send that to your consultant. (or alternatively, have them send your their public key and add it to the authorized_keys file for adeveloper
)
never give up your private key, thats why its called private ;-)
traditional ftp alternatives
vsftp/proftp etc also support chroot configurations, but in this modern day ssh based configurations are the normal way, and support for ftp is historical only.
there are a couple of links to tutorials here;
http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229
http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny
Best Answer
I finally used SFTP to solve the mentioned problem. The main issues where the file permissions. I did the following steps (running CentOS 7.2):
Folder Permissions Following file permissions where set. Including the sticky bit (explained after the code).
Create Group and Users
Create user for external provider and set new password.
Setup sftp-server Subsystem in sshd_config
Outcomment existing Subsystem and and add:
Add add the end of sshd_config
Restart sshd service
Login via SFTP to test the connection
Security
SELinux is enforcing and was never en issue concerning this SFTP setup.