How to add user with SFTP/ FTP access to '/var/www/html/website_abc' folder on Amazon EC2 Centos?

Possible Duplicate:
Linux directory permissions

I'm working with some third-party developers and I would like to grant SFTP (or FTP) access to the root folder for a website they're working on i.e. '/var/www/html/website_abc' so that they could upload the files there. Note that I'm hosting my other websites there on the same EC2 instance e.g. '/var/www/html/website_xyz'.

Just to emphasize that I'm working with multiple websites on 1 single EC2 instance, the structure of the websites are as follows:

/var/www/html/
/var/www/html/website_abc
...
/var/www/html/website_xyz

My goals are as follows:

• User 'adeveloper' has access to '/var/www/html/website_abc' and only '/var/www/html/website_abc'
  • I suppose user 'adeveloper' will use 'adeveloper@[my elastic IP]' as username to login to SFTP (or FTP), am I right?
• User 'adeveloper' do not have access to '/var/www/html/' or any other directories in my EC2 instance
• How about the private key file?
  • Do I pass my private key file to the third-party developers - is it advisable to do so?
  • Is there a way to generate a different private key file for them or allow them to log in with username & password instead?

I have done searches but most people were talking about how to access EC2 via SFTP which I'm already be able to using WinSCP.

Clarifications:

• I would need 'adeveloper' to be able to upload stuffs to /var/www/html/website_abc which is 'write' permission
• I would need 'adeveloper' to not have 'write' permission for any files/ directories under /var/www/html/, and ideally not even 'read' permission
• However, there seems to be big problem here:
  • /var/www/html/ already has permission 777 since this is my DocumentRoot folder. So, how do I stop 'adeveloper' from accessing my other website?

Partly solved I managed achieved my goals using OpenSSH (I create .ssh folder inside /var/www/html/website_abc/ and generate private key and give it to the third-party developers). I also learnt that I should never ever give the private key file AWS gave me. Still learning about chroot.

Solution 1:

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