What should be the directory mode for /var/www/html folder

After more research it seems like another (possibly better way) to answer this would be to setup the www folder like so.

1. sudo usermod -a -G developer user1 (add each user to developer group)
2. sudo chgrp -R developer /var/www/site.com/ so that developers can work in there
3. sudo chmod -R 2774 /var/www/site.com/ so that only developers can create/edit files (other/world can read)
4. sudo chgrp -R www-data /var/www/site.com/uploads so that www-data (apache/nginx) can create uploads.

Since git runs as whatever user is calling it, then as long as the user is in the "developer" group they should be able to create folders, edit PHP files, and manage the git repository.

Note: In step (3): '2' in 2774 means to 'set Group ID' for the directory. This causes new files and sub directories created within it to inherit the group ID of the parent directory (instead of the primary group of the user) Reference: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

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