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 believe that the error message you are getting explains it.
Your server's root
account has wrongly setup profile scripts. Some of them print a message that violates SFTP protocol. There's different profile script for a terminal and non-terminal session (one that has and does not have TTY allocated). Messages can be printed only from the script used for terminal sessions. When you print a message from profile script used for non-terminal sessions, it breaks any client using a strict protocol (such as SFTP or SCP).
The message starts with "Plea" as the error says. It can easily be something as trivial as
echo "Please be careful when using root account!"
You will see a complete message when you log in using an SSH terminal (such as PuTTY).
Typically you will need to move the commands that print the message from .bashrc
script to .bash_profile
.
It works with ubuntu
account, because its profile scripts do not print the error message.
See also WinSCP documentation for the error message "Received too large (... B) SFTP packet. Max supported packet size is 102400 B".
Best Answer
SFTP; the SSH File Transfer Protocol uses the SSH port and is a subsystem of your SSH server.
No separate FTP server needed. (Well not quite, there is indeed an
sftp-server
program that speaks the server side of SFTP protocol to but it is not intended to be called directly. It is called by your SSH server using the Subsystem option.)Permission denied
errors are typically exactly that, file-system permissions preventing your user from writing in places you are not allowed to...Arguably the SFTP protocol is as cryptographically secure as FTPS so no preference there.
FTP over SSL still suffers from the classical FTP problem of needing two ports/connections and the SSL version of FTP is even more likely to break than regular FTP when you need to do NAT or set up firewall rules.
The advantage of FTPS is that TLS certificates have a much wider supported trust infrastructure to validate the identity of a remote server using its TLS certificate than SSH keys.