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
I'm writing this from the samba server's perspective.
If you don't have access to a gui or prefer to do things in the command line you can replace step 5 with:
First, work out which ports samba is listening on. This can be done with this command:
netstat -tulpn | egrep "samba|smbd|nmbd|winbind"
You'll see something like this:
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 43270/smbd
tcp 0 0 10.0.0.1:139 0.0.0.0:* LISTEN 43270/smbd
tcp 0 0 10.0.0.1:88 0.0.0.0:* LISTEN 43273/samba
tcp 0 0 127.0.0.1:88 0.0.0.0:* LISTEN 43273/samba
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN 43270/smbd
tcp 0 0 10.0.0.1:445 0.0.0.0:* LISTEN 43270/smbd
The above example shows, that the services are listening on localhost (127.0.0.1) and the interface with IP 10.0.0.1 - each on the listed ports (139, 88, 445, and so on). Further information about samba port usage can be found here: https://wiki.samba.org/index.php/Samba_port_usage
Make a note of port and associated tcp/udp, then add lines that open these ports and protocols in /etc/sysconfig/iptables (it's probably a good plan to back up iptables before editing).
If we take the top line of output from the example above, we'd want to open TCP port 139 in iptables. This can be done by adding the following line of text to /etc/sysconfig/iptables:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
Say if you wanted to open UDP port 137 you could do it by adding the following line of text to /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m udp -p ucp --dport 137 -j ACCEPT
You'd need to keep adding lines for any other ports that you need to have open.
Then save your changes, and restart IPtables (service iptables restart).
Hope that helps.
Best Answer
What you want to do for consolehelper is put
UGROUPS=wheel
in the console.apps files. (You don't need to change what's there already, and usually shouldn't.) And then add the corresponding users to the wheel group. Then, members in that group will be prompted to auth-as-self, while other users will still auth-as-root. (A while ago, I needed this same functionality, so I wrote it and got the patch upstreamed. Open source is awesome.)This is documented in
man userhelper
.On newer distributions — current Fedora and RHEL6 — consolehelper is being phased out in favor of PolicyKit (a.k.a.
polkit
). This has a different configuration scheme, but can also do the same thing. Seeman pklocalauthority
for details on that, but the summary is: put files in/etc/polkit-1/localauthority/50-local.d
with contents like:And, finally, you can uncomment the
%wheel ALL=(ALL) ALL
line in/etc/sudoers
. (This may become the default in Fedora 15.)