Regarding the data transfer security, there are more concerns beyond the authentication weaknesses or the misuse of authorization. Whether it’s wired or wireless, your transmission environment is more likely to be under a packet sniffing threat than you suppose, especially if ever the data you transfer start to possess a great commercial value as you grow up your business. When planning a secure transfer policy for your network, just focusing on the initiation stages at checkpoints where the authentication and authorization processes are taking place, may lead you to not to take into consideration that the data themselves may also include set of clear text authentication schema(s) inside. In such a case, you’d be only hardening the gates with “keep out“ strategy rather than protecting the data on their way. Therefore, data encryption is essential necessity in any kind of corporate environment.
Implementing host or IP address based access control precautions via TCP wrapping on inetd super-server, configuring simple ACLs on 3rd party FTP servers or setting up specific firewall rules in order to keep FTP connections under control will only provide a false satisfaction while bringing rigid limitations over connectivity that will obstruct “anytime, anywhere updates” for especially the enterprises with lots of mobile partners and consistent data transfer volumes. In such scattered topology, it is not practically feasible to enforce your static gateway policies to all of the endpoint nodes. Above all, none of these techniques will protect your data from being intercepted by various network sniffers and from being stolen by skilled intruders out there.
Then, why not to combine public key authentication model with the data transfer encryption to leave all such concerns behind ? In order to achieve this, we’ll be implementing SFTP which is quite often deemed as FTP over SSH. Actually this notion is wrong as SFTP is a new protocol designed from the ground up by IETF (Internet Engineering Task Force) SECSH (Secure Shell Working Group). Also it is occasionally confused with Simple File Transfer Protocol which is also irrelevant. SFTP is used as a subsystem of SSH protocol and it utilizes SSH encryption during the file transfer. Yes, it is slower than the conventional unencrypted and unprotected FTP due to the encryption overhead. But if you agree to pay this price in the form of slower transfer rates, in return for an absolute security and access flexibility for your business, SFTP is what you’re looking for.
I won’t refer to a public key authentication matter again in this article as we’ve done it before in SSH Public Key (/w RSA) Authentication post. I’ll directly proceed to SFTP part assuming that you’ve read and implemented the steps given there and you have an up and running SSH v2 with RSA (preferably 2048 bit) Public Key authentication.
Additionally, you have to edit your sshd_config, comment out the default Subsystem directive and subsequently append our new subsystem configuration below. Please notice %u variable as it will catch the user account for chrooting.
# vi /etc/ssh/sshd_config
# override default of no subsystems #Subsystem sftp /usr/libexec/sftp-server Subsystem sftp internal-sftp Match group sftp ForceCommand internal-sftp ChrootDirectory /usr/local/www/apache22/data/%u X11Forwarding no AllowTcpForwarding no
Before we start arranging the dependent paths, we need to add a new group to our system in order to configure sshd to invoke internal-sftp susbsytem for the users of this relevant matching group.
# pw groupadd sftp
Let’s suppose that we’re going to prepare a SFTP setup for a web hosting customer account called “company”. We have to create the chroot home directory under your DocumentRoot where the customer will be locked inside. After that, we’ll create and order the .ssh directory ownership and permissions in order to store the public key of this customer. Follow the steps below;
# cd /usr/local/www/apache22/data/ # mkdir company # cd company/ # mkdir .ssh # chown -R root:sftp .ssh/ # chmod 750 .ssh # cd .ssh/ # touch authorized_keys # chmod 440 authorized_keys
Public key has to be copied to SSH server and has to be appended to a file (~/.ssh/authorized_keys) which contains the list of authorized keys.
# cat /path/to/key/Identity.pub > /usr/local/www/apache22/data/company/.ssh/authorized_keys
Add SFTP user account to the system with the usermod options below and give a new password to this account which in fact will never be used throughout SFTP connections;
# pw useradd -n company -g sftp -d /usr/local/www/apache22/data/company -s /usr/sbin/nologin # passwd company New Password: Retype New Password:
Return back to chroot directory and change its ownership. It must be definitely root owned!
# cd /usr/local/www/apache22/data/ # chown root:wheel company
Finally, create user writable directory. In this case it will be the actual webroot of the user where the uploaded web data will be kept. You may create unlimited number of separate containers inside the chroot directory for different vhost configurations for the same user.
# cd company/ # mkdir webdata # chown -R company:sftp webdata
For another independent user, you shall create another chroot directory inside /usr/local/www/apache22/data and repeat the consequent steps.
# /etc/rc.d/sshd restart Stopping sshd. Starting sshd.
We are at our final step and at this point we need a client software, right? When it comes to SFTP clients, some of existing FTP clients do not fully support this protocol properly (at the time this article was being written) especially in terms of Public Key Authentication. For now, WinSCP will be the most neat choice for Windows users to make untill the rest catch up with it. FileZilla is another solution for both Windows and Ubuntu users but it converts and leaves the private key file passwordless during the site setup which thereby causes a security concern for serious implementations. I do know that FlashFXP is going to support it in 4.0, its upcoming major version.
If you decide to use WinSCP, create a new session record by indicating the file protocol as SFTP and locate your Private Key file. If your key files are in OpenSSH format, WinSCP will ask you to convert them to PuTTY format (*.ppk) before using. You can easily do it by using PuTTYgen tool that comes with WinSCP.
If you face the following error message within the first connection attempt, most probably you have forgotten to change the ownership of the chroot directory to root.
# tail -f /var/log/auth.log Sep 23 22:56:00 app2 sshd[15832]: fatal: bad ownership or modes for chroot directory "/usr/local/www/apache22/data/company"
RSS feed for comments on this post.
